When Release is released?
How often do you hear the question: When will this release will released?
You will not believe how many people think that the “release” is released when it is deployed to production environment.
This is not always the case. Rather, it is a particular case, which is an exception to practice.
Much depends on the type of release. I recall that in general, releases can be divided into 2 types by distribution method: Pull and Push.
Pull - Release when the actor of the system decides independently whether to apply it to the update or not. At the same time, the actor is not necessarily a human being. In this role, other components internal or external to the system may act. The decision is made on the basis of certain metrics. It can be an event in the system, a planned calendar update, some external factors, etc.
A vivid example of the Pull release is when an application on your smartphone offers you to upgrade to a new version.
Push - Release that occurs regardless of the "desire" of the end user of the system Again, the end user is not always a person. In other words, at some point, the user of the system becomes available to new features or changes have been made to existing ones. The simplest example is changing the interface of your favorite web site.
Of course, the release can be major or minor. You can split releases into major and minor ones in different ways. In most cases, the business needs and architectural solution will dictate the rules of how they have to be divided within the project.
And let's define for whom release is released.
A simple case. Major push release. You have deployed some "component A" of your solution. The code is in place. The testing phase begins. Testing is organized properly and your component is covered by the autotests. However, for some reasons, additional manual testing is required. For example, a number of tests have failed and you need to double-check or simply your validation process assumes that one more validation step is when a representative of the product supports runs specific business flow (a kind of canary testing). Suppose also that the update is not available for other users/actors until it’s deployed J and the validation process is incomplete (you can simply block access to the resource, deploy to an offline server and validate there, roam the traffic with a loader, etc.) .
In this case, the release will be available for the validation team immediately after the deployment. But at the same time this release will not be available for other users. And (we can say this with a high degree of probability) the main beneficiaries of the release are just those users for whom the update is still not available. Once testing confirms that you can release the Kraken, “Component A” will be released for users. And there are cases when validation can take quite a long time. Especially when we are talking about canary testing (even not hours but in some cases days).
Moreover, in the case of Pull release, most likely you want to be covered by canary testing by a certain group of users of the system before making it available to other users of the system.
By this, we can say that “release of Component A” is released, when a set of features/updates included in this release become available for use by the WHOLE TARGET user/actor group.