Promotion-to-production policy

On the life cycle of software components, we explained in the previous post that today's DevOps approach needs a new phase in the development life cycle to control the performance of components (DevPerOps) and how they affect business objectives, by centralising the whole workflow in a continuous Performance Technical Office (OTR).

However, before components go into production, it is possible to set certain control rules to ensure that software components are promoted under set quality and performance standards: the promotion-to-production policy.

For a proper promotion-to-production policy, two basic components must exist:

1. A production release calendar that sets which days are authorised for promoting software.

   • Critical days will be agreed with the business on which no software can be promoted, except through an exception procedure that requires additional validation.

2. Runs of the software components in a reliable pre-production environment, so that the performance metrics of each technical component can be compared with its own previous runs.

   • It does not need the same data volumes as production, but it should cover as many real cases as possible.

With these elements, a production release procedure can be set up that checks the technical components before they are promoted to that environment.

The promotion policy takes the following elements into account and works from the following starting information, giving an OK or NOK to the promotion as its result:

• The application team must fill in a document with technical and functional questions, and attach a minimum number of runs in earlier environments with representative data volumes, as close as possible to the production environment.

• A central team with performance expertise will check that the technical component is optimal in terms of duration and consumption, detecting changes in behaviour compared with other versions of the element, and any bad practices in it, so that they are fixed before promotion.

• If everything is correct, the application team is authorised to put the process into production.

• Otherwise, the necessary changes must be made to the software.

• There will be exceptions to the procedure depending on the business. In that case, there must be a commitment to fix the component in production, as it falls within the provider's warranty (the component must be fixed within an agreed time).

This way we make sure that, as far as possible, new changes to the software reach production in the best condition. For this, the tests must be as close to production as possible.

Detecting performance problems in earlier environments also brings several benefits:

• Proactively fixing software inefficiencies while the software is still under warranty.

• Lower costs thanks to early detection of increases in consumption.

• Optimal running of software elements once they are in production.

• Identifying the applications and software providers with the most incidents, so they can get special attention.

However, it is in production that every possible case can be validated, along with how each element affects the client's main business objectives (costs, SLAs and response times), by applying a policy that reviews elements after they go into production: the post-implementation policy.