release management: building an automated continuous delivery pipeline in kubernetes.
release management: building an automated continuous delivery pipeline in kubernetes.

Every release comes with a certain uncertainty: will the desired operating environment accept the developed code? Or does it take a long time to fix errors before the application is available to users? In fact, the release process is full of possible sources of error that need to be eliminated.

Release management is therefore an important part of software development today and is currently becoming more and more relevant. In order to make the sequence of releases as efficient as possible, automation solutions are increasingly coming into focus. The following article shows what a corresponding model can look like.

release management in the context of DevOps.

The release process can be described with the following brief definition, which includes the two essential aspects: A software release artifact is put into operation within an existing production environment. How successful the commissioning is depends on both sides. The release management has the task of specifying the steps in the release process and of ensuring the quality of the code and documentation.

If software development works with Scrum, release management is included in every sprint. Instead of "release", however, "increment" is used in this context. Ultimately, the aim is for each sprint to produce a functional product at the end. However, agile methods do not take into account the specific requirements of the operation. To better accommodate these, the Scrum Institute proposes a cross-sprint release plan that is comparable to the backlog.

release management runs in iterative stages.

The artifacts that are built via a classic CI pipeline and have successfully passed the first stages of the test pyramid are automatically versioned and assigned to the first stage. If the CI pipeline can only run up to unit testing, this first stage is capable of validating multiple components in an integration or end-to-end test. If the test was successful, the quality gate of the stage was passed and the components are assigned to the next stage.

This procedure can be repeated as often as it makes sense. Ultimately, it always leads from the Dev and Test Stages to the Preprod and Prod Stages in the same process. Thanks to the configuration management integrated in the artifacts with Infrastructure-As-Code and versioned environment properties, the stages are automatically and verifiably correctly configured by a release.

conclusion: automated releases make DevOps practical.

The goal of a true CI/CD pipeline is to make the transition from software development to operations completely seamless. With the connection of DevOps, Git (GitOps) and Infrastructure as Code, this ambitious goal comes a lot closer to reality. The operations team hands over the environment configuration to the cloud environment, so the entire process runs in the cloud. Versioning, installation and testing run automatically. 

However, this is rarely the case in practice, as there are usually still certain personnel and organizational hurdles. In addition, continuous delivery can only exploit its full potential with a high degree of automation. This can be achieved with the appropriate technical expertise and practical experience, but this is precisely what many companies are lacking at the moment.