DevOps 101 - Automation

In my last few articles, I've begun the discussion on the 6 pillars of DevOps and have covered Management, Integration, Communication, and Collaboration:

The Fifth Pillar

Next on the list is Automation. Automation is defined as:

"The technique, method, or system of operating or controlling a process by highly automatic means, as by electronic devices, reducing human intervention to a minimum."

Back in the day when deployment meant copying code to the one server you had connected directly to the internet, you could get away with manual processes, but it was still fraught with potential issues. That is definitely not true with today's rats nest of wires, servers, virtual machines, proxies, load balancers, firewalls, and all the other components needed to host a scalable and secure network.

In the early 2000's when I developed iControl (F5's first web service based management interface), I saw the pain that developers and network ops faced when dealing with application deployment. I talked about this in my "DevOps - A Brief History of Time" article I wrote earlier this year. Developers needed a better way to get their code pushed to the end user and Network ops needed a better way to understand how the applications worked and trust the development team to be a part of the deployment process. I talked a lot about the brick wall the existed between Dev and Ops and that automation was critical in leveraging the talents from both sides.

Automation - The Glue That Binds Dev to Ops

It's taken over 10 years, but DevOps has been the catalyst to blowing up that brick wall and coordinating the two teams together. But, network ops would never hand the keys to the network kingdom over to the developers so something was going to have to be put in place that was testable, reliable, and free from the risk of fat-fingering a config option that could take down the network.

Automation is the key to providing the trust and reliability into the equation and acts as the glue that binds the two teams together during the production phase. Automation fits into all aspects of the deployment process including development, testing, deployment, and all of the sub-processes within. Care needs to be made to ensure that all components in your system can be automated via software integrations or APIs. The build system, the testing tools, and the network components (load balancers, firewalls, application delivery devices, security appliances, etc) all need to be able to be scripted or programmed.

When dealing with 2 or 2000 developers, tools are needed to ensure that the collaborative work done can be integrated with success to achieve the desired results. Continuous Integration is the process of merging all development code into a shared codebase on frequent intervals. Merges aren't complete with out validation to ensure the merge didn't break anything so integrated testing is also a critical component. When merges occur, automated tests are triggered so that the developers will know right away if their work needs a little bit more TLC . When check-ins occur to the revision control system, automated build servers compile the code and run the automated tests. In addition to functional testing, performance and optimization testing is also occurring during this process.

Build tools

For the system to flow together, a centralized build system is needed that will interact with the various test and deployment systems. Vendors/Tools in the "Build" space are

Automated Testing

Integrating testing into the development and build process both locally and at the central build server is done to ensure an issue-free code base. Tools in this space include

Continuous Integration

CI should occur frequently enough that no errors can arise in the compilation or testing of the code without developers noticing and correcting them immediately. Typical practice is to trigger a build every time code is committed to a revision control system, rather than periodic scheduled builds. To achieve this, CI relies on a code repository, build automation, build self-testing, commits auto-build, and having a replica of the production environment to perform tests. Vendors and tools in the CI space include:

Continuous Delivery

Continuous Delivery (CD) is the process of building a deployment pipeline where a set of tests are performed that must pass before a piece of software is allowed to be released. Teams produce software updates in short cycles to ensure the software can be reliably released at any time. CD builds on CI by adding regular deployments to production as part of the build process. A healthy CD process aids in accelerated time to market, improved productivity, reliability, quality, and customer satisfaction. Vendors in the CD space include:

It Doesn’t Stop There

Automation can take place at virtually every step of the application delivery process. A successful implementation of automation within the DevOps methodology will lead to better products and thus much happier customers. For those just tackling DevOps, start small by automating with scripts manual processes that are time consuming. Then move into software solutions that assist with the build/test/deploy areas, then look on how to tie them together. The hard part is going to be picking which solutions to use to achieve this goal but luckily there are many vendors and products in this space so it’ll be just a matter of you finding what works for your environment.

Published Sep 24, 2015

Version 1.0