I work at a financial institution and we have a lot of requirements around our approval process
- Developers can trigger deployments to Test but QA has to approve them
- Developers can trigger deployments to Staging but Lead Devs and DBAs have to approve them.
- Developers can request a deployment to Production, but the release manager, business owner, and web admin have to approve it.
- Developers can change the deployment process, as they have the most context around what is needed to deploy their application.
- We never want to have the possibility of approvals being skipped. However, developers can simply disable the step.
- We only want to approve once for all the component projects, not for each one.
The recommendation is to leverage the new Deploy Child Octopus Deploy Project step template to create a release orchestration project.
Step by step instructions on how to leverage the step template can be found in this blog post.
A few notes about this unique set up.
The first is Developers have edit permissions on all the child component projects.
But they cannot create or deploy releases in the child project
They cannot edit the release orchestration project. In fact, they cannot see the variables!
They can create and deploy releases for the release orchestration project.
But, when they trigger the deployment they cannot take ownership of the manual interventions.
All the approvals happen in the release orchestration project, and the components are deployed in order (Database, then Web API, then Web UI).
This approach allows for:
- Developers to have control over their processes, while being unable to change the approval process.
- Applications are deployed in the “right” order.
- Approvals happen in one spot.
- RBAC controls can enforce rules such as all child projects must go through the release orchestration process.
