A self-organizing team at work, everyone is dealing with their tasks, beginning to end, in harmony and without any trouble. Is something like that possible in the world of software production? It seems so.
A typical scenario when working on a big software project in enterprise IT environments goes something like this: the delivery deadline is fixed and there’s no budging. The development team is running late due to unclear demands, as they see them, followed by too much work for the given deadline, not to mention the constant changes in definitions. Business guys are agitated since all the functionalities clearly won’t be ready on time, and they made promises to clients, the market, and everyone in between. Activities are cut that – supposedly – only waste time without visible gain, such as integration testing. Software launch in a production environment, which is the only somewhat stable element, lasts an entire weekend, and you can’t tell if everything will fold into place on Monday morning. You reach the first day of production, which is also the first real test of functionalities, in photo finish. No one even mentions performance testing or high system availability, but everyone is so scared of the new version with fixes of the most obvious bugs, which is likely due the very next day.
The paradox is that the development team, the business team, and the system team all give their best and organize their parts of the work the best they can, but the whole process is still rough around the edges.
In other words, everyone is trying hard, but the results are still elusive.
Does it have to be that way? No it doesn’t, and the answer comes in the form of DevOps, a handy name for a cluster of ideas, concepts, and activities aimed at simplifying the building, launching, and maintaining systems that are complex and changeable by nature.
DevOps is not a new concept, both in terms of time and content. Crisis rooms have always been formed, where everyone, from the development team to the system team, would sit all night long, managing the launch of big software projects. The problem is that such crisis rooms would be organized only after the crisis already threatened the project big time. Nowadays, when agile and lean methods have been widely accepted in software (and not only software) development, they become expanded with the “Ops” part, forming an integral discipline that – and the raw data clearly indicates it – significantly improves the satisfaction of all participants in the production process: from the client to the development and the system administrators.
What does the raw data tell us?
Puppet Labs Inc. is a company that deals with the automation of IT environments, and it has been conducting research for years already that it later publishes as a State of DevOps Report. The numbers for 2015 are anything but boring.
High-performing IT organizations deploy finished and tested software 30 times more frequently. Apart from that, source code commit is 200 times shorter, there are 60 times less problems, and when they do occur, they are solved 168 times more quickly. Imagine an IT organization that needs six to eight weeks to implement something and that launches new things in production once a week. And now imagine an equivalent IT organization that needs 60 to 90 minutes from commit to production, five to ten times a day. Once a line of code is written, it is practically instantly compiled, tested, and launched. With its ancient approach, the first company simply doesn’t stand a chance.
Three quarters of the companies that took part in the research have up to 2000 employees, and 87% of the companies have 20 or more servers in their infrastructure; it’s not something that easily translates to how things work in Croatia.
Based on the abovementioned data, the Puppet Labs team concludes that a high-performing and well-organized IT department has real business value and that it also significantly contributes to the performance of the entire organization. In other words, organizations that consider IT the initiator of business activities instead of strictly operative cost achieve visible advantage when compared to their competitors.
What are the concrete steps?
You don’t buy DevOps, you build it.
As well as the enterprise architecture or one of the agile methodologies, DevOps is also mostly a matter of internal culture and attitude towards the process of software manufacturing. The basic problem is eliminating the barrier between development and operations – to put it differently, nothing particularly positive will happen until the production database administrator keeps asking himself why they need him at the very beginning of the project and not when it’s all done and ready for launch. Once it becomes accepted that everyone equally partakes in the process of software manufacturing, we can start thinking about concrete steps.
Let’s say that the idea of DevOps has clicked in your organization and that you’ve been tasked with arranging the process of software manufacturing. What is the recipe? Is it even possible to define the recipe of introducing DevOps? The answer is, of course, yes and no. As much as this concept is related to the change of internal culture and method of operating, certain concrete technical steps can be identified without which DevOps makes no sense.
The first step would probably be to bring the development team (Dev) and operations (Ops) to the same table in the earliest stage of the project, that is, during the devising and design of the software product. The logic behind this step is the fact that the end product – software – will have to be launched in a certain environment. Also, servers exist for a useful purpose. We can’t allow the development team to program something and hope for the best, for it to actually run on production servers, while the system team don’t even know what lies ahead.
The cooperation of the development and operations teams will yield the process of build and deploy of the manufactured software. We want not only this process to be automatized, but we also need the scripts and the configuration of the environment to be deposited into the repository along with the “real” source code. Everything that is done with the program source code (versioning, etc.) has to also be done with the execution environments. Conducting these two steps alone moves us far into the introduction of DevOps.
Furthermore, we want to make it easier for the development team to test products in an environment that is as similar to the production environment as possible, and we also want to know that the end product will be able to be installed in production without any issues. Dev and Ops teams will define and enable the creation of server environments that will be very similar to the target production environment. Also, the development team will be able to launch (and destroy) these environments according to its needs. Virtualization is necessary for a successful realization of this idea.
The automation of all forms of testing is the logical next step, from checking the validity of the source code (“Yes, it’s compiling, let’s move on.”) to launching unit tests and regression testing to performance testing.
Next step – enter the DevOps support platform, that is, a cluster of tools or maybe a unique, integral solution that sits aside, recognizes the commit in the source code repository, and automatically starts the build, the launch of the appropriate execution environment, the installation of the end product into that environment, the automatic launch of tests, and informs all the interested parties on the results of the activity.
If all these steps are done well, we’ll have a ready-made product executed in an almost-production environment, tested and ready for operation, with product launch reduced to a single click.
What next?
Let’s Go Together, Right Now. IT needs to think deeply and ask itself: “How can we, as participants in the software manufacturing process, join hands in making this process easier, from the business request to production?” A good start is to form a joint development-operations team, and then to automatize everything. And afterwards? Launching new functionalities every… why not, every 5 minutes.
