With DevOps approach to software delivery being a decade old already, there is no doubt that it is the backbone of the modern IT industry. ITSvit.com, a Managed Services Provider with 5+ years of DevOps expertise, covers the reasons why DevOps is so great and how it revolutionized the way we develop software, run our infrastructure and interact with our customers.
Let’s take a look at a traditional software delivery lifecycle many developers of enterpise-grade software are too familiar with.
The customers (product users or owners) request a certain feature. It is added to a backlog, which is already full of story points to do, so the work on the new feature can only start in half a year or so. Once the developer finally gets to writing the code for this feature, he requires the design and specifications for it. It’s good if these are done already, as otherwise the developer just creates a ticket for a designer and product owner, and goes back to fixing bugs.
Once all the required information is available and the developer starts writing the code, it must be tested periodically. The developer creates a ticket for a QA engineer with a request to check the new batch of code and goes back to fixing previously found bugs. If a QA engineer is free at the moment and sees the request at once and has the needed testing environment at hand — he/she starts testing the new batch of code. If he/she is busy, it might take some time.
If there is no free testing environment available, the QA engineer must issue a ticket for the Ops engineer to deploy and configure this environment. Having the ticket issued, the QA engineer goes back to testing what he can. Meanwhile, the Ops engineer is tasked with keeping the production environment operational, and there is always something wrong with it. Thus said, if his head is not on fire at the moment, the Ops engineer sees the QA’s ticket and configures the testing environment and reassigns the ticket back to QA — and goes back to putting out the fires.
When the QA engineer can go back to this ticket and starts testing the new batch of code, the testing might succeed or not. If it does — the new batch must be pushed to the staging server for high-level testing of the new product version. If the code does not pass the tests, it is given back to the developer for bug fixing. Rinse, repeat.
Now multiply this by the number of developers, QA and Ops engineers working on the project — and you will clearly see the tangled mess that was the software development before the DevOps introduction. This mess was the reason that major enterprise software updates were released only once a year or two. And we didn’t even discuss the release process yet — those famous updates that crashed the servers for hours and days — younger developers don’t even know of them. Why? Because of DevOps!
With DevOps, the Ops, the QA and the developer work in sprints to deliver new feature versions every two weeks. At the beginning of each sprint, the three of them (or their Team Leads) discuss the plan o wok for the sprint and what must be done. Then the developer starts writing unit and integration tests for the future feature and the Ops engineer prepares the scripts for automated deployment of all the needed environments — so-called CI/CD pipelines. With these pipelines, submitting a new batch of cod to your VCS leads to the automated deployment of the needed testing environment to run the unit and integration tests. If these succeed — the code is automatically pushed to the staging server, if not — the developer is automatically informed. The whole process takes mere minutes.
The same goes for QA and testing on the staging server, and if all the tests are green, the new code is automatically pushed to production, without any headache for the developer, QA or Ops engineer. This boosts the team productivity immensely and reduces the time-to-value for new products by 90%, according to Puppet’s report on the State of DevOps of 2018.
Removing a ton of manual work and wasted time, reducing the number of bugs, automating the routine operations — this is why DevOps approach to software delivery is so great!