Continuous Releases Or “unfinished”: How Often To Release Updates Of Your Product

There are only two basic approaches to the issue of new versions of the product. You can accumulate a lot of new features and fixes bugs in big releases that come out a couple of times a year, and you can fill the updates on production as often as possible — several times a week or even in real-time. The second method is called Continuous integration. In recent times it is becoming increasingly popular.

His PR even the President of Sberbank German Gref, who recently became a passionate Evangelist of agile approaches. However, large releases has its advantages, and many are quite successful and innovative companies are using their. Let me remind you how looks the process of developing. In both cases, it consists of indivisible units, which is commonly called a ticket or stories.

A ticket can be a new functionality or a bugfix. In a large release entirely developed tens and hundreds of tickets, followed by a full (regression) testing of all product. If testing is completed successfully, the release is available on production. In continuous integration, every ticket is implemented and tested in a separate “sandbox” branch.

After completed the review of code changes, as well as manual and automatic tests, the ticket is considered completed and is poured into the master branch. Thus, the master is always a version suitable for release. It can be put on production every week, day or even automatically with each new ticket. We “Moysklad” switched from large releases to the continuous release of updates.

Ill try to compare the advantages and disadvantages of both approaches, we encountered in practice. Stability. In the product is critical for business stability, and I mean not only the quality but also the absence of changes in the interface. Each update existing functionality is a bit shaky for normal users, most of whom dont want any changes.

They find it easier to endure the stress a couple times a year than a series of small changes that occur constantly. Handling. The large release is planned date by which it needs to be released. The backlog from it shows how bad things are.

Perhaps it can be ahead of schedule, but that I have not seen even once in my life. In need of a big release can be thrown out certain functions that interfere with his willingness, but on the whole, the planned availability date disciplinarum. On the other hand, processing and weekend work that accompany the race schedule — additional stress for the team, which is not always useful.

PR-effect. Big update — this event is a great infopovod. It can be nice to announce, to write articles, book reviews, initiate discussions in social networks. On the basis of the news “in 168 update during the year we have slightly improved the print invoices” it is difficult to launch a massive PR campaign.

Delay. In practice, we are constantly faced with the fact that the implementation of one or two complex functions were delayed for unpredictable time. Because of this, we had to delay the whole release, which could have dozens of options and bugfixes. It was frustrating for bug fixes. Sometimes we had to release a openly crude releases only in order to put for a long time waiting for bugfixes.

Uncontrolled complexity. The simultaneous release of several new features has led to the fact that immediately after the release we received a large number of error messages. Work on them stopped the normal process of development for one to two weeks. Even worse was the fact that from the first glance it was often unclear what specific change caused the problem.

Slow response. After the release of a new feature we almost always get feedback — information about what you need to improve the implementation. Before critical issues were corrected immediately, and the improvements that we thought was useful, was planned for a new release. As a result, users received them only a couple of months.

At this point, they were already used to working according to certain patterns, which broke the next improvement. As a result, users were constantly unhappy, and the product has evolved slowly. Function does not wait for each other. I think that is the main advantage of continuous updates have been released.

Once tested a new chart for sales analysis, it gets to production. He did not have to wait for the readiness of the rights management of users and several dozen changes. Rapid response. If we release a new function and immediately understand how it should be improved, the changes go the next day.

When we decide to change the colour buttons to see how it affects conversion, a new option appears immediately, but not in next release in two months. In General, this process is much better suited for the model of lean startup and the concept of constant experimentation with the product change. The updates are clearly divided into platform and functional. The fact that problems require different fixes.

For example, if the platform changes, when changing a certain technology or interior architecture, you need to rollback to a previous version, then to calmly deal. Functional bugs in the release it is easier to fix quickly. With continuous updates we dont have tasks to do single-platform release and the other with new features. Simply share the tickets separately.

More resources to testing and release. It is really fully test the product manually twice a year, but doing it every day is impossible. It seems that for continuous releases have to sacrifice quality, greatly reducing the test. In fact, the decision is found and works fine — its automated tests. Their development and support need more time, but starting from a certain size of project, without them in any case impossible to do.

In addition to testing, there are still overhead costs to conduct the release. If placing new code into production servers is possible and necessary to automate, there is still the task of monitoring everything in order to users with a new Assembly. This problem is impossible to fully pass on the scripts.

The slide graphics. Now have no releases planned date, since in fact no own releases. We remain with a lot of tickets, and each of them has a rough estimate of the time of realization. Because a steady increase in that time for a day or two or week do not affect the other tickets, it is easy to overlook. Instead of one big project “to release release the 25th of may, were receiving hundreds of mini – and micro-projects as separate tickets.

Managing requires more effort and more experience of project management. After we switched to continuous releases, the frequency of production of the system increased by the order. From five to 54 for the same time periods in 2015 and 2016. It would be logical to assume that users are now less time waiting for patches.

Indeed, the median waiting ticket of the user from the inception of the support prior to the exit fix on production decreased from 17 to five days (average time — from 70 to 34). I think this is a very good result. Despite the fact that approaches to the issue of updates has its benefits, we generally are satisfied with their transition to the continuous release. It makes for a more dynamic development of the product, encourages automated testing (which in itself is much more reliable and efficient), and, I think, is better massturbate.

As you grow the number of developers and testers, namely continuous updates make the product development process more controlled.

Read more: startup mvp development

Leave a Reply