DevOps is a set of concepts and a way of work that has originated from the Agile and Lean approaches to operations. It pertains to software development teams (Dev) and information-technology operations (Ops) working together to improve productivity, automate infrastructure, and continuously measure application performance. This is all to deliver more software solutions in a shorter period.
DevOps has also received an academic definition from three computer science researchers working at the American research and development center in Pennsylvania and the Commonwealth Scientific and Industrial Research Organization. Len Bass, Dr. Ingo Weber, and Dr. Liming Zhu have defined it as a “set of practices intended to reduce the time between committing a change to a system and the change being placed into normal production while ensuring high quality.”
Developers and system administrators are working together throughout all the stages of the development cycle. This includes the actual writing of the code, testing, and production support.
To better understand the differences this approach brings to the table, let’s take a look at what a normal development cycle means, from the actual code writing to the testing, implementation, and production. Then we’ll take a look at how this process is effectively transformed through a DevOps way of work and talk a little about the main principles the history behind DevOps.
The software development side of coding
Software companies are racing with each other to come up with new and exciting products or updates for their customers. The software starts with one developer or a whole team who write the code for new products, features, updates, bug fixes, and so on. In a non-DevOps working environment, the developer will not know if the code works until it is placed into production.
However, that takes weeks before the code goes into production. In between that time, they also have to take care of the next batch of codes in advance while also having that pending code in the back of their minds.
Also interesting: DevOps and IT Projects in the Real World
When a big chunk of code is eventually deployed into the production environment, the occasional error might occur. This means that developers have to stop what they’re working on and get back that code they’d written a few weeks ago to tweak it so no errors would occur.
Why the errors in the first place? It’s mostly because the development environment is somewhat different from the production environment.
The IT operations side of coding
The operations team is responsible for maintaining the production environment. That translates to dozens of servers they need to administer correctly. This is so customers and consumers will never be shut out of their favorite products and software.
When they’re not dealing with server problems, the operations team takes care of deploying new code in this production environment. Usually, things don’t go smooth, and little tinkering needs to be done for the code to properly fit into the environment. This is why code deployment is usually scheduled to happen once or twice a month.
Once the code is deployed, it’s the operation teams’ responsibility to make sure there are no errors and to solve them if there are. In this phase, an operations team member might feel a little frustrated that the developers have just thrown a bunch of code and now they have to deal with it and its many problems.
People asked themselves how to put these two teams in the same room and let them work better together. How do we bring them to learn to think alike and break down any misunderstandings of each other’s environments and share their responsibilities? This is where the DevOps idea happened.
Enter the DevOps team
The first major prerequisite for any DevOps team to work properly is a little shift in mindsets. They would work together to automate infrastructure, automate workflows, and measure application performances together. This is to improve the overall productivity and efficacity of the whole development cycle.
A DevOps team will start to focus on automation at first, from code testing to workflows and infrastructure. Their workflow will change. The developers won’t write a large bag of code and then hand it over to the operations team anymore. They will write small bits of code and these bits are deployed on the same day or the next.
They will fix all the bugs together. If the code is written in small chunks, then it can be deployed more frequently. This will improve the productivity and efficiency of the whole department.
One thing is clear: a DevOps team is better fitted to respond to market needs and deliver products on a larger scale. Instead of building software and configuring infrastructure manually, they work according to a configuration management code that would describe how everything should be built. One major change that a DevOps team will have to work on is implementing and adopting a discipline of application performance monitoring and optimization in almost real-time.
The history of DevOps
We can call DevOps an adopted child of the Agile System Administration movement and also a grandchild of the Enterprise Systems Management movement (ESM). The ESM arose to fame in the mid-2000s, and since then, a bunch of conferences and boot camps and guys talking about a better development process emerged.
The first Velocity conference happened in 2008, and it was all about web performance and operations best practice. This followed various important developer/operations collaboration examples of how a safer and rapid development cycle could be instilled. More professionals began to think about this new concept and how they might implement it in their workflow.
In 2009, the first conference named DevOpsdays took place in Belgium. An agile practitioner and project manager, Patrick Debois, founded the conference. In 2012 we had the first State of DevOps report, conceived and launched by Alanna Brown from Puppet. More followed, and the DevOps adoption began a real thing.
Tools necessary to implement DevOps
DevOps methodology cannot be applied without a set of tools that help automate and monitor the cross-functional workflow as well as aid the final delivery of software. In “DevOps language,” these tools are called “toolchains.” There are seven main categories of toolchains out there:
- Code development tools
- Building tools for continuous integration of new code and for maintaining the build status (such as Jenkins, Gitlab, Bitbucket)
- Testing tools
- Packaging tools
- Release automation tools
- Configuring tools that help with the infrastructure configuration and management (such tools are Terraform, Ansible, Puppet)
- Monitoring tools that help track application performance and end-user experience.
Overall, DevOps is a set of practices and methodology that promotes collaboration between developers and operations. This helps to innovate faster, to be more responsive to any business and market needs, to collaborate better, and release more frequent features and new code. DevOps starts with a new mindset, a whole new bunch of tools, and some skill-polishing in the middle.
Photo credit: The feature photo has been taken by ThisisEngineering RAEng.
Source: Len Bass, Dr. Ingo Weber, and Dr. Liming Zhu (DevOps: A Software Architect’s Perspective)