📜 ⬆️ ⬇️

Release the first version!

Introduction


Competently established and established processes are not for us! This is boring, when everything is already set up and works like a clock, but we must strive towards this. And after that, enjoy the work done and once again check how everything works well ...

It is very important what code gets into productive operation. It is important its stability and predictability. When using strict quality control regulations, the rate of implementation of the new functionality will certainly decrease.

In this connection, there are frequent situations when a sufficiently raw “development” code is supplied to the customer, after minimal testing. This entails many problems.

N.N.U


Imagine the usual situation in the project. The project is already six months old, it is still young and not very functional. Changes are made by the minutely distributed team. The customer requires a new functionality almost instantly after its implementation.
')
There is a temptation to use continuous integration, which is expressed in updating the customer’s servers with code from the main development branch.

Postulate 1: Code in the main development branch is unstable

In this case, the approach of updating the code at the customer will bring only problems. It is necessary to fix the code slice, which is expressed in the version, and install only the version code at the customer.

Of course, you can argue on the postulate 1 that the code in the main branch is stable. Yes, this is possible if there is sufficient coverage with unit tests, extensive functional and integration testing is carried out. The QA department is very harsh. The code is developed in the branches and transferred to the main branch only after thorough testing.

In many projects there is no quality control and testing department, often there are no tests. All development is carried out in the main branch. This is the postulate 1 for such projects.

Release version


Your code is barely compiled, there are a lot of errors, fatal and not so much, the customer begins to turn gray on the type and behavior of the system? Release the version!

Release a version of this under-product. Announce the version to the customer and outline the approximate release date of the next release. It acts magically. The customer wants a new version of the product, the developers have an entire iteration in order to write code and correct errors without the customer's screams and pressure.

Motivation


This is about the release of the first version. It is the most important, since then the whole product will be built on the basis of it. Without it, there will be no other versions of a successful product. And the team becomes calmer for their work. Of course, it is important after the release of the first version not to lose the pace and in the shortest possible time to release the second version of the product, more stable and even more desired by the customer.

pros


From the positive aspects of the release version can be identified:


Minuses


There are also disadvantages of the release of the first version in the early stages of working on the project:


I do not exclude that each reader will be able to bring on a couple more pros and cons of the release of the first crude version.

Conclusion


Most companies do not find a person with a post "build-master". With such a person, the process of releasing versions proceeds much easier. But even without it, you can release versions of your product. Well, the very first version is only the beginning of the long life of the program.

In addition, the release of the version creates interesting and fun traditions in the team. The simplest of them: going to the bar, evening board games, cinema sessions, online games with the whole team.

NNU - Zero Initial Conditions.

Source: https://habr.com/ru/post/152895/


All Articles