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...

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, prenons le cas où 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 les uns après les autres, vous...

1. Les bénéfices du Continuous Delivery

Le Continuous Delivery permet de fournir rapidement des feedbacks 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êmes...

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...