Sharing IT Best Practices with youSharing IT Best Practices with youIn the DevOps – Versioning article the term forward releasing is already mentioned. But much more is to report about this form of release management.
A S-CI is the description of an object that is managed by the DevOps development process. An S-CI assigns various attributes to describe the object or components. An S-CI may include the meta data of a third or fourth generation language, a SQL script, a database scheme or any other object that is required to bring an application to.
The idea for forward releases is that any S-CI rolled out in an environment and whose rollout has not gone wrong will no longer be restored. The reason is that more DevOps teams work with the same deployment pipeline. As soon as an already rolled S-CI is reset, all other S-CIs that depend on this must also be reset. While the disturbance may be marginal and the rest of the test cases just go well. Therefore, wait for a defect patch that accompanies the normal deployment pipeline. Forward releases prevents branching.
The forward release concept gives an alternative of branching. In this concept, the release management process is explained by the train metaphor as depicted in figure 1. This article described how this metaphor works.
The objects to be deployed are the packages that are deployed by putting them on the release train. A package is only allowed to get on the train if a valid ticket is shown. The ticket represents the valid test report. The toll gates of the DTAP street are in this metaphor represented by the rail road stations. The release manager is the train engineer. However, there are so many packages on the train that he cannot decided whether the train is allowed to run. He is assisted by the Release Management Team (RMT).
In Figure 1 more than one train is drawn. This is because of the fact that on each station one or more tollgate tests have to take place. Since the tests do take time, the train is not running from Development straight forward to Production. In fact, all the trains run at the same time but only from one station to the other. So, each period, let’s say two weeks, the following trains run: D-T, T-A, A-P.
The RMT decides whether the packages (stories) are allowed to get on the train. The RMT consist of the change manager, the release manager and the test manager. The decision is based on the train tickets, which are the test results of the stories and the authorisation of the related feature. However, the RMT has still to decide whether there may be conflicts between the stories or not. If a story is not put on the train, it will be placed in the depot of the train station.
Stories that are not allowed to go on the train stay in the depot until they are authorized and error free, rejected or fixed by a bug-fix that arrived by a new train.
Discuss with us about this article on LinkedIn.
DevOps Best Practices, ISBN: 9789492618078
Agile Service Management with Scrum, ISBN: 9789071501807
Mogelijk is dit een vertaling van Google Translate en kan fouten bevatten. Klik hier om mee te helpen met het verbeteren van vertalingen.