4 Things You MUST Have in Order to Say You’re Doing DevOps

1. Continuous Integration (CI)

Every company that develops software should be doing continuous integration because it is the very basis and start of what DevOps entails. At a minimum, you should be building your software on every single check-in that a developer makes into your codebase. Ideally, your developer should have already run the software locally on their desktop or development machine before checking in their work. Once they check-in that code, there should be a system that first detects that a commit has been performed then checks out that code and compiles it with all of the work completed by developers. This is the very basic of integration points, verifying the new code works with all other code that has been committed. If the code compiles and passes all its tests (unit tests) then you can move onto integration tests with other systems. Usually, the additional integration tests are the result of a successful build and unit test run which would trigger the software to be deployed into an environment that contains the other tooling that your software might work with. Once this deployment is complete, a new set of integration tests would run to verify that both the software and its assumptions about the other systems it needed to work with are still true and still working. There are plenty of tools that can help you with this basic step. Jenkins, Bamboo, Hudson, uBuild, and others. These tools provide you the building blocks needed to trigger builds on check-in and to feed information back to the developers on success or failure of the build and test run. These same tools can be used to perform deployments as well, but we will get to that in a little bit.

2. Continuous Testing (CT)

So Continuous Integration is important, but it can be quite lacking when the code base does not have any unit tests in it. Face it, doing a build when there aren't any unit tests to run is just performing a compile, and to be honest, the developer should have performed at LEAST that much work to verify that their code would not break anything when they committed it. This is where the continuous testing comes in. Each and every change that a developer is making to the code base should have unit tests that represent how it was meant to work. Their work should likely contain the unit tests and some number of integration or larger story testing to prove not only that what they wrote works as expected but that what the developer wrote actually solves the abstract problem initially posed by the business. All of these tests should be able to be run automatically by the system when a code commit is performed or triggered to run manually by a user when there is an event or a configuration change that MAY impact how the system would work. The testing should be fast so that the feedback about the health of the system is equally quick. Large codebases of thousands of lines should likely have thousands of small unit tests that run in milliseconds to small seconds each that can help provide confidence that work to change the system did not impact any other functionality. This automation is a must to provide the confidence to do a software deployment whenever the whim strikes. Continuous Integration should execute the tests and provide that feedback quickly to developers and the organization.

3. Configuration Management (CM)

Now we have a build with runs and tests that provide sufficient evidence that what I am building is working, running, and meets the needs that were being described by the business. However, I may not yet have even deployed the running software anywhere, or entered configuration management. Today, It is exceedingly rare for companies to have one, or two servers running their business, website, and/or software. Even at relatively small scales, it is more likely that multiple machines make up the needs infrastructure for any software. With that in mind, it is important that the software being built deploy to hardware or vm’s or containers that have been built and configured with the same base things in mind. Enter configuration management systems. Things like Chef, Puppet, Ansible, etc.) are all systems that allow you to define the configuration of a target in code. Generally, this is where executives say - “… well, I have people for that…” the problem is that people are error prone, and they make mistakes that they may not even realize that they are making. The result is that machines configurations are slightly different. These slightly different configurations lead to inconsistent deployments and inconsistent end user results that may be hard to track down. Configuration management helps to address that by taking the human out and turning the configuration into code that can run through the same DevOps process as the software being developed. Configurations can then become testable and repeatable without error.  When configurations do not happen correctly, information is reported out that something has gone wrong, long before your end users are ever affected by the error. There are a number of tools in the space which all work similarly but have different execution philosophy and as such will impact how you implement them in the long run within your organization. Tools like Chef, Puppet, Ansible, Salt, CFEngine are all systems for controlling infrastructure and configuration. Tools like Fabric and other scripting platforms help integrate the platforms of CI and the artifacts out to systems that are controlled with CM.

4. Continuous Delivery (CD)

Now I have three legs on my stool. I have CI building and CT running tests against my built software, and configuration management (CM) verifying that all my machines of the same class (web server, db, etc.) are identically configured. So what is left? What is left is that if I have this level of confidence inspired by everything I have done thus far. I should be able to make my software deploy into production when all my tests pass. This is continuous delivery. Continuous delivery is having built the processes to deliver software into production and having the confidence built into the ways in which things are tested and the automatic feedback such that everyone can understand the quality of the code that has been developed as being good enough to deploy. Put differently - the CI, CT, and CM have provided evidence along the way that the work of a developer or developers is of high enough quality that if all the tests pass it should be ok to deploy right now. Continuous delivery is the automation to deliver whenever people have enough confidence to push the button that runs the deployment and its automation against the environment that exists.

The stool now has four legs and can stand on its own.

There are far more sophisticated ways that all four of these things can interplay with one another and recent technology in containers and other delivery mechanisms are enhancing this process every single day. We can help you implement these things in your organization - ask us how we have done this in lots of different types of environments to go from deployments per qtr, or per year to deployments per day with quality and safety.

image courtesy of: Arjen Bangma, Transnatural director (Own work) [CC BY-SA 4.0 (http://creativecommons.org/licenses/by-sa/4.0)], via Wikimedia Commons