Intégration continue

À propos de l’intégration continue

L’intégration continue (CI) est une pratique logicielle qui nécessite un committing fréquent du code dans un dépôt partagé. La plupart du temps, le fait de commiter le code permet de détecter plus rapidement les erreurs, et réduit la quantité de code dont un développeur a besoin pour le débogage lorsqu’il recherche la source d’une erreur. Les mises à jour fréquentes du code facilitent également la fusion des modifications apportées par différents membres d’une équipe de développement logiciel. Ceci est idéal pour les développeurs, qui peuvent alors passer plus de temps à écrire du code et moins de temps à déboguer des erreurs ou à résoudre les conflits de fusion.

Lorsque vous commitez du code dans votre dépôt, vous pouvez générer et tester le code en continu pour être sûr que le commit ne provoque pas d’erreurs. Vos tests peuvent inclure des analyseurs de code (qui vérifient la mise en forme), des vérifications de sécurité, la couverture du code, des tests fonctionnels et d'autres vérifications personnalisées.

La génération et le test de votre code nécessitent un serveur. Vous pouvez compiler et tester des mises à jour localement avant de pousser du code vers un dépôt, ou vous pouvez utiliser un serveur CI qui recherche les nouveaux commits de code dans un dépôt.

À propos de l’intégration continue à l’aide de GitHub Actions

CI avec GitHub Actions propose des workflows qui peuvent compiler le code dans votre référentiel et exécuter vos tests. Les flux de travail peuvent s’exécuter sur GitHubdes machines virtuelles hébergées ou sur des machines que vous hébergez vous-même. Pour plus d’informations, consultez « Exécuteurs hébergés par GitHub » et « Exécuteurs auto-hébergés ».

Vous pouvez configurer votre flux de travail CI pour qu’il s’exécute lorsqu’un GitHub événement se produit (par exemple, lorsque le nouveau code est envoyé (push) à votre référentiel), selon une planification définie ou lorsqu’un événement externe se produit à l’aide du webhook de répartition du référentiel.

GitHub exécute vos tests CI et fournit les résultats de chaque test dans la pull request, afin que vous puissiez voir si les modifications apportées à votre branche introduisent une erreur. Lorsque tous les tests d’intégration continue d’un workflow réussissent, les modifications que vous avez poussées sont prêtes à être examinées ou fusionnées par un membre de l’équipe. Lorsqu’un test échoue, cela peut signifier que l’une de vos modifications a provoqué l’échec.

Lorsque vous configurez CI dans votre référentiel, GitHub analyse le code dans votre référentiel et recommande des flux de travail CI en fonction du langage et de l’infrastructure de votre référentiel. Par exemple, si vous utilisez Node.js, GitHub suggèrez un modèle de flux de travail qui installe vos packages Node.js et exécute vos tests. Vous pouvez utiliser le modèle de flux de travail CI suggéré par GitHub, personnaliser le modèle de flux de travail suggéré ou créer votre propre fichier de flux de travail personnalisé pour exécuter vos tests CI.

En plus de vous aider à configurer des flux de travail CI pour votre projet, vous pouvez utiliser GitHub Actions pour créer des flux de travail dans le cycle de vie complet du développement logiciel. Par exemple, vous pouvez utiliser des actions pour déployer, empaqueter ou publier votre projet. Pour plus d’informations, consultez « Écriture de workflows ».

Pour obtenir une définition des termes courants, consultez « Présentation des GitHub Actions ».

Étapes suivantes

GitHub propose des modèles de flux de travail CI pour divers langages et infrastructures. Pour obtenir des didacticiels sur la configuration de l’intégration continue à ces modèles, consultez Génération et test de votre code.