DevOps, a term suggesting some sort of link between development and operations, has been a hit the last few years. Everyone talks about it, many want it, but, much like the agile approach, there are many views on what it really is. In this text, I am not trying to declare a single truth (which does not exist anyway) or convince you that DevOps can solve all your problems (as it will not). The main message is that even small improvements to the current situation will help and, besides time and enthusiasm, no major investment is needed.
Let’s take a brief look back in time. The early nineties gave birth to a new trend—the daily build. Considering the tools and technology of the day, having an application compiled, built, tested and ready for installation every day represented a small revolution. At the end of the day, all the changes recorded in the versioning system could be processed, unit-tested and subjected to static code analysis (using tools such as CheckStyle, PMD and FindBugs). Around the turn of the century, we got used to the comforts of continuous delivery that, besides building the application itself, included preparation of all the other items necessary for delivery—configuration scripts, incremental packages, etc. All this required a mature level of automation, various tools, configuration management, definitions of procedures and processes, etc.
Now, let me turn for a moment to another area often confused with continuous delivery—continuous deployment. While these approaches may seem similar, they reflect very different levels of organization maturity. Just because you are able to prepare your software for deployment daily does not necessarily mean you can simply deploy it into production (even automatically) any time you want. Continuous deployment involves more than just IT; it also involves the business side of the company and requires the detailed orchestration of all necessary processes. It’s not surprising that many organizations implement continuous delivery and leave the deployment process unchanged. In many cases, it is a very rational and satisfactory solution.
This little detour leads us to DevOps, presently the most recent step in the evolution that goes way past the capabilities of continuous delivery. Deployment into production rarely means the end of application development, and this must be reflected in the process. In this sense, DevOps is closing the software development cycle with the help of continuous monitoring and strong involvement of operations that provide further input for subsequent software development. DevOps should eliminate the well-known situation where the development team announces that their release is “perfect”, only the operations staff “don’t know how to deploy it correctly”, while the operations staff complain about the poor quality of the development.
In this respect, the DevOps approach is not only about tools and processes, but mainly about people. In the team working in DevOps mode, everyone has to take responsibility for the software product, no matter what phase a problem surfaces in. (No more “It’s them, not us”.) Frankly, some people may have difficulty adjusting to it, partially because, besides the responsibility, the work requires incessant searching for better ways of doing things and other improvements.
The basic principle of DevOps is to achieve the maximum level of automation attainable for each and every step, while individual steps are reasonably small and isolated, thus allowing their repeat use and quick fall-back in case of errors. Everything must be versioned and tested. And we don’t mean only the source code, but also supplementary scripts and, more recently, the versioning of the database model and configuration data.
From the operations point of view, it’s the automation of deployment that has key importance. The deployment process should be the same for all target environments, differing only in the level of configuration. The deployment into production should not be more difficult than deployment into the test environment. The term self-service is often used to describe the capability which allows any team member to use an application/tool to initiate the build of an application and its deployment into any target environment.
“That’s all very nice, but what is the price tag and what do I get for it?” Since we are talking about improving quality and simplifying development and delivery processes, we can reasonably expect a reduction in the time-to-market. DevOps also places high demands on quality assurance, therefore we can expect a reduction in the number of bugs and faster fixes, which implies lower costs both for development and operations.
If that question comes from the IT side, we can also mention the faster error feedback and operative delivery capabilities, giving developers more space for experimentation (which, especially in cases involving legacy systems, can reduce the backlog of changes).
When measuring DevOps benefits, we can focus on main four factors: the delivery cycle duration, the quality of deliverables, the cost of deliverables and the capability to experiment as mentioned earlier. The current reality is often the opposite: long delivery cycles, questionable quality of deliverables, high costs and fear of changes. DevOps aims to turn this around.
So, how can you get started with DevOps? The simple answer is “just do it”, but in steps and with a specific goal. In case of a new project, it can be simple. Start by budgeting days (in single digit numbers) for setting up the development environment (versioning system, continuous integration server, build process, a tool for static analysis, etc.). The best news is that for most DevOps functions you do not need to make any major software investments as there are many open source tools (with no licence restrictions) available. SVN, Git, Ant, Maven, Gradle, Jenkins, SonarQube and Bugzilla are just a few of them. And if you need to add some functionality, small scripts written in the language of your choice (such as Python, Groovy, Powershell or Bash) may meet your needs.
If you decide to introduce DevOps into a running project, proceed in small steps with a specific objective. Identify the area with the biggest problems. Is it the number of bugs? Start with the tests (Unit, GUI tests, etc.). Do you have a problematic build process or deployment into environments? Then start with the automation of package assembly, modify the build scripts, introduce the deployment pipeline, etc. Do not try to “break” all at once. The step-by-step approach is safer, and smaller changes give team members time to adapt and to start proposing their own ideas for improvements.
Even a small change can have a big positive impact. I recall one project, where the process of preparing the deliverable was a complex manual task. Despite the minute instructions, composing the software release depended on one particular person. As the acceptance deadline approached, the stress increased and the quality of packages delivered for testing declined, and no one could say whether the problem was the quality of the software or its deployment process. We needed certainty in at least one area. It was decided to automate the preparation of the deployment package—the application, scripts, documentation, etc. It took only two days to put the process in place, but after two smooth and error free deployments, the team regained their confidence and could concentrate on the software itself. In the end, those two days played a major role in the success of the whole project.
In the end, DevOps is not so much about tools and large investments, but about the will to constantly improve and not settle for the current situation. Today it is truer than ever that nothing is impossible (not even the automatic configuration of servers, disruption-free deployment, etc.), you only need to conjure up the willpower and to get started. Even a small change can tip the scales towards the success of your project.