Partager via

Moderniser votre développement logiciel avec l’intégration continue

À mesure que le code est développé, mis à jour ou même supprimé, avoir une méthode intuitive et sécurisée pour intégrer ces modifications dans la branche de code principale permet aux développeurs de fournir de la valeur.

En tant que développeur, vous pouvez apporter de petites modifications au code, transférer ces modifications vers un référentiel de code et obtenir un retour presque instantané sur la qualité, la couverture des tests et les bogues introduits. Ce processus vous permet de travailler plus rapidement, avec plus de confiance et moins de risques.

L’intégration continue (CI) est une pratique dans laquelle les systèmes de contrôle de code source et les pipelines de déploiement de logiciels sont intégrés pour fournir des mécanismes de génération, de test et de commentaires automatisés pour les équipes de développement de logiciels.

Le processus d’intégration continue démarre lorsqu’un ingénieur génère une demande d’extraction pour signaler au système CI que les modifications de code sont prêtes à être intégrées. Idéalement, le processus d’intégration valide le code par rapport à plusieurs références et tests. Il fait ensuite un retour d’informations à l’ingénieur à l’origine de la demande sur le statut de ces tests.

Si les vérifications et les tests de référence s'effectuent correctement, le processus d'intégration produit et prépare des composants qui déploieront le logiciel mis à jour. Ces actifs incluent du code compilé et des images de conteneurs.

L’intégration continue vous permet de fournir plus rapidement des logiciels de haute qualité via les actions suivantes :

  • en exécutant des tests automatisés sur le code pour permettre une détection précoce des changements cassants ;
  • en exécutant une analyse de code pour garantir les normes, la qualité et la configuration du code ;
  • Exécutez des vérifications de conformité et de sécurité pour vous assurer que le logiciel n’a pas de vulnérabilités connues.
  • en exécutant des tests d’acceptation ou fonctionnels pour vous assurer que le logiciel fonctionne comme prévu ;
  • en fournissant des commentaires rapides sur les problèmes détectés ;
  • en produisant, le cas échéant, des actifs ou des packages déployables (mise à jour du code incluse).

Automatiser l’intégration continue avec des pipelines

Pour obtenir une intégration continue, utilisez des solutions logicielles pour gérer, intégrer et automatiser le processus. Une pratique courante consiste à utiliser un pipeline d’intégration continue.

Un pipeline d’intégration continue implique un logiciel (souvent hébergé dans le cloud) qui fournit :

  • Plateforme permettant d’exécuter des tests automatisés.
  • Analyses de conformité.
  • Les rapports.
  • Tous les autres composants qui composent le processus d’intégration continue.

Dans la plupart des cas, le logiciel de gestion de pipeline est intégré au système de contrôle de version, de sorte que lorsque les requêtes de tirage sont créées ou que les logiciels sont fusionnés dans une branche donnée, le pipeline d’intégration continue est exécuté. L’intégration du contrôle de source offre également la possibilité de donner des commentaires CI directement sur les demandes d’extraction.

De nombreuses solutions, comme Azure Pipelines ou GitHub Actions, offrent les capacités de pipelines d’intégration continue.

Intégrer des pipelines avec la gestion de code source

L’intégration de votre pipeline d’intégration continue avec votre système de contrôle de code source est essentielle pour permettre des contributions de code rapides et en libre-service.

Le pipeline CI s’exécute sur une demande d’extraction récemment créée. Le pipeline comprend tous les tests, évaluations de sécurité et autres contrôles. Les résultats des tests CI s’affichent directement dans la demande d’extraction pour permettre des commentaires sur la qualité quasiment en temps réel.

Une autre pratique populaire consiste à créer de petits rapports ou badges qui peuvent être présentés dans le cadre du contrôle de code source pour rendre visibles les états de construction actuels.

L’image suivante montre l’intégration entre GitHub et un pipeline Azure DevOps. Dans cet exemple, la création d’un pull request déclenche un pipeline Azure DevOps. Le statut du pipeline s’affiche dans la demande d’extraction.

Capture d’écran d’un badge d’état Azure DevOps dans un dépôt GitHub.

Incorporer des tests automatisés

Un élément clé de l’intégration continue est la création et le test continus du code à mesure que les développeurs apportent leur contribution au code. Le test des requêtes de tirage à mesure qu’elles sont créées fournit des commentaires rapides indiquant que la validation n’a pas introduit de changements provoquant des erreurs. L’avantage ? Les tests du pipeline d’intégration continue peuvent être les mêmes que ceux exécutés lors du développement piloté par les tests.

L’extrait de code suivant montre une étape de test à partir d’un pipeline Azure DevOps. L’étape comporte deux tâches :

  • La première tâche utilise une infrastructure de test Python populaire pour exécuter des tests CI. Ces tests résident dans le contrôle de code source en même temps que le code Python. Les résultats des tests sont enregistrés dans un fichier nommé test-results.xml.
  • La deuxième tâche consomme les résultats des tests et les publie dans le pipeline Azure DevOps en tant que rapport intégré.
- script: |
    pip3 install pytest
    pytest azure-vote/azure-vote/tests/ --junitxml=junit/test-results.xml
    continueOnError: true

- task: PublishTestResults@2
    displayName: 'Publish Test Results'
    inputs:
    testResultsFormat: 'JUnit'
    testResultsFiles: '**/test-results.xml'
    failTaskOnFailedTests: true
    testRunTitle: 'Python $(python.version)'

L’image suivante montre les résultats des tests qui s’affichent dans le portail Azure DevOps.

Capture d’écran des tests de pipeline Azure DevOps dans le portail Azure DevOps.

Tests échoués

Les tests ayant connu un échec devraient bloquer temporairement un déploiement et conduire à une analyse plus approfondie de ce qui s’est passé. Les tests ayant échoué devraient également conduire soit à un affinement des tests, soit à une amélioration du changement qui a provoqué l’échec des tests.

Publier l’état de la build

De nombreux développeurs montrent que leur qualité de code est élevée en affichant un badge d’état dans leur dépôt. L’image suivante montre un badge Azure Pipelines affiché sur le fichier README d’un projet open source sur GitHub.

Capture d’écran d’un badge Azure Pipelines sur un fichier README dans GitHub.

Optimiser les temps de génération

Pour effectuer des builds plus rapides, vous pouvez :

  • Choisissez des agents qui répondent à vos besoins en matière de performances : accélérez vos builds en sélectionnant les machines de build appropriées. Les machines rapides peuvent faire la différence entre les heures et les minutes. Si vos pipelines se trouvent dans Azure Pipelines, vous pouvez exécuter vos travaux à l’aide d’un agent hébergé par Microsoft. Lorsque vous utilisez des agents hébergés par Microsoft, la maintenance et les mises à niveau sont prises en charge pour vous. Pour plus d’informations, consultez Agents hébergés par Microsoft.

  • Optimisez l’emplacement du serveur de build : lorsque vous générez votre code, les données sont envoyées sur le réseau. Les entrées des builds sont extraites d’un référentiel de contrôle de code source et du référentiel d’artefacts. La sortie du processus de génération doit être copiée, comprenant les composants compilés, les rapports de test, les résultats de couverture du code, et les symboles de débogage. Il est important que ces actions de copie soient exécutées rapidement. Si vous utilisez votre propre serveur de build, assurez-vous que le serveur de build se trouve près des sources et d’un emplacement cible. Les chargements et téléchargements rapides peuvent réduire le temps de génération global.

  • Effectuer un scale-out des serveurs de build : un seul serveur de build peut être suffisant pour un petit produit. À mesure que la taille et l’étendue du produit et du nombre d’équipes travaillant sur le produit augmentent, un seul serveur peut ne pas suffire. Mettez à l’échelle votre infrastructure horizontalement sur plusieurs machines lorsque vous atteignez la limite. Pour plus d’informations, consultez Créer et gérer des pools d’agents.

  • Optimisez la build :

    • Ajoutez des tâches parallèles pour accélérer le processus de construction. Pour plus d’informations, consultez Configurer et payer des travaux parallèles.

    • Activez les exécutions de suite de tests parallèles, ce qui permet souvent d’économiser beaucoup de temps, en particulier lors de l’exécution de tests d’intégration et d’interface utilisateur. Pour plus d'informations, consultez Exécuter des tests en parallèle avec n'importe quel gestionnaire de tests.

    • Utilisez la notion de multiplicateur, où vous pouvez effectuer un scale-out de vos builds sur plusieurs agents de build. Pour plus d’informations, consultez Spécifier des tâches dans votre pipeline.

    • Envisagez de déplacer des tests d’intégration, d’interface utilisateur et de fumée vers un pipeline de mise en production. Le passage à un pipeline de déploiement améliore la vitesse de construction et la vitesse de la boucle de rétroaction de construction.

    • Publiez les artefacts de build dans une solution de gestion de package, telle que NuGet ou Maven. La publication dans une solution de gestion de package vous permet de réutiliser plus facilement votre artefact de build.

Implémenter des types de build pour s’adapter à vos flux de travail

Votre organisation peut choisir de créer plusieurs types de builds différents pour optimiser les temps de génération. Les builds possibles sont les suivantes :

  • Build d’intégration continue (CI) : l’objectif de cette build est de s’assurer que le code est compilé et que les tests unitaires sont exécutés. Cette build est déclenchée à chaque validation. Il sert de cœur du projet et fournit à l’équipe des commentaires de qualité immédiatement. Pour plus d’informations, consultez Spécifier des événements qui déclenchent des pipelines.

  • Build nocturne : l’objectif d’une build nocturne n’est pas seulement de compiler le code, mais également de garantir que les suites de test plus volumineuses qui sont inefficaces s’exécutent à une cadence régulière pour chaque build. En règle générale, ces tests incluent l’intégration, l’interface utilisateur ou les tests de fumée. Pour plus d’informations, consultez Configurer des planifications pour les pipelines.

  • Version de production : outre la compilation et l’exécution de tests, cette version compile la documentation de l’API, les rapports de conformité, la signature du code et d’autres étapes qui ne sont pas nécessaires chaque fois que le code est construit. Cette version fournit la copie maîtresse qui est envoyée au pipeline de mise en production pour le déploiement final dans l'environnement de production.

Les types de builds nécessaires à votre organisation dépendent de facteurs, notamment de la maturité de votre équipe et de l’organisation, du type de produit sur lequel vous travaillez et de votre stratégie de déploiement.

Découvrez comment créer un pipeline d’intégration continue à l’aide de GitHub ou d’Azure DevOps :

Découvrez comment afficher des badges dans vos dépôts :

  • Last updated on