- SEMVAR versioning is used for each repository (That is, DO NOT USE PI as a version)
- Deploying to unity-test or unity-venue-test require a release
- Answers "what are we integrating with" when issues arrise.
- Code is in a github release
- CHANGELOG included
- Release description is accurate and up to date
- Artifacts (binary code executables and/or Docker images) are available
- Available from Release Page
- Binaries/containers shall include the semantic version of the component
- Binaries/containers can optionally include the commithash of the main branch
- Software has been deployed, integrated, and tested in a development environment.
- All automated tests are passing
- Unit Test Code Coverage is at 80%
- All automated tests are passing
- Documentation is updated, deployed and accessible (gitbook, redoc, api-based docs, etc)
- Github Issues are updated and in resolved (or closed) state. Issues are included in Release notes.
System releases are aggregates of individual component releases. These usually approach some milestone (e.g. a PI end) as a way of marking where we are in the development process.
- Manifest of releases has been generated and is available
- Code releases have been deployed to the TEST environment
- System Level Verification and Validation (V&V) Test plan has been created and executed for each release
- V&V Summary is available
- Manual development tests are explicitly marked in the testplan
- Release Announcement is available on the release page
- Review Materials are archived where applicable
- Release Demo(s) has been Scheduled
- Publicized way of requesting issues - github, service desk, etc for your component
- No official guidance on branch strategy, but
- Main should be releasable code at any point
- Manual development tests are described in each repository (test/MANUAL-TESTS.md)
- Should plan for automating manual test.
- License File included in repository
- Labels are generated for the repository