Interesting discussion the other day about automation as a workforce multiplier. Does automation cost more to first set up? Usually. But after the third or fourth time you use that automation it pays for itself and after that it rapidly becomes a force multiplier for your team in order to be able to do more with less. The argument that automation provides a rapid ROI is pretty well established.
But the discussion also centered around who should be responsible for automation. Are developers responsible for automating their own builds and deployments? I would argue no. In small shops where resources are scare this may just be a reality of the job, but larger shops will benefit multi-fold by having a resource they can rely on to help get their builds automated. By creating a Center of Excellence around an automation group you reap the benefits of:
- Standardized automation processes: if the same group is responsible for every automation, the chances of divergence from the standard is smaller because there are less chefs in the kitchen.
- Reusable components: within each environment there are usually a finite number of steps in building and deployments. Creating an automation group allows better control over centralizing PowerShell and other scripting libraries that can be used over and over on multiple projects.
- Gatekeepers: having additional eyeballs on the delivery pipeline and how code moves through it is never a bad thing. By enforcing specific standards in how the code is structured and delivered so as to be automation friendly, your automation group can help make sure that code being delivered meets a certain minimum standard before passing through the automation gate.
- Continuous Learning: devOps is becoming a hot topic and with that tools are being created and updated on a weekly basis. Having a group dedicated to supporting your automation tools ensures you have a better chance of being up to date on best practices and Best of breed when it comes to automation tools. More importantly, these tools can be rapidly integrated with your automation processes and allow the company to quickly reap the benefits of their investments.
- Security: those of use who are automating processes almost always have production access. By limiting the number of people responsible for automating the pipeline delivery to production you reduce your risk surface. Every dev who wants to get their code promoted to production must follow the automated processes (which are hopefully also fully auditable).
So that was the discussion from my point of view. Mileage may vary depending on how diverse your own infrastructure is and if your delivery teams are siloed across various technologies within the enterprise.