Consistent Policy Enforcement
What if the industry has been thinking about continuous delivery the wrong way? What if continuous delivery is not an extension of continuous integration, instead it is the concept of automating the rules that have been defined by your change review boards and exposing them to application teams early in the development cycle. You would automate your production delivery through policies eliminating the need for manual change review boards, which is the real blocker of being able to deliver continuously.
For example, you want to ensure that none of your EC2 Security Groups enable 0.0.0.0/0 to the public, or you want to make sure none of the Kubernetes Service ports are open on port 22. With Armory’s Policy Engine, you can deliver your application through the orchestration of build, provision, and deploy stages that are validated against these policies, providing teams the information needed to better understand the amount of risk necessary for this change. You can expose these rules in your non-production environments so application teams have visibility into the operational requirements as a part of the development lifecycle. You would define your pipelines to validate the policies required for production deployments, rather than the traditional trial and error approach. Evaluating policies is normally done with a manual ticketing approach. This approach introduces opportunity for manual error, and also reduces consistency since different people are assigned to different tickets, which reduces the overall safety of your production environments. Using a policy-driven approach minimizes the manual ticketing process, providing consistent application of policies across the organization.
Safe Deployments Require Automation
Armory originally viewed our Policy Engine as a way to provide gates for teams to stop the delivery of a risky piece of software or infrastructure. Therefore, we positioned the Policy Engine as a safety mechanism as teams implement continuous delivery. But blocking deployments at the last minute is the antithesis of continuous delivery and should only be done as a last resort. Instead, we now leverage our Policy Engine to inform application teams of missing requirements early on, in their non-production pipelines, allowing them time to fix their deployments before an official change review.
You can use the Armory Policy Engine to provide training wheels to teams of lesser maturity in the continuous delivery process, surfacing best practices earlier in the delivery process. As teams get better at implementing the policies in their development lifecycle, you can allow them to skip the change review process altogether, and deliver functionality straight to production. Imagine a world where change review boards only questioned exceptions to production deployments, rather than having to validate every production delivery.
What We Learned from Releasing the Policy Engine
Over the last 6 months, the Armory team has been querying teams and executives about their challenges pre and post COVID-19. We found an interesting correlation between enterprises and analysts that are struggling to define a category for software delivery automation due to the number of tools that companies use, while needing to provide self-service capabilities to their application teams. The delivery options range everywhere from manual, repeatable steps that are done via a series of tickets, to complete automation through declarative delivery with GitOps. The tooling choices seem to come down to the decisions of the platform architecture teams in conjunction with the operations and SRE teams. The problem every executive and analyst has described to us has nothing to do with the delivery of applications to non-production systems. Instead, it has to do with the critical nature of securing and automating the delivery of projects into a production environment.
Today, teams can deploy to non-production environments with limited involvement from the operations teams. This is normally due to limited security constraints on the environment to allow teams to experiment with different technologies and frameworks. Application teams gain a false sense of security thinking this will be consistent with the production environments. To deploy to production, application teams still require a number of internal processes, from manual ticketing processes to change review boards. This slows down the delivery process, as decisions are still made in silos with limited feedback to the application teams. Even when the operations teams give a green light for an application team to deploy to production, the security team can overrule their decision. Many teams stop innovating due to the frustration this process fosters. They are relegated to the maintenance of applications without the opportunity to experiment. This leads to a consumer perception that the company has stopped innovating, forcing consumers to seek alternatives from their competitors. Even worse, teams struggle to compete with existing offerings, requiring a company to reduce staff as revenue continues to decline. This is critical today as companies start to recover post COVID-19.
Conclusion
We currently have a number of customers that are using the Armory Policy Engine to begin their continuous delivery journey. If you work for a company that has concerns with consistent policy enforcement or visibility into policy definition, we would love to speak to you to learn more about your challenges. You can learn more about our Policy Engine on our website.
