ODE Release Preparation

Pre-Release Activities

During the course of development, source code changes are committed to Git and pushed to GitHub.

1. All features are developed in a feature branch off of dev branch usually named after the Jira ticket ID. All commits must also carry the Jira ticket ID so that all commits for the feature can be traced and listed from Jira. When the feature is fully developed with adequate Unit Testing, documentation and regression testing, a Pull Request (PR) is created and assigned to reviewers for approval. Once the PR is approved, the developer who created the PR, will merge the feature branch to dev branch and close the PR. When all features belonging to a Release Backlog are merged to dev, it is time to go to Step 2.
2. Tester pulls from dev branch and builds the pre-release software
3. Tester runs the automated regression test scripts and verifies that all tests pass
4. Tester verifies automated regression tests scripts by manually running a sampling of the manual tests provided here.
5. Tester reports the test results to the project team. If any test has failed, the pre-release activities are aborted and process starts from the beginning (step 1) or approval from Product Owner (PO) must be requested to release the software with a known issue. If all tests have passed or PO has approved the release with a known issue, a developer or a tester performs the following Release Process.
6. Tester pulls the software from the GitHub using the these instructions and runs the automated regression test scripts again.
7. Tester verifies automated regression test scripts by manually running a sampling of the manual tests.
8. Tester reports the test results to the project team. If any test has failed, the release activities are aborted and process starts from the beginning (step 1) or approval from Product Owner (PO) must be requested to release the software with a known issue. If all tests have passed or PO has approved the release with a known issue, the project team notifies the stakeholders that the ODE software release is ready for deployment.
9. The ODE software user pulls the software from the GitHub using the these instructions, builds the executable (Docker Image), deploys it to their Development (DEV) environment and runs the automated regression test scripts, manual test procedures and/or their own suite of User Acceptance Testing.
10. If UAT testing is completed successfully and all tests PASS, the software can be deployed to Production (PROD) environment. If any test fails, the issue must be reported in ODE issue tracker and followed up by the ODE Support SOP.

Release Process

When it's time to release the software to production, the following steps need to be taken by the ODE development team:

1. Switch to dev branch which should contain the latest code to be released:

git checkout -B dev origin/dev
git pull --recurse-submodules=yes origin

2. Release the software which will promote the version, tag the release, prepare for a new development iteration and merge the tagged release to stage branch.

. ./scripts/release.sh <releaseVersion>

where <releaseVersion> is the version that we are releasing, for example 1.2.3