Before we define DevOps let’s understand the software development landscape changes in the last 10 years for context. Before the advent of cloud computing we typically had two separate divisions within the engineering or information systems department.

1) Developer/engineering (Dev) teams 

2) operations (Ops) teams of system administrators, DBAs, network administrators.

Developers were responsible to write working code and when it was time to ship they would typically check-in their source code into a source control system and at the very most support a release to a “developer” environment. A release manager may work with the Ops team which then would coordinate releases between various environments like “UAT”, “Training” and then finally “Live”. We highlight a few challenges that this approach creates.

• The process tends to create silos between the Dev and the Ops teams.
• The release process is at odds with Agile software development principles of frequent incremental software delivery.
• Configurations to software can vary between different environments and typically Sysadmins were not the most knowledgeable on those.

Enter DevOps, a practice that emerged with cloud computing and agile software delivery. DevOps is a set of practices intended to reduce the time between committing a change to a system and the change being placed into normal production or going live, while ensuring high quality.  This helps in

• Developers aiding in the process of delivering software efficiently.
• Improving quality of the software delivered.
• Creating faster feedback loop so smaller changes can be pushed down the delivery pipeline without a big overhead.

DevOps activities are performed throughout the various stages of the software development life cycle. In the figure below we show DevOps initiatives that can be undertaken at the various stages.

We list and define some of the fundamental DevOps practices.

Also called as programmable infrastructure is a practice where we orchestrate and automate activities such as server provisioning, build, configuration settings and software deployments.  The automation is done in code that lives within the version control system.  This code is not “scripts” but it is actually proven and tested software written usually in a high level programming language or declarative programming language.  Tools such as Ansible, Docker can be used to define your infrastructure as code.

This is the process of integrating the code that is checked-in with defined unit and integration tests to ensure the quality of code delivered. Code commits are made earlier on and often. These commits will trigger a build and deployment to a set of “canaries”. Automated unit and integration tests are run on these instances. If there has been any significant regression with the delivery of the new build, These changes can be rolled-back. The automated unit and integration tests are also evaluated and “flaky” or “unwanted” tests  are removed so the tests do not take more than a few hours to run.

Not to be confused with continuous deployment is the actual capability of an organization to deploy code within the various environments taking into consideration the configuration settings that are unique to each. This is a required practice for DevOps. The capability to deploy software at any given time to any given environment as needed is a “must-have”.

Customers like Ensemble have saved on development cost from the efficiencies that we helped create with DevOps. Interested in learning how?