À 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 linters de code (qui vérifient la mise en forme du style), 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 générer et tester des mises à jour localement avant de pousser (push) du code vers un dépôt, ou vous pouvez utiliser un serveur d’intégration continue qui recherche les nouveaux commits de code dans un dépôt.
À propos de l’intégration continue avec GitHub Actions
L’intégration continue avec GitHub Actions offre des workflows qui peuvent générer du code dans votre référentiel et exécuter vos tests. Les workflows peuvent s’exécuter sur des machines virtuelles hébergées dans GitHub, ou sur des machines que vous hébergez vous-même. Pour plus d’informations, consultez « Utilisation des exécuteurs hébergés par GitHub » et « À propos des exécuteurs auto-hébergés ».
Vous pouvez configurer votre workflow d’intégration continue pour qu’il s’exécute lorsqu’un événement GitHub se produit (par exemple, lorsque le nouveau code est poussé vers votre dépôt), lorsqu’un événement externe se produit si vous utilisez le webhook de dispatch du dépôt, ou selon une planification définie.
GitHub Enterprise Cloud exécute vos tests d’intégration continue et fournit les résultats de chaque test dans la demande de tirage (pull request). Vous pouvez donc voir si la modification de votre branche provoque 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 l’intégration continue dans votre dépôt, GitHub Enterprise Cloud analyse le code de votre dépôt et recommande des workflows d’intégration continue basés sur le langage et le framework de votre dépôt. Par exemple, si vous utilisez Node.js, GitHub Enterprise Cloud suggérera un modèle de workflow qui installe vos packages Node.js et exécute vos tests. Vous pouvez utiliser le modèle de workflow d’intégration continue suggéré par GitHub Enterprise Cloud, personnaliser le modèle de workflow suggéré ou créer votre propre fichier de workflow personnalisé pour exécuter vos tests d’intégration continue.
En plus de vous aider à configurer des workflows d’intégration continue pour votre projet, GitHub Actions vous permet de créer des workflows dans le cycle de vie complet de 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 « Comprendre GitHub Actions ».
Modèles de workflow
GitHub Enterprise Cloud propose des modèles de workflow d’intégration continue pour une variété de langages et de cadres.
Consultez la liste complète des modèles de workflow d’intégration continue proposés par GitHub dans le dépôt actions/starter-workflows sur GitHub.com.