Control who can deploy to production
Octopus Deploy provides the most value when it is used by your whole team. Developers and testers might be allowed to deploy specific projects to pre-production environments, but not production environments. Stakeholders might be permitted to view certain projects, but not modify or deploy them. To support these scenarios, Octopus supports a permissions system based around the concept of teams.
Control who can make production changes
If you would like to empower your team or decrease the workload of the release manager, you can grant permission for individual team members to push to various environments. For example, testers could be empowered to push to testing environments or certain devs or team leads could be empowered to push to dev environments.
Ensure releases have been tested prior to production
Use Lifecycles in Octopus to define the phases in your deployment process, and ensure that releases can't be deployed to production unless they've been tested first.
A complete audit trail
Octopus leaves behind a full audit trail of who did what and where, and captures diffs of changes made to configuration variables or deployment processes.
SOX & PCI-DSS compliance
The permissions model and auditing in Octopus help to maintain separation of duties and visibility over production changes, helping to meet your PCI-DSS and Sarbaines-Oxley requirements.
Active Directory integration
Use groups in Active Directory to manage the teams users are associated with, giving you a central, standard place to grant and revoke deployment permissions.
You might also like...
Currently updating a deployment process in @OctopusDeploy. I forgot how easy this was to use, everything just makes sense.— David Swindells (@d_swindells) January 30, 2019
Tools like @OctopusDeploy can be great in enabling culture change, we've been able to scale and improve our configuration story since we started using it.— Neil Chalk (@_neilch) July 19, 2018