Pratique CI/CD : un flux de travail d'intégration continue simple mais fonctionnel [Partie 1]

CI/CD est un dogme bien établi en matière de développement logiciel. Internet regorge d’articles et de pages parlant de CI/CD. Ils ont toujours la même image CI/CD . Je parie que vous connaissez l'image dont je parle.

J'ai lu des dizaines d'articles sur le sujet et expérimenté la mise en œuvre d'un pipeline CI/CD de bout en bout. La réalité est que la mise en œuvre d'un pipeline CI/CD est bien plus complexe que la lecture d'articles, la compréhension de l'image globale du CI/CD et l'utilisation de la théorie. Le développement d’un pipeline CI/CD nécessite des équipes interdisciplinaires et expérimentées.

Cet article explique comment créer un pipeline CI minimum viable pour une application Python. Vous pouvez adapter le contenu de l'article à d'autres langues et exigences. L'exemple utilise FastAPI et GitHub Actions.

CI : Intégration continue

Permettez-moi d'ajouter mes deux cents aux descriptions d'intégration continue existantes. L'intégration continue signifie la fusion régulière des modifications de code automatiquement testées, approuvées et livrables dans le référentiel du projet.

Cet exemple utilise les actions GitHub pour exécuter automatiquement les vérifications requises sur chaque événement « Pull Request » ou « Push to Main » afin de garantir que le code respecte les normes de qualité du référentiel. Le marché propose une collection diversifiée d'outils CI/CD : Jenkins , Travis , CircleCI , GitLab, etc. Choisissez celui qui correspond le mieux aux exigences de votre pipeline.

L'exemple de workflow vérifie que le nouveau code suit les règles de formatage exécutées pre-commit . Ensuite, il exécute les petits tests en utilisant Pytest et, enfin, les moyens en installant l'application Helm Chart sur un cluster Kin D.

Votre flux de travail d'intégration continue dépendra de la taille de votre équipe, de sa maturité, des exigences des applications et de la stratégie de branchement.

Analyse du code statique

Analysez les modifications du code sans les exécuter. Les outils d'analyse statique vérifient que votre code respecte les règles de formatage, n'utilise pas de dépendances obsolètes ou corrompues et est suffisamment lisible et simple. Ils suggèrent également de coder des anti-modèles et des bugs en fonction du langage de programmation.

Nous expliquerons comment installer, configurer et exécuter Pre-commit. Vous pouvez combiner Pre-commit avec d'autres outils d'analyse comme Sonar ou Synk .

Pré-engagement

Pre-commit est un outil écrit en Python. Pour le configurer sur votre référentiel, il suffit de créer un fichier YAML et d'ajouter les hooks versionnés que vous souhaitez exécuter avant chaque validation. Pre-commit gère automatiquement les dépendances requises par les hooks et corrige automatiquement les erreurs trouvées. Il prend en charge plusieurs types de fichiers : JSON, YAML, tf, py, ts, etc.

Réduisez les coûts d’infrastructure en exécutant localement vos vérifications de code avant de les pousser. Vous pouvez exécuter Pre-commit sur votre CI pour vérifier le format du code poussé.

Installez, configurez et exécutez l'outil de pré-validation :

 repos: - repo: https://github.com/pre-commit/pre-commit-hooks rev: v2.3.0 hooks: - id: check-yaml - id: end-of-file-fixer - id: trailing-whitespace

 $ pip install pre-commit $ pre-commit install $ pre-commit run --all-files

Test

Les définitions et la portée des tests unitaires, d'intégration et de bout en bout sont parfois diffuses. Comme je l'ai fait avec la description de l'intégration continue, j'ajouterai mon grain de sel aux types de tests de génie logiciel chez Google :

• Petit : Tests rapides. Testez de petits morceaux de code. Utilisez des doubles de test ou des environnements simulés (par exemple SQLite). Il n’est pas nécessaire de construire un artefact. Temps : ~ 60 secondes.

• Medium : Testez l’interaction entre plusieurs morceaux de code. Ils peuvent inclure la création des artefacts, l'utilisation d'artefacts tiers (par exemple une base de données ) et la connexion au réseau localhost. Utilisation d'environnements falsifiés (par exemple docker-compose, Kind, Minikube, etc.) ou de services externes (par exemple Azure Blob Storage ou AWS S3). Temps : ~ 300 secondes.

• Grand : Ils utilisent des environnements de type production (par exemple, tests de performances). Temps : + 900 secondes.

  
  

Avoir ou non des tests moyens/grands sur votre pipeline d'intégrations continues dépend de vos besoins.

Petit

L'exemple utilise Pytest pour exécuter les tests et le client de test FastAPI pour simuler l'environnement. Pas de secrets ; votre outil de test de langage de programmation doit vous fournir toutes les dépendances requises pour tester votre application.

De plus, vous pouvez ajouter une vérification de couverture de test minimale et la télécharger dans le cadre de vos résultats. La couverture des tests est une mesure délicate. Une couverture de test élevée ne signifie pas implicitement avoir un code bien testé, mais un 50 % est supérieur à un code testé à 0 %.

Moyen

Kin D est un cluster Kubernetes léger docker-in-docker utilisé pour le développement local ou CI. Nous utilisons Kind pour configurer un environnement de test et exécuter les tests sur celui-ci :

1. Créer le cluster Kind
2. Construire l'image Docker
3. Charger l'image Docker dans Kind
4. Installez MetalLB et appliquez les CDR requis
5. Installer Ingress-Nginx
6. Installez votre graphique de barre
7. Configurez l'hôte de votre système d'exploitation

Charger des images Docker

Kind ne parviendra pas à télécharger votre image car elle n'est pas téléchargeable à partir d'un registre. Kind nécessite que l'image soit chargée avant de l'utiliser.

MétalLB

MetalLB est un équilibreur de charge Kubernetes nu. Découvrez pourquoi un équilibreur de charge est requis sur la page Web de MetalLB .

Une fois installé à l'aide du Helm Chart, nous pouvons créer les CRD requis :

 --- apiVersion: metallb.io/v1beta1 kind: L2Advertisement metadata: name: kind-advertisement --- apiVersion: metallb.io/v1beta1 kind: IPAddressPool metadata: name: kind-address-pool spec: addresses: - "172.26.255.0/24"

Docker crée un sous-réseau pour le cluster Kind (par exemple 172.26.0.0/16). Inspectez l’interface réseau Kind pour connaître la plage d’adresses IP attribuée et utilisez l’adresse comme valeur pour la ressource IPAddressPool. Plus d'informations sur la configuration de MetalLB sont disponibles sur la page Web KinD .

Exposer l'application

Installez le graphique Helm Ingress-Nginx. Ensuite, installez votre application Helm Chart, en définissant un objet Ingress. Définissez la propriété ingressClassName sur nginx et définissez un hôte (par exemple api.local). Enfin, modifiez le fichier /etc/host pour ajouter la ligne suivante :

 192.168.1.10 api.local

Vous pouvez définir autant d'hôtes que vous le souhaitez, pointant vers la même adresse. Nginx fera le reste.

Livraison

Avant de livrer les artefacts requis, le flux de travail exécute les étapes de peluchage et de test.

Nous utilisons Commitizen pour gérer les versions des artefacts. Commtizen met automatiquement à jour la version de l'artefact et applique les modifications. Il crée une nouvelle balise git avec le format de balise configuré. Vous pouvez également configurer Commtizen pour mettre à jour votre journal des modifications avec les dernières modifications.

 [tool.commitizen] tag_format = "v$major.$minor.$patch" version_scheme = "semver" version_provider = "pep621" major_version_zero = true update_changelog_on_bump = true version_files = [ "charts/ci-example/Chart.yaml:version", "charts/ci-example/Chart.yaml:appVersion" ]

Le workflow utilise la version de sortie Commitizen pour définir la balise Docker Image et Helm Chart.

Conclusions

Cet article décrit un flux de travail d'intégration continue simple mais fonctionnel. Des modifications peuvent être nécessaires pour fonctionner avec d'autres langages de programmation ou répondre à vos besoins, mais certaines étapes doivent être facilement exportables et fonctionner telles quelles.

Pratique CI/CD : Déploiement continu [Partie 2] Bientôt disponible…