If it’s not automated, it’s not done. Changing your approach from “implement now and automate later” to “implement means automate” will take you a long way down the road to Continuous Delivery.
The benefits of IT automation are fairly well understood – lower costs, higher reliability, and better performance. There is a popular saying in the tech world, “if you have to do something more than once, automate it.” This principle – often called DRY for Don’t Repeat Yourself – should be a core mantra for any IT organization. The key question, therefore, is not whether to automate, but when to automate.
Automate First or Pay for It Later
At Ten Mile Square, our view of automation is quite simple: Automate first. Often there will be the “task being done,” and, while completing that task, there’s the thought that “we will just automate this later.” If you know you’re going to automate already, then making automation into a separate, later step just adds to the workload and cost. Write the definition of done to include the automation. Most of the time, it will take several iterations to get the task done anyway, and the automation will not only save time later, but will also lessen the time to complete the task.
What happens when you don’t automate first and continue to develop features without automation instead? Once a development task is done, the pressure to add new features still persists. There is no good time to “stop and automate.” Four bad things can happen:
- Servers or virtual machines become “artisanal.”
- Deployment procedures start to involve running multiple non-idempotent scripts that break down or require manual intervention.
- Refreshing an environment takes months at a time.
- CI/CD pipeline looks like a long, hopeless road of manually executed jobs.
At this point, there can be so much automation-related technical debt that it can derail product release cycle, adversely affecting the business side of the company. This is usually when we get called in.
Creating Confidence Through Automation
We have tackled many Continuous Integration/Delivery (CI/CD) challenges at both the enterprise and departmental levels, and, no matter where we go, our clients always want one thing: Push button automation that gets built and delivered with a positive business impact. Our clients also believe that they can ”automate” once, and then they won’t have to do it again for a very long time.
In reality, all development or deployment efforts are iterative and repetitive tasks, and should be written as automation from the onset. This frees people from doing those tasks manually and makes it significantly easier to introduce new features and incorporate new technologies.
When we work with our clients on automating their current tasks, the work almost always includes five, important deliverables:
- Building full lifecycle CI/CD pipelines
- Modernizing supporting tools and infrastructure
- Creating custom configuration management databases (CMDB)
- Untangling monolithic dependencies among components.
- A lot of knowledge transfer that enables our clients to full embrace and realize success through automation.
Once reliable automation is in place, entire IT teams become much more confident. It becomes easy to rebuild a server that fails, because the build process is infinitely repeatable. Automation-driven teams can run multiple deployments daily and can provision nearly identical environments for development, QA, and production without fear of failure or unexpected inconsistencies. The business is rarely affected by IT outages, and the relationship between IT and its business stakeholders improves.
The Philosophy of Automation
Through years of implementing and coaching clients on CI/CD, we find that automation-driven deployment carries very similar philosophy and benefit as test-driven development. It is crucial to make sure your code, processes, and delivery mechanisms are all assets that are buildable, repeatable, and transferable. In other words, avoid accumulating technical debt and create CI/CD pipeline automation in parallel with other development efforts from day 1 of the project cycle. Having such implicit automation development at the start of a project gives your team the ability to develop a reliable infrastructure, deploy frequently, troubleshoot with confidence, and build a baseline for measuring performance. Finally, it requires fewer resources to enforce a CI/CD mindset in an organization, especially at the beginning of the hiring/on-boarding process, as compared to fixing a broken culture.
The False Danger in Automation
We often see employees that are afraid to “automate themselves out of a job.” We recommend that managers encourage engineers to take the initiative to learn automation best practices and allocate adequate amount of cycle time for implementation using those new techniques. In particular, IT Managers should identify “key” employees who are currently viewed as “constraints,” because they are the sole source of knowledge for a process that should be automated. Emphasize that there’s plenty of more interesting, higher value work to do, and the faster you automate one task away, the sooner you get to more interesting tasks. Employees who can automate and document all their tasks in a way that enables other qualified team members to execute and troubleshoot them can free themselves up to handle higher priority tasks, and enjoy their vacations more, too. These employees multiply the efficiency and capability of their entire team.
There are several powerful configuration management tools on the market. We named this series “Ansible State of Mind” because of our recent success using Ansible as a configuration management tool to help our clients implement world-class CI/CD processes. This 5-part series documents our experience with CI/CD and automation using Ansible. We’ve started here at a 30,000-foot level, and, by the end of the series, we’ll be drilling down into a nitty-gritty details of a successful Ansible implementation.
Stay tuned for part 2 of the series: The Yellow Brick Road to Automation.