RFC: Proposed Method for Developing and Deploying UKRDC-Services
We have 3 environments, and 3 Wheel Indices - dev, staging and release. Currently, we do not use the staging index.
Currently, we update the dev wheel index every time we do a commit on ukrdc-services code. Neither dev or staging are installed until the script is run.
Promotion is done to release via a script in bamboo.
After a conversation with Rapolas, it is proposed that we have a release branch which is the code for the staging and production environments.
| Development | Staging | Live |
|---|---|---|
| Code development is done on the Master branch by developers doing fixes on branches from Master and their subsequent code merged to master. | Staging will use the release branch of ukrdc-webapi and the ukrdc-services pinned in the requirements.txt. Say, in this case 10.8.4 | At the start of the cycle, the deployed code of ukrdc-webapi on LIVE has the ukrdc-services module pinned to 10.8.4. |
Once the point has come to release, the ukrdc/services/__init__.py version is bumped to a release candidate version - in this case 10.8.5.RC1. | ||
| Tag the Master branch and merge the tag to the release branch | ||
When the code is merged from master into the release branch, the build process will build and upload the 10.8.5RC1 to the devpi RELEASE index. | ||
| If bugs are found in the release candidate, these are fixed on the release branch, and the changes migrated back in master. | ||
| When the 10.8.5RC1 ukrdc-services wheel has been successfully tested, the version number on the release branch will be changed to 10.8.5, the requirements.txt on ukrdc-webapi[release] updated to 10.8.5; | ||
| The wheel file will be built as 10.8.5 and loaded up to the dev-pi release index. | ||
| The Live server is updated with the new code from the release branch by running the standard script. |