Time-to-Market as a trump card for the introduction of DevOps
Imagine a fantastic situation - the director of the company decides to implement DevOps. Himself, without pressure from techies. Without a compelling example of competitors. The management itself recognized that it is impossible to improve the quality of the product, predictability, transparency and repeatability of business processes in the development and implementation of software without DevOps tools.
Submitted? Happened? You have successfully passed the test for the richest imagination!
In fact, of course, everything is wrong. Most often, the leadership is not up to our IT shnyh things. Therefore, we have to convince. But how?
When raising the culture of communication between programmers and system administrators is given as an argument, you can easily run into a counter-argument: are you uncultured now, are you? Or they may even remind you of the costs that the company has already incurred a year or two ago, when you switched to Agile together. Is there a feature in IT every year that can promote processes in a revolutionary way?
As for improving the quality of the product, you can also give a hint. But be careful. Since the task to program without errors has not been canceled yet. Yes, no bugs in any way, but that’s why the company has a “whole department of testers”, isn't it?
The predictability of processes is generally such a subjective factor, which is difficult to justify and avoid jokes about Wangu and Nostradamus.
At the same time, if we are talking about a typical enterprise, then in such a company, most likely, there is already an established IT team. And this team in the old (except Agile) habitual rhythm works together for many years and is hardly eager to (again) change something. Everything suits everyone, except, of course, leadership. Which sees that in their software any errors constantly pour in, terms of release of new versions are displaced.
Of course, we can assume another option, when a person comes to the company with experience in DevOps, who clearly understands what the problem is and how it should be solved. And who is able to convey his opinion to the leadership. However, let's not hope for a miracle uncle.
And this many break. They begin to say that no one supports them, that it is impossible to introduce anything in this swamp and then simply go to another company where the cycle repeats.
It turns out a vicious circle? No, just gradually we come to the conclusion that with a business you only need to speak in a language that he understands - in the language of money. To do this, we get the trump card from the wide legs of the sleeves - Time-to-Market abbreviation. We need to show that thanks to DevOps, new versions of the product will be produced like hotcakes. And all the rest of the above benefits from the introduction of DevOps let's leave for the final presentation, which we will create for the director when everything works out. Many will say that this is too obvious. Not!
We need something that will take us a minimum of time and resources (after all, no one will allow people-months to be written off to introduce some DevOps and will not buy urgently new servers for us), but it will give a very tangible result (Time will be shortened -Market).
First you need to find a bottleneck, and it is always one (the first step in the theory of constraints of Goldratt). After the successful implementation of Agile (and all this makes sense only after the introduction of Agile), in terms of software development, they still need manual testing. Even with a pool of free hands, regression testing can take two to three weeks. And I know everything from how testers “love” to conduct regression testing.
So, we have determined that testing is the bottleneck. Then you need to start with its automation. Many will notice: easier said than done. Millions of lines of code have already been written, and it’s good if programmers covered at least something with unit tests. In fact, everything is not as scary as it seems. Experience shows that 80% of successful results in the form of a serious reduction in the Time-to-Market is achieved by 20% of the efforts. This is exactly how much testing automation costs in our case.
Quite a Pareto law, yeah.
And most importantly, you can start testing automation even before management agrees to allocate resources for implementing the remaining parts of DevOps. Such a small pilot project that can be done on its own in one or two weeks.
But at the same time, this situation gives us a chance to win a spectacular and, most importantly, quick victory. After which, with a positive attitude and blessing of leadership, you can already ask for money and resources.
Let's start with the fact that, for sure, your programmers are already using some server software for daily assembly. It can be TeamCity, or Bamboo, or Jenkins, - it doesn't matter. The main thing is that part of the automation is already there and it needs to be used, and if not, then it is easy to deploy in a day.
First you need to automate the smoke tests. And how to understand what to automate? Yes, just look at what you regularly broke when laying out changes over the past six months.
Next you need to create several tests to verify the work of the main business processes. How to define them? Ask a question to your analysts / directors / business representatives, with what a break in the office to the programmers, an angry director rushes in and sets the tasks with a raised voice.
A week, well, a maximum of two to create such tests. As a result - very fast feedback on global errors.
And while the project is in the proof of concept mode, you do not have to prepare the same automatic server deployment for testing and other bows, but do everything manually. This beauty can then be happy to do with the admins.
What it will lead to is not difficult to guess. Developers will immediately see (and correct) their mistakes. Testers will be spared from routine in the form of long and tedious regression tests. They will have a couple of days in order to test only those code points that were subject to editing. Yes Yes exactly. And if not, go back to the beginning and once again talk with analysts / directors / business representatives on the subject of business-critical processes.
Bottle neck, because of which there were major brakes, eliminated. Now it remains only to release a few new releases into the production environment, remove the statistics "was / was" and go with these figures to the leadership. Profit!
After such a convincing victory, you can already talk about the automation of the deployment of stands (at least for testing). Next, beg for funds for monitoring and other delights DevOps. It should be remembered that the other components of the system will no longer have a wow effect for business.
Example in the studio
At the end of the post, I think it would be appropriate to give an example of a successfully completed project on the implementation of DevOps, which was implemented by our company.
One major retailer has about 20% of the business in an online store. At the same time, it is necessary to react to the market situation and make the necessary changes in the software very quickly. And often. And high quality. Any jamb on the site can affect the conversion, the risks are expressed in real money.
To reduce the update time and improve the quality, a specialized autotest platform was created, on which the routine tasks of testing changes and regressing the site were automated. In addition, the process of interaction of the automated testing team with the development teams was built. This allowed developers to immediately identify and correct defects in the upgraded system, without waiting for the final acceptance testing.
Representatives of the retailer found the experience successful and decided to apply it to the rest of the software products.
And another small example, but already from the practice of one large insurance company. Before the introduction of test automation releases were released every six months. Not because the business demanded it, it just didn't work out more often. And the customer just wanted. So, two months after the start of the implementation of auto-test tools, the IT team switched to two-week release iterations.
Indicative enough to start doing this, isn't it?
Sergey Stramnov, pre-architect of the Jet Infosystems software solutions center