Oui, en DevOps, on fait la distinction entre déploiement et mise en production. Une mise en production consiste essentiellement à cliquer sur un bouton pour rendre une fonctionnalité accessible aux utilisateurs. Mais même avec deux déploiements par an, je dois encore patienter pour obtenir des retours.
En DevOps, nous privilégions des boucles de rétroaction courtes et établies pour résoudre les problèmes liés aux erreurs ou aux divergences d'interprétation dès leur apparition. Il s'agit non seulement d'une question de bon sens, mais aussi des trois axes du DevOps :
- Première approche : une pensée systémique et la mise en place d’un flux continu et rapide – de l’idée au client
- Deuxième approche : Renforcer les boucles de rétroaction
- Troisième voie : Instaurer une culture d'expérimentation et d'apprentissage continus
L'apparition et la reconnaissance des problèmes peuvent être retardées. Si un malentendu survient lors d'une discussion, il peut facilement s'écouler des jours, des semaines, voire des mois avant que nous ne le reconnaissions (si nous le reconnaissons un jour).
Afin de concevoir des logiciels et des produits conformes à nos normes de qualité, il est donc crucial de mettre en œuvre des mécanismes permettant la détection rapide des problèmes.
Il existe de nombreuses possibilités méthodologiques et techniques pour cela, telles que :
Mais la meilleure option est :
Coopération!
Applications d'évaluation GitLab
Comment ça marche
Et c'est précisément l' GitLab Review : favoriser la collaboration entre les équipes de développement, les services commerciaux et les clients, et raccourcir le cycle de retour d'information.
Les applications de revue GitLab sont des déploiements directement liés à une demande de fusion (l'équivalent GitLab d'une demande d'extraction). Les demandes de fusion créent également une branche de fonctionnalité. Une fois une modification validée sur cette branche, GitLab (sous réserve de la réussite des tests automatisés) la déploie dans son propre environnement (dynamique).
Vous avez ensuite la possibilité de tester la modification dans l'environnement dédié, de donner votre avis et de tester immédiatement les corrections nécessaires. Difficile de faire plus court.
Une fois la modification approuvée, GitLab fusionne les modifications de la branche de fonctionnalité avec la branche principale, nettoie l'environnement dynamique et ferme la demande de fusion.
Avantages
- La détection précoce des erreurs et des malentendus
permet aux experts ou aux clients de vérifier immédiatement les modifications. - Collaboration transfrontalière :
en s’appuyant sur la demande de fusion, des personnes issues de différents départements/équipes/entreprises et possédant des compétences différentes travaillent ensemble. - Réduction des risques liés aux mises en production :
Connaître les fonctionnalités qui ont déjà été testées réduit le risque d’erreurs lors du déploiement ou de la publication de la branche principale. - Tests continus :
les nouvelles fonctionnalités et les modifications sont testées et vérifiées en continu, de manière automatique et manuelle. Cela permet d’éviter les tests fastidieux et frustrants lors des phases de test raccourcies.
Exigence
Votre application doit être une application web et vous aurez besoin de l'infrastructure sur laquelle les applications de révision seront déployées. Cela inclut un cluster Kubernetes.
Vous n'avez pas besoin d'argent (du moins pas pour les licences GitLab). Des applications de révision sont disponibles pour tous les niveaux de licence, de la version gratuite à la version Ultimate.
La méthode la plus simple consiste à utiliser la fonctionnalité Auto DevOps. Lorsque Auto DevOps est activé, GitLab reconnaît votre langage de programmation et, en se basant sur celui-ci et sur des modèles des pipelines par défaut pour compiler et tester l'application.
Au fait : les configurations Auto DevOps peuvent être adaptées à vos besoins.
Guide rapide des exigences minimales :
1. GitLab SaaS ou GitLab sur site (par exemple via notre hébergement GitLab géré)
2. Un projet GitLab (dépôt)
3. Cluster Kubernetes avec Ingress
4. Agent GitLab dans un cluster Kubernetes
5. Dans les paramètres du projet → CI/CD → Variables
- KUBE_CONTEX avec valeur
- KUBE_INGRESS_BASE_DOMAIN avec l'adresse IP de votre cluster Kubernetes
6. Activez Auto DevOps dans votre projet GitLab
Pratique
Voyons ensemble à quoi cela ressemblera une fois les travaux terminés.
Dans GitLab, je crée un nouveau projet basé sur le modèle NodeJS Express. Cela me donne une application web minimale.
Tout d'abord, j'active Auto DevOps dans les paramètres CI/CD du nouveau projet.
GitLab crée ensuite un pipeline pour la branche master. On peut déjà y voir les différentes tâches créées par Auto DevOps pour tester mon application.
Une fois que la tâche de « production » a déployé avec succès l'application sur mon cluster Kubernetes (dans cet exemple, sur Google Cloud), je peux accéder à l'application.
Nous souhaitons maintenant trouver un meilleur titre. C'est pourquoi j'ouvre une issue dans le projet. Les issues dans GitLab servent à planifier les modifications et peuvent également être affichées sur les tableaux et les feuilles de route.
Suite à ce problème, je crée une nouvelle demande de fusion. Les modifications nécessaires y seront apportées. Comme vous pouvez le voir sur l'image ci-dessous, GitLab crée une nouvelle branche de fonctionnalité, « 1-change-title ».
J'ouvre l'IDE web intégré à GitLab pour la modification du code sur la demande de fusion.
Je change le titre (index.js) en « Les applications de test sont cool !! » et le cas de test (test.js), qui teste la lecture correcte du titre.
Une fois la modification validée, le pipeline assemblé par Auto DevOps s'exécute sur la branche de fonctionnalité. GitLab a créé une tâche distincte pour mon fichier test.js. L'application de revue est déployée dans la tâche « review ».
Une fois la « révision » de la tâche terminée avec succès, je vois un bouton sur la demande de fusion permettant de consulter l'application de révision.
Un rapide coup d'œil à notre cluster Kubernetes montre qu'en plus de l'environnement de production, nous avons maintenant également un environnement « review-1-change » en cours d'exécution.
Cliquer sur le bouton « Voir l’application » ouvre l’application de révision avec mes modifications (ici avec deux points d’exclamation, contrairement au code ci-dessus, car il y avait encore un problème avec le cluster Kubernetes et j’ai dû effectuer une nouvelle validation)
Tout semble conforme aux attentes, je fusionne donc la demande de fusion dans la branche principale. Après avoir cliqué sur le bouton correspondant (Marquer comme prêt → Fusionner), le pipeline de branches de fonctionnalités nettoie d'abord l'environnement de l'application de test (c'est-à-dire qu'il l'arrête) avant que les modifications ne soient fusionnées dans la branche principale.
Le pipeline principal est déjà prêt (voir image ci-dessous) et sera lancé par GitLab dès que le nettoyage sera terminé.
Une fois que le pipeline principal a fusionné les modifications et les a déployées en production dans le cluster Kubernetes, notre application modifiée est en production.
Un coup d'œil à notre cluster Kubernetes montre que seul l'environnement de production est encore en fonctionnement et que l'application de révision n'est plus active.
Résumé
Les applications de revue de code de GitLab raccourcissent le cycle de rétroaction entre les différentes parties prenantes, ce qui nous aide à identifier et à résoudre les problèmes au plus tôt. Cela contribue à améliorer la qualité globale du produit.
Si vous avez des questions concernant Review Apps, Auto DevOps ou GitLab, n'hésitez pas à nous contacter.
Ton
Beni
