CI/CD avec GitLab

L'importance de la CI/CD et de GitLab dans les projets modernes

Dans un monde où les logiciels évoluent rapidement, la capacité à livrer des mises à jour fréquentes, fiables et de qualité est un avantage stratégique majeur. C'est ici que le concept de CI/CD (Intégration Continue et Déploiement Continu) entre en jeu.
Combiné à un outil puissant comme GitLab, il devient possible d'automatiser, de sécuriser et d'accélérer tout le cycle de développement logiciel.

En parallèle, la méthode Agile s'est imposée comme un cadre incontournable pour gérer efficacement les projets logiciels. Associée à la CI/CD, elle permet d'atteindre un haut degré de flexibilité, de collaboration et de satisfaction des utilisateurs.

Qu'est-ce que la CI/CD ?

La CI/CD (Continuous Integration / Continuous Deployment ou Delivery) est une approche visant à optimiser le processus de développement, d'intégration, de test et de déploiement des logiciels.

1. Intégration Continue (CI)

L'objectif de la CI est de s'assurer que chaque modification apportée au code (par exemple, un commit) est automatiquement intégrée et testée. Cela inclut :

L'exécution des tests automatisés pour valider les changements.
La détection des erreurs dès qu'elles surviennent.
La prévention des conflits de code grâce à l'intégration fréquente.

2. Déploiement Continu (CD)

Le CD est la suite logique de la CI. Il automatise la mise en production des applications. Cela peut être divisé en deux approches :

Continuous Delivery : Le code est prêt à être déployé manuellement.
Continuous Deployment : Chaque changement validé est automatiquement mis en production.

Lien entre CI/CD et la méthode Agile

La méthode Agile repose sur des cycles courts et itératifs, appelés sprints, durant lesquels les équipes livrent des fonctionnalités incrémentales et exploitables. Voici comment la CI/CD complète Agile :

Réduction des cycles de développement :
- Avec la CI/CD, les équipes peuvent livrer des versions fonctionnelles à chaque sprint, voire plus fréquemment.
- Les pipelines CI/CD automatisent les tests et le déploiement, alignant la fréquence des livraisons avec la philosophie Agile.
Retours rapides :
- La méthode Agile encourage les retours fréquents des utilisateurs. Grâce à la CI/CD, les modifications basées sur ces retours peuvent être intégrées rapidement dans la prochaine itération.
Amélioration continue :
- Les tests automatisés et le monitoring dans les pipelines CI/CD permettent une amélioration continue, un principe clé d'Agile.
Collaboration renforcée :
- L'Agile favorise une communication fluide entre les développeurs, testeurs, et parties prenantes. La CI/CD, combinée à GitLab, fournit une plateforme unique où toutes les étapes du cycle de vie logiciel sont visibles.

Pourquoi adopter la CI/CD ?

Amélioration de la qualité du code :
- Grâce aux tests automatisés, les bugs sont détectés rapidement.
- Les développeurs peuvent intégrer et tester leur travail fréquemment, réduisant ainsi les conflits de fusion.
Déploiements plus rapides :
- Les pipelines CI/CD permettent d'automatiser les étapes fastidieuses (tests, builds, déploiement).
- Les équipes peuvent livrer des fonctionnalités aux utilisateurs en un temps record.
Réduction des risques :
- Les tests automatisés minimisent les erreurs humaines.
- Les déploiements itératifs rendent les changements plus faciles à surveiller et à corriger.
Flexibilité et scalabilité :
- Les équipes peuvent expérimenter et innover sans craindre d'impacter l'ensemble du projet.
- Les processus automatisés s'adaptent aux besoins croissants.

Pourquoi choisir GitLab pour la CI/CD ?

GitLab est bien plus qu'un simple gestionnaire de code source : il offre une solution complète pour mettre en place une stratégie CI/CD efficace. Voici ses principaux avantages :

1. Plateforme tout-en-un

GitLab combine un gestionnaire de dépôt Git, des outils de CI/CD, et des fonctionnalités DevOps comme la gestion des conteneurs et le monitoring, dans une seule interface.

2. Pipelines CI/CD faciles à configurer

GitLab permet de définir des pipelines dans un simple fichier .gitlab-ci.yml.
Ces pipelines peuvent inclure des étapes comme :

Compilation du code.
Exécution de tests automatisés.
Build et déploiement d'images Docker.
Déploiement dans des environnements cloud comme AWS ou Kubernetes.

3. Intégration avec des outils tiers

GitLab s'intègre avec des outils populaires comme Docker, Kubernetes, Terraform, et d'autres, facilitant ainsi la gestion des conteneurs, des infrastructures et des applications.

4. Sécurité intégrée

GitLab propose des scans automatiques pour détecter les vulnérabilités dans le code et les dépendances.
Les tests de sécurité peuvent être intégrés directement dans le pipeline CI/CD.

5. Automatisation avancée

Les "GitLab Runners" permettent de lancer des jobs CI/CD sur des machines locales ou cloud.
Les fonctionnalités comme les "Environnements dynamiques" permettent de tester les changements dans des environnements isolés avant leur mise en production.

6. Écosystème open-source

GitLab est une solution open-source avec une communauté active, ce qui garantit flexibilité et personnalisation.

Exemple d'un pipeline CI/CD avec GitLab

Voici un exemple d'un pipeline GitLab CI/CD pour un projet Docker déployé sur AWS (Nous prendrons l'API que nous avons créée avec FastApi) :

services:
  - docker:27.4.1-dind

stages:
  - lint
  - build
  - test
  - deploy
  - fargate

dockerfile_lint:
  stage: lint
  image: hadolint/hadolint:2.9.2-debian
  script:
    - hadolint Dockerfile
  allow_failure: false

flake8_lint:
  stage: lint
  image: python:3.10
  before_script:
    - pip install flake8
  script:
    - flake8 . --count --select=E9,F63,F7,F82 --show-source --statistics  # Affiche les erreurs critiques
    - flake8 . --count --exit-zero --max-complexity=10 --max-line-length=88 --statistics  # Tolérance pour les avertissements
  allow_failure: false

image_build:
  stage: build
  image: docker:27.4.1
  script:
    - docker build -t my-fastapi-georisque:latest .
    - mkdir image
    - docker save my-fastapi-georisque:latest > image/my-fastapi-georisque.tar
  artifacts:
    paths:
      - image
  allow_failure: false

test_api:
  stage: test
  image: docker:27.4.1
  script:
    - docker load < image/my-fastapi-georisque.tar
    - docker run -d --rm --name fastapi-container -p 8082:8000 my-fastapi-georisque
    - for i in {1..10}; do
        if docker exec fastapi-container curl -s http://127.0.0.1:8001/ | grep '"message":"Bienvenue sur mon application"'; then
          echo "API is ready";
          break;
        fi;
        sleep 2;
      done
    - |
      docker exec fastapi-container sh -c "
      curl -s http://127.0.0.1:8001/docs | grep 'Swagger UI' &&
      curl -s 'http://127.0.0.1:8001/api/v1/catnat/?longitude=2.290084&latitude=49.897442&rayon=1000&page=1&page_size=10'  | grep '\"message\":\"Résultats trouvés\"'
      "
  dependencies:
    - image_build

deploy_to_aws_ecr:
  stage: deploy
  image: docker:27.4.1
  script:
    - apk add --no-cache aws-cli
    - docker load < image/my-fastapi-georisque.tar
    - docker images
    - aws ecr get-login-password --region eu-west-3 | docker login --username AWS --password-stdin $AWS_ACCOUNT_ID.dkr.ecr.eu-west-3.amazonaws.com
    - docker tag my-fastapi-georisque:latest $AWS_ACCOUNT_ID.dkr.ecr.eu-west-3.amazonaws.com/my-fastapi-georisque:gitlab
    - docker push $AWS_ACCOUNT_ID.dkr.ecr.eu-west-3.amazonaws.com/my-fastapi-georisque:gitlab
  dependencies:
    - image_build
  only:
    - main

deploy_to_fargate:
  stage: fargate
  image: alpine:latest
  script:
    - apk add --no-cache aws-cli
    - aws --version
    - aws configure set aws_access_key_id "$AWS_ACCESS_KEY_ID"
    - aws configure set aws_secret_access_key "$AWS_SECRET_ACCESS_KEY"
    - aws configure set default.region "eu-west-3"
    - aws ecs update-service --cluster $AWS_ECS_CLUSTER --service $AWS_ECS_SERVICE --force-new-deployment --region eu-west-3
    - echo "Deployment completed successfully!"
  dependencies:
    - deploy_to_aws_ecr
  only:
    - main

Analyse des stages du pipeline CI/CD

Le pipeline est divisé en plusieurs stages : lint, build, test, deploy et fargate. Voici une analyse de chaque étape et son rôle :

1. Stage `lint`

Objectif : Valider la qualité syntaxique et les bonnes pratiques du code.

Sous-stages

Dockerfile Lint
- Objectif : Valider la qualité syntaxique du fichier Dockerfile avec Hadolint.
- Commandes principales :
```
hadolint Dockerfile
            
```
Flake8 Lint
- Objectif : Vérifier la qualité et la conformité du code Python aux normes PEP8.
- Commandes principales :
```
pip install flake8
flake8 . --count --select=E9,F63,F7,F82 --show-source --statistics
flake8 . --count --exit-zero --max-complexity=10 --max-line-length=88 --statistics
            
```
Impact :
- Détection des erreurs critiques et des avertissements.
- Standardisation du code Python pour améliorer sa lisibilité et sa maintenabilité.

2. Stage `build`

Objectif : Construire l'image Docker de l'application FastAPI.

Commandes principales :

docker build -t my-fastapi-georisque:latest .
docker save my-fastapi-georisque:latest > image/my-fastapi-georisque.tar

Impact :

Génération d'une image Docker exportable.
Conservation de l'image comme artefact pour une utilisation dans les étapes suivantes.

3. Stage `test`

Objectif : Valider l'application en exécutant des tests fonctionnels dans un conteneur Docker.

Commandes principales :

docker run -d --rm --name fastapi-container -p 8082:8000 my-fastapi-georisque
curl -s http://127.0.0.1:8001/docs | grep 'Swagger UI'

Impact :

Détection rapide des erreurs avant le déploiement.
Simulation d'un environnement réel.

4. Stage `deploy`

Objectif : Déployer l'image Docker sur Amazon Elastic Container Registry (ECR).

Commandes principales :

aws ecr get-login-password --region eu-west-3 | docker login --username AWS --password-stdin ...
docker push $AWS_ACCOUNT_ID.dkr.ecr.eu-west-3.amazonaws.com/my-fastapi-georisque:gitlab

Impact :

Centralisation de l'image Docker sur un registre sécurisé.
Préparation au déploiement sur AWS Fargate.

5. Stage `fargate`

Objectif : Déployer ou mettre à jour le service sur AWS Fargate.

Commandes principales :

aws ecs update-service --cluster $AWS_ECS_CLUSTER --service $AWS_ECS_SERVICE --force-new-deployment

Impact :

Automatisation du déploiement en production.
Garantit une mise à jour fluide sans interruption de service.

Organisation en fonction des stages

Pour maximiser l'efficacité et la collaboration, voici une organisation possible prenant en compte les différents stages :

a. Étape 1 : Pré-développement (Lint)

Responsable : Équipe de développement.
Action : Assurez-vous que le Dockerfile et le code Python suivent les bonnes pratiques et standards.
Objectif : Éviter les problèmes liés aux images Docker mal configurées et garantir que le code Python respecte les conventions et est exempt d'erreurs critiques.

b. Étape 2 : Construction (Build)

Responsable : Équipe d'intégration.
Action : Construire et sauvegarder l'image Docker pour qu'elle soit utilisée dans les étapes suivantes.
Objectif : Produire un artefact fiable (l'image Docker) pour la suite du pipeline.

c. Étape 3 : Validation (Test)

Responsable : Équipe QA.
Action : Exécuter des tests automatisés pour valider les fonctionnalités principales et l’intégrité de l’application.
Objectif : Garantir que l'application fonctionne comme prévu avant de la déployer.

d. Étape 4 : Publication (Deploy sur ECR)

Responsable : Équipe DevOps.
Action : Publier l’image dans un registre privé pour faciliter le déploiement.
Objectif : Centraliser et sécuriser les images Docker.

e. Étape 5 : Déploiement en production (Fargate)

Responsable : Équipe DevOps ou responsable des opérations.
Action : Déployer ou mettre à jour le service sur AWS Fargate.
Objectif : Assurer un déploiement sans interruption et superviser les performances en production.

Conclusion

La combinaison de la méthode Agile, de la CI/CD et de GitLab permet aux équipes de relever les défis du développement logiciel. Agile offre un cadre flexible et collaboratif, tandis que la CI/CD assure une automatisation fluide pour livrer des logiciels rapidement et sans bugs. En utilisant GitLab, vous accédez à une plateforme intégrée qui simplifie chaque étape du cycle de vie logiciel.

Pour plus de détails, consultez le repository GitLab.

CI/CD avec GitLab

L'importance de la CI/CD et de GitLab dans les projets modernes

Qu'est-ce que la CI/CD ?

1. Intégration Continue (CI)

2. Déploiement Continu (CD)

Lien entre CI/CD et la méthode Agile

Pourquoi adopter la CI/CD ?

Pourquoi choisir GitLab pour la CI/CD ?

1. Plateforme tout-en-un

2. Pipelines CI/CD faciles à configurer

3. Intégration avec des outils tiers

4. Sécurité intégrée

5. Automatisation avancée

6. Écosystème open-source

Exemple d'un pipeline CI/CD avec GitLab

Analyse des stages du pipeline CI/CD

1. Stage lint

Sous-stages

2. Stage build

3. Stage test

4. Stage deploy

5. Stage fargate

Organisation en fonction des stages

a. Étape 1 : Pré-développement (Lint)

b. Étape 2 : Construction (Build)

c. Étape 3 : Validation (Test)

d. Étape 4 : Publication (Deploy sur ECR)

e. Étape 5 : Déploiement en production (Fargate)

Conclusion

1. Stage `lint`

2. Stage `build`

3. Stage `test`

4. Stage `deploy`

5. Stage `fargate`