Is there anyway to restrict the deployment to an environment during a particular window.
The idea behind this is to have a stable environment where QA can perform their validation on an environment where development teams consistently deploying latest packages.
We can set maintenance window but
1, This will prevent us from deploying to all the environments (I agree that administrators can still do the deployments)
2, Not sure I can schedule this for every day to run automated tests
3, Not a good practice to use maintenance window for this purpose
Thanks for getting in touch, this sounds like a really interesting situation! Your quite right, using maintenance mode is a way to approach this, but as you mentioned it is a bit of a heavy-handed approach that will prevent all deployments in that window.
Currently there is no first-class way to do this in the Octopus UI, but we have a few options that might work for your scenario:
Manual intervention with a run condition
One approach is to create a manual intervention step at the top of your deployment process, scoped to your QA team to approve - and then create a run condition on that step so that it only runs within your “scheduled window”. This would mean the manual intervention would only block your deployment during the scheduled window, and would be skipped at all other times - thus preventing deployments to the QA environment. (You could also explore a custom step template to bundle up the behaviour)
Note: If your server isn’t running in the same timezone as you are you’d need to work out what the scheduled window would be on the server time and use that for the run condition.
Automated permissions
Another option would be to create a new Octopus project with a script step to invoke the Octopus server API to remove permissions from your development team to deploy to the QA environment. You could then schedule this project to run every day at a specific time at the beginning of your scheduled window. You could then create a second project that restores the permissions, and runs at the end of the window.
Heads up: if you’re not already on 2019.1 or higher, the permissions model will be changing - so any scripts you write might need updating after you upgrade.
Either of these would solve your problem: if you have only a few projects to control, the manual intervention can be added on a per-project basis. Alternatively if you wanted to do this on a server-wide scale, the permissions option will affect the QA environment across all projects.
Hopefully this has helped! I’ve linked out so some relevant docs pages to help you get started. If you get stuck or have any further questions, let me know!
