Intégration et déploiement continus (CI/CD)

1. Concepts fondamentaux de Git

1. La phase de build

Lorsque plusieurs développeurs travaillent en même temps sur un seul et même code, il est nécessaire de mettre en place des solutions permettant d’empêcher des incompatibilités et des dysfonctionnements d’opérer.

Le développeur commence par effectuer un commit du code et par pousser les modifications qu’il a apportées au niveau du dépôt de code (par exemple GitLab).

Une fois que le code a été poussé par le développeur sur le dépôt de code, ce dernier notifie le serveur d’intégration continue que de nouvelles modifications ont eu lieu.

Le code est ainsi buildé par le serveur (Jenkins, ou GitLab-CI par exemple). L’étape de Build correspond aux processus grâce auxquels le code source initial est converti en un fichier, ou un ensemble de fichiers, directement exécutable(s) sur un ordinateur ou un serveur. C’est d’ailleurs durant ces étapes qu’a lieu, pour certains langages, le processus de compilation, où les fichiers correspondant au code source sont convertis en un code directement exécutable (souvent du langage machine ou du binaire).

Lorsque cette troisième étape est effectuée, le serveur d’intégration continue informe le dépôt de code que le build a réussi ou a échoué.

2. Les phases de tests

Une fois que le build s’est correctement déroulé et que le code s’exécute sans difficulté, différents tests peuvent être effectués.

Nous pouvons effectuer...

1. Architecture de GitLab-CI

1. Exécuter plusieurs jobs en parallèle

Comme expliqué précédemment, vous pouvez tout à fait lancer plusieurs jobs en même temps sur votre Runner GitLab. Il est cependant nécessaire que les jobs appartiennent au même stage.

Par exemple, si nous souhaitons effectuer plusieurs tests sur notre code, comme :

Il est alors possible de construire un pipeline dont le fichier .gitlab-ci.yml ressemblerait à ceci :

stages: 
  - code 
 
flake8_code: 
  stage: code 
  image: python 
  before_script: 
    - pip install flake8 
  script: 
    - flake8 password_check.py 
  allow_failure: true 
 
security_code: 
  stage: code 
  image: python 
  before_script: 
    - pip install bandit 
  script: 
    - bandit -r password_check.py 
  allow_failure: true 
 
pylint_code: 
  stage: code 
  image: python 
  before_script: 
    - pip install pylint 
  script: 
    - pylint password_check.py 
  allow_failure: true 

git commit -a -m "Test multiples jobs" 
git push -u origin main 

Le résultat correspond à un pipeline qui ressemble à ceci :

Il y a quelque chose d’intéressant à observer ! En effet, plutôt que les trois jobs s’exécutent...

1. Les bénéfices du Continuous Delivery

Le Continuous Delivery permet de fournir rapidement des feedback automatiques sur les environnements de préproduction et de production (cf. chapitre Introduction au DevSecOps).

En effet, le service ou logiciel est toujours gardé dans un état releasable et déployable même lorsque de nouvelles fonctionnalités sont en cours de développement.

Cependant, pour être efficace, il faut que le Continuous Delivery soit accompagné de la mise en place d’un pipeline permettant de faire du déploiement à la demande. Cela permet d’arriver à un état de réduction des coûts, de gain de temps et de diminution des risques inhérents aux changements incrémentaux réalisés.

2. Les différences avec le déploiement continu

Il ne faut pas confondre les notions de déploiement continu avec celles de Continuous Delivery. En effet, elles ne correspondent pas spécifiquement aux même phases de développement.

L’intégration continue correspond aux processus itératifs couvrant les phases de développement du code source, de tests, et de build.

Le Continuous Delivery englobe les parties Build et Quality Assurance, permettant d’obtenir un code qui est dans un état releasable, c’est-à-dire prêt à être déployé (mais pas encore déployé). Il y a donc besoin d’effectuer...

1. Quelques règles de bonnes pratiques

Mettre en place du déploiement continu implique un certain nombre d’investissements au niveau ingénierie. En effet, il devient nécessaire d’implémenter de nouveaux outils.

La condition indispensable à un bon déploiement continu correspond à la capacité d’effectuer de bons tests automatiques. Ces tests sont effectués pour prévenir des risques de régressions lorsque du nouveau code est introduit, et ainsi remplacer les phases de revues de code manuelles. Comme expliqué précédemment, ils peuvent être réalisés lors des phases d’intégration continue.

Il est également nécessaire de pouvoir effectuer un retour en arrière rapide (rollback) en cas de dysfonctionnement d’une nouvelle version déployée. On peut ainsi utiliser les techniques de déploiement Blue/Green, par exemple (expliquées un peu plus loin dans ce chapitre).

Enfin, une bonne infrastructure est une infrastructure supervisée, sur laquelle un certain nombre d’alertes ont été implémentées pour avoir la capacité de détecter les dysfonctionnements qui peuvent apparaître.

2. Méthode Blue/Green

Cette méthode apparaît pour la première fois dans le livre Continuous Delivery de Jez Humble et David Farley comme un pattern à utiliser pour les déploiements, notamment au sein d’équipes DevOps.

Certaines applications ont besoin de fonctionner 24h/24 et 7j/7, ce qui implique des déploiements sans arrêt de service. C’est pour cette raison qu’est apparu le Zero Downtime Deployment (ZDD).

Au sein de ce ZDD, le déploiement Blue/Green cherche à déployer une nouvelle version de...