Par Sébastien Bernard, architecte de solutions | expert en qualité de code, DevOps et intégration d’IA générative | passionné par l’innovation et le succès client.
Objectifs de cette série
Cette série d’articles a pour but d’explorer les différents outils pour effectuer des déploiements en pipeline as code. GitHub Actions est notre cobaye pour cette fois-ci.
L’objectif de chaque article reste le même : récupérer le code source depuis GIT, compiler un projet JAVA/Spring-Boot avec Maven, lancer les tests puis déployer l’application sur AWS BeanStalk.
Ces étapes seront écrites sous forme de code dans un pipeline et exécutées avec l’outil CI/CD.
Chaque article sera divisé en plusieurs parties :
- Installation et démarrage d’un outil CI/CD
- Configuration de l’outil CI/CD (si nécessaire)
- Développement du pipeline de déploiement continu
- Vérification du déploiement
- Conclusion simple
Si vous voulez exécuter un pipeline, vous aurez besoin de :
- Runtime Docker pour exécuter les étapes du pipeline.
- Un environnement AWS BeanStalk avec clé d’accès et secret pour déployer l’application.
Avant de commencer, définissons deux concepts clés : déploiement continu et pipeline as code.
Que signifie « déploiement continu » ?
Le déploiement continu est étroitement lié à l’intégration continue et fait référence à la mise en production d’un logiciel qui réussit les tests automatisés.
« Essentially, it is the practice of releasing every good build to users », explique Jez Humble, auteur du livre Continuous Delivery.
En adoptant à la fois l’intégration continue et le déploiement continu, vous réduisez non seulement les risques et les erreurs rapidement, mais vous améliorez régulièrement les applications pour arriver à une meilleure solution. Avec des livraisons plus rapides et régulières, vous pouvez rapidement vous adapter aux besoins de l’entreprise et aux besoins des utilisateurs.
Cela permet une plus grande collaboration entre les opérations et la livraison, ce qui transforme votre processus de livraison en un avantage concurrentiel.
Que signifie « pipeline as code » ?
Les équipes font pression pour automatiser leurs environnements (tests), y compris l’infrastructure.
Le pipeline as code permet de définir les étapes de déploiement par du code au lieu de configurer ces étapes manuellement.
Code source
La référence de la démo est disponible dans GitHub : Continuous Deployment Demo
GitHub Actions
Objectifs
Le septième concurrent est GitHub Actions, l’outil CI/CD natif intégré dans la célèbre plateforme GitHub. GitHub Actions se distingue par son intégration poussée avec GitHub, offrant aux développeurs une expérience fluide.
Vous pouvez trouver les autres articles ici : #1-Jenkins, #2-Concourse, #3-GitLab, #4-CircleCI, #5-TravisCI, #6-Azure DevOps
GitHub Actions est la plateforme de GitHub pour l’intégration continue et la livraison continue qui remplace le besoin de services CI/CD externes. Depuis son lancement en 2018, GitHub Actions est devenu un favori parmi les développeurs pour sa flexibilité et son écosystème étendu.
GitHub Actions fournit un environnement robuste et intégré qui prend en charge tous les aspects du cycle de vie du développement : gestion du code source, intégration continue, déploiement et surveillance.
Fonctionnalités différentielles :
Intégration au Marketplace : GitHub Actions, comme Azure DevOps, offre un marketplace d’actions développées par la communauté. Ces actions peuvent être intégrées dans les workflows pour réaliser des tâches comme configurer des environnements, exécuter des tests ou déployer sur des clouds. Le marketplace propose une vaste gamme d’actions, de simples utilitaires jusqu’aux scripts de déploiement complexes, facilitant la création de workflows avancés avec peu d’effort.
Workflows réutilisables : GitHub Actions permet la création et la réutilisation de workflows standardisés pour plusieurs projets, réduisant la duplication du travail entre équipes et permettant la mise en place de standards
Intégration avec les dépôts GitHub : GitHub Actions s’intègre directement avec les dépôts GitHub, réagissant à des événements comme les push ou les pull requests. Par exemple, un build peut être automatiquement déclenché lors de la création d’une pull request, assurant ainsi que les vérifications de qualité du code sont faites avant toute intégration.
Matrice stratégique : GitHub Actions supporte les constructions en matrice, permettant l’exécution simultanée de jobs dans diverses configurations. Cette capacité est idéale pour tester votre code sous différents environnements, comme diverses versions de langages ou dépendances. En définissant une matrice de configurations, vous assurez que votre code fonctionne correctement dans tous les environnements visés, économisant ainsi temps et effort grâce à des tests parallèles et détectant plus tôt les problèmes de compatibilité.
Structure
GitHub Actions offre deux manières principales de créer et d’éditer des workflows : en utilisant l’interface web de GitHub ou en éditant directement les fichiers YAML dans le dépôt. Un workflow contient des jobs qui peuvent être exécutées en parallèle, et chaque job se compose de plusieurs étapes. Ces étapes peuvent inclure des actions comme la récupération du code, la configuration des dépendances, l’exécution des tests et le déploiement des applications.
Maintenant que nous comprenons mieux la plateforme, plongeons dans la configuration de notre dépôt !
Configurer votre dépôt pour GitHub Actions
Tout d’abord, vous devez créer un dépôt sur GitHub. GitHub Actions est gratuit pour les projets open source, ce qui en fait un excellent choix pour l’automatisation. Pour ce tutoriel, nous allons créer un dépôt public. Un dépôt public permet à d’autres de voir votre code, ce qui peut être bénéfique pour les projets collaboratifs et les contributions open source.
Une fois le dépôt créé, naviguez jusqu’aux paramètres du projet. Ici, vous devez activer toutes les actions et les workflows réutilisables pour le projet. Cette étape garantit que GitHub Actions peut fonctionner sans aucune restriction, fournissant les autorisations nécessaires pour que les workflows s’exécutent correctement.
Ensuite, nous devons configurer les secrets nécessaires pour accéder à l’instance AWS. Les secrets sont cruciaux pour stocker de manière sécurisée les informations sensibles telles que les clés d’accès. Dans les paramètres, rendez-vous dans le menu « Secrets et variables » et ajoutez les secrets nécessaires. Pour ce tutoriel, nous ajouterons AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY et AWS_REGION. Ces secrets permettent à vos GitHub Actions de s’authentifier et d’interagir de manière sécurisée avec les services AWS.
Avec le dépôt et les secrets configurés, vous êtes maintenant prêt à déployer vos premières GitHub Actions ! Cette configuration simplifie le processus de déploiement, le rendant efficace et sécurisé.
Ajouter votre premier workflow
Pour créer votre première action pour le projet, naviguez jusqu’à l’onglet « Actions » dans votre dépôt. Sélectionnez l’option set up a workflow yourself. Cela vous permet de créer un workflow personnalisé adapté aux besoins de votre projet.
Renommez le fichier de workflow en build-deploy.yml et insérez le code suivant :
name: Build and deploy
on :
push:
branches: [ master ]
pull_request:
branches: [ master ]
jobs:
build:
name: Build package
runs-on: ubuntu-latest
steps:
– name: Checkout code
uses: actions/checkout@v3
– name: Set up JDK 1.8
uses: actions/setup-java@v3
with:
distribution: ‘temurin’
java-version: ‘8’
– name: Build with Maven
run: mvn package –file pom.xml -Dmaven.repo.local=.m2
– name: Upload Artifact
uses: actions/upload-artifact@v4
with:
name: continuous-deployment-demo
path: target/demo-1.0.jar
deploy:
name: Deploy to AWS Elastic Beanstalk
runs-on: ubuntu-latest
steps:
– name: Download Artifact
uses: actions/download-artifact@v4
with:
name: continuous-deployment-demo
– name: Deploy to EB
uses: einaregilsson/beanstalk-deploy@v22
with:
aws_access_key: ${{ secrets.AWS_ACCESS_KEY_ID }}
aws_secret_key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
application_name: continuous-deployment-demo
environment_name: github-env
version_label: 1.0
region: ${{ secrets.AWS_REGION }}
deployment_package : target/demo-1.0.jar
Ce fichier YAML définit un workflow nommé « Build and deploy » qui se déclenche lors des événements de push et de pull request sur la branche master. Il se compose de deux jobs : build et deploy.
- Le job
buildrécupère le code, configure JDK 1.8, construit le projet à l’aide de Maven et télécharge l’artefact. - Le job
deploytélécharge l’artefact et le déploie sur AWS Elastic Beanstalk.
Cette configuration garantit que chaque push ou pull request sur la branche master entraîne une nouvelle construction et un déploiement, maintenant ainsi une intégration et une livraison continues.
Le fichier de workflow final devrait ressembler à ceci :
Validez vos modifications, et vous aurez avec succès ajouté votre premier workflow GitHub à votre dépôt ! Ce workflow automatisera votre processus de construction et de déploiement, économisant du temps et réduisant le potentiel d’erreur humaine.
Conclusion
L’intégration étroite de GitHub Actions avec les fonctionnalités de GitHub offre aux développeurs la possibilité de créer des actions qui interagissent efficacement avec les API de GitHub, automatisent les revues de code, et gèrent les workflows de déploiement.
Les capacités de partage des workflows au sein de la même organisation et via le marketplace permettent de propager facilement les meilleures pratiques en réduisant l’effort au niveau des équipes.
Les matrices permettent des tests en parallèle dans plusieurs environnements, améliorant la fiabilité de vos applications.
Les possibilités de configuration des Runner GitHub sont limitées et il y a une dépendance, peu importe le type de Runner au queue manager de GitHub.
Il manque certaines fonctionnalités avancées que pourraient nécessiter les grandes organisations, telles que des analyses détaillées, des insights et des processus d’approbations manuels.
Obtenez des conseils d’experts du DevOps
Vous désirez créer votre chaîne de déploiement logicielle automatisée et accélérer vos livraisons ? Les conseillers DevOps de Gologic peuvent vous aider à mettre en place des pipelines as code, incluant le développement, l’intégration, les tests, la livraison et le déploiement continus (CI/CD). Explorez nos services ou contactez-nous pour en apprendre davantage sur notre approche stratégique.
Par Sébastien Bernard, architecte de solutions | expert en qualité de code, DevOps et intégration d’IA générative | passionné par l’innovation et le succès client.
