Chaque version s'accompagne d'une certaine incertitude : l'environnement d'exploitation souhaité acceptera-t-il le code développé ? Ou faudra-t-il beaucoup de temps pour corriger les erreurs avant que l'application ne soit disponible pour les utilisateurs ? En fait, le processus de release est plein de sources d'erreurs possibles qu'il faut éliminer.
La gestion des versions est donc une partie importante du développement de logiciels aujourd'hui et devient de plus en plus pertinente. Afin de rendre la séquence des versions aussi efficace que possible, les solutions d'automatisation prennent de plus en plus d'importance. L'article suivant montre à quoi peut ressembler un modèle correspondant.
La gestion des versions dans un contexte DevOps.
Le processus de release peut être décrit avec la brève définition suivante, qui comprend les deux aspects essentiels : un artefact de version logicielle est mis en service dans un environnement de production existant. Son succès dépend des deux parties. La gestion de la mise en service a pour tâche de spécifier les étapes du processus de passage en production et de garantir la qualité du code et de la documentation.
Si le développement de logiciels fonctionne avec Scrum, la gestion de la mise en service est incluse dans chaque sprint. Dans ce contexte, on utilise toutefois le terme "incrément" au lieu de "release". En définitive, l'objectif est que chaque sprint aboutisse à un produit fonctionnel à la fin. Cependant, les méthodes agiles ne prennent pas en compte les exigences spécifiques de l'opération. Pour mieux les prendre en compte, le Scrum Institute propose un plan de release transverse au sprint, comparable au backlog.
La gestion des versions se déroule par étapes itératives.
Les artefacts qui sont construits via un pipeline CI classique et qui ont passé avec succès les premières étapes de la pyramide de test sont automatiquement versionnés et affectés à la première étape. Si le pipeline de CI ne peut aller que jusqu'au test unitaire, cette première étape est capable de valider plusieurs composants dans un test d'intégration ou de bout en bout. Si le test est réussi, l'étape qualité (quality gate) a été franchie et les composants sont affectés à l'étape suivante.
Cette procédure peut être répétée aussi souvent que nécessaire. En fin de compte, elle mène toujours des étapes Dev et Test aux étapes Preprod et Prod dans le même processus. Grâce à la gestion de la configuration intégrée dans les artefacts avec Infrastructure-As-Code (IaC) et les propriétés d'environnement versionnées, les étapes sont automatiquement et de manière vérifiable correctement configurées par une release.
conclusion : les releases automatisées rendent le DevOps pratique.
L'objectif d'un véritable pipeline CI/CD est de rendre la transition du développement logiciel à l'exploitation totalement transparente. Grâce à la connexion entre DevOps, Git (GitOps) et Infrastructure-As-Code, cet objectif ambitieux se rapproche de la réalité. L'équipe d'exploitation transmet la configuration de l'environnement à l'environnement Cloud, de sorte que l'ensemble du processus se déroule dans le Cloud. Le versioning, l'installation et les tests se déroulent automatiquement.
Toutefois, c'est rarement le cas dans la pratique, car il reste généralement certains obstacles liés aux personnes et à l'organisation. En outre, la livraison continue ne peut exploiter tout son potentiel qu'avec un haut degré d'automatisation. Cela n’est possible qu'avec l'expertise technique et l'expérience pratique appropriées, mais c'est précisément ce qui fait défaut à de nombreuses entreprises à l'heure actuelle.