At the moment there are three github actions (in the .github/workflows directory)
One deploys to the test environment whenever there is a merge into develop
One deploys to prod whenever there is a merge to main
One deploys a "down for maintenence" page, and is triggered manually through the github website
The deployment from main -> prod has proven to be messy and unnecessarrily complex. There is also no need to hoard the prod code, because it will always be in the commit history on the develop branch.
Let's change the prod deployment so that rather than being triggered by a merge into main, it is triggered manually. Instead of deploying the code from main, it should deploy from develop.
This can all be accomplished by editing the appropriate workflow file
Acceptance criteria:
[x] deployment to prod is from develop rather than main
[x] deployment to prod is triggered manually (like the "down for maintenance" page) rather than triggered by a merge
At the moment there are three github actions (in the .github/workflows directory)
One deploys to the test environment whenever there is a merge into develop One deploys to prod whenever there is a merge to main One deploys a "down for maintenence" page, and is triggered manually through the github website
The deployment from main -> prod has proven to be messy and unnecessarrily complex. There is also no need to hoard the prod code, because it will always be in the commit history on the develop branch. Let's change the prod deployment so that rather than being triggered by a merge into main, it is triggered manually. Instead of deploying the code from main, it should deploy from develop. This can all be accomplished by editing the appropriate workflow file
Acceptance criteria: