...
- Main
- Current "snapshot" branch
- Code here should be as stable as possible
- Code should never not be committed directly
- Base for feature/fix branches
- Feature branches
- When working on a specific feature/fix, create a new branch for that work item
- Either submit a PR when ready, or create a draft PR whenever
- PRs should pass all tests and code-quality checks before merging
- PRs should be reviewed by someone else on the project before merging
...
This guide is broadly applicable to both "ukrdc-fastapi" and "ukrdc-nuxt"
- Navigate to Actions
- From the Publish Docker Image workflow, click Run Workflow
- Enter the deployment environment you wish to deploy to
- This will become the docker image tag
- "production" and "staging" are protected, and will wait until the deployment has been approved by a project admin
- Create a new GitHub Release, or push a tag
- The tag and release should be named as the approximate release datetime, in the format YYYY-MM-DD-HHMM
- E.g. 2021-11-22-1410 for a release made on November 22nd 2021 at 14:10
- A docker image will be published with 2 tags, the version number, and 'latest'
Update containers on the app server
...
Reverting/redeploying an old version
- Eventually I want to add historical image tags so we can select an old version in the Compose file
- For now though, if you need to roll back a deployment, either revert commits in the 'main' branch and re-deploy as above,
or create a new temporary branch with the fixed/rolled-back code and use that branch in "Use workflow from" as aboveModify your docker-compose file, and instead of pointing to the image tag 'latest', point to a specific version tag.
Active Instances
- staging-app and live-app both include new UKRDC instances
- /srv/ukrdc-compose/
- In both cases, the host nginx config needs to be set up to forward to the Docker stack
- E.g. /etc/nginx/conf.d/staging-app.ukrdc.nhs.uk.conf
- This should not need to be changed unless we want to change the new stack base URL