When organizations start moving to DevOps, one of the first things they focus on is automation. It makes sense: Automated deployment tools are easy to explain, and implementing them usually shows value right away.
But speed isn’t the only reason (or even the best one) to move to DevOps and an automated release pipeline.
Stronger configuration management
Using infrastructure-as-code and implementing automated deployments gives organizations strong control over the configuration of servers, applications, and environments. Deployment scripts become living documentation of the state of each system, and they can be tracked in version control, tested, and reviewed.
Configuration changes are easily identified by comparing two versions of the script. There’s no more guessing how the application is set up or should be configured—just look at the code. Policies and approvals that require sign-off “just for awareness” can be replaced with code reviews and automated dashboards.
Repeatable, reliable deployments
Automated deployments mean that each time you run the deployment code, it will execute and deploy the application or system in the same way. That makes it repeatable and reliable. Typos and “fat fingers” are caught when writing the code, not while testing and troubleshooting a deployed system.
All the uncertainty is removed, and that lets you deploy new versions confidently. Upgrades are trivial, uneventful, and stress-free. If you need a system set up for a demo, you know it can be done easily. If you want to have parallel pipelines running or if you need to scale, it can be done automatically. And when you are done using an environment, you can delete it to reduce resource use and keep costs down, because you know it can be recreated when you need it again.
Idempotency and immutable infrastructure
If deployment code is idempotent, then when you run it back to back with no intervening changes, nothing will happen on the subsequent runs. You can set it to run every half hour or every five minutes—nothing will change unless it has to. If someone manually alters a configuration or makes a change without committing code, it will be reverted on the next run. This means there is no more configuration drift or unsanctioned changes to systems.
Infrastructure is immutable if you never install new software or configurations on top of old versions: Every version is deployed from scratch. There is no buildup of old versions or configration files just “lying around.” Access to change the system can be disabled for everyone except the automation deployment tool, so configuration drift again is stopped—no more developers and testers experimenting on a system and forgetting to revert it, and no more well-meaning system administrators saying, “While I’m here I’ll just tweak this setting.” Every deploy is clean.
Confidence
All these benefits of automated deployments lead to increased confidence in the pipeline and the release process. Automation provides awareness and visibility into the changes being made with the understanding that changes will happen as intended. The code will run over and over the same way: repeatably and reliably. And we have confidence that we can move faster because we know how the deployments will end up.
Originally posted on TechWell Insights
