par Benjamin Lallement, conseiller DevOps et membre du collectif Gologic
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.
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
Azure DevOps
Objectif
Notre sixième cobaye n’est nul autre que Microsoft et sa plateforme Azure DevOps.
Vous trouverez les autres articles en cliquant ici : #1-Jenkins, #2-Concourse, #3-GitLab, #4-CircleCI, #5-TravisCI. Azure DevOps est la plateforme de Microsoft qui remplace les plateformes précédentes comme VSTS, TFS pour effectuer l’intégration continue. Azure DevOps fournit une plateforme contenant toutes les fonctionnalités clés du développement : dépôt de code source, pipeline, planification des tests et gestion des tâches. Dans cet article, nous focusserons sur la partie pipeline : Azure Pipelines !
Avec le virage de Microsoft vers le monde de l’open source, Azure DevOps profite aussi de ce virage. Elle permet d’effectuer des pipelines qui se connectent à tous les outils connus sur le marché et de compiler tous les types d’applications comme du .Net, Java, Python ou encore du NodeJS.
Azure Pipelines fournit une édition du pipeline dans deux sens : des snippets vers le pipeline as code et du pipeline as code vers des snippets. Ces deux types d’édition facilitent l’exploration des différentes possibilités et permettent une flexibilité dans l’édition du pipeline par le code.
Par défaut, les snippets les plus communs sont offerts (compile, script, bash, powershell, publish tests, publish artefacts, etc…). Des snippets supplémentaires se retrouvent sous forme de catalogue dans le Azure DevOps Marketplace. Cela ajoute une quantité d’outils et de fonctions infinis. La fonction pipeline de Azure DevOps fonctionne sous forme de descripteur en format YAML. La configuration est stockée dans le projet dans un fichier azure-pipelines.yml.
Azure DevOps Pipelines s’intègre par défaut avec les dépôts de code source de Azure DevOps (notre cas). Il est quand même possible d’héberger son code source chez un autre hébergeur, accessible depuis l’extérieur. La plateforme étant seulement disponible en mode SaaS, il est impossible d’accéder à un dépôt privé sans en donner accès depuis l’extérieur.
Si le code source est modifié, le pipeline se déclenche par un changement au niveau des sources ou du pipeline lui-même.
En matière de structure, Azure DevOps ressemble aux autres outils : un pipeline est composé de `JOB`, regroupant des exécutions de tâches en `STEPS`. Pour les enchainements, un `JOB` déclare des dépendances, des conditions ainsi que du parallélisme entre les tâches. Un `JOB` s’exécute sur un agent selon le pool de VM accessible dans Azure et peut exécuter toutes les tâches dans un conteneur Docker.
L’espace de travail est commun pour toutes les tâches dans un `JOB` pour simplifier les échanges de fichier (tests, artefacts, etc…). Ensuite, le passage de données entre les `JOB` se fait par la publication dans un dépôt d’artefacts.
Les notions `Deployment JOB` et `Environment` sont différentes dans Azure DevOps en comparaison aux autres outils CI/CD. Un `Deployment JOB` a pour objectif d’exécuter des tâches de déploiement sur un environnement selon des stratégies : RunOnce, Blue-Green ou Canary. Cette fonctionnalité est manquante dans tous les autres outils de CI/CD et nécessite souvent l’installation d’un gestionnaire de déploiement comme Harness ou Spinnaker pour appuyer les stratégies de déploiement.
Il faut noter que Azure DevOps est en plein développement et beaucoup de fonctionnalités sont en cours de travail ou non fonctionnelles. Azure DevOps est offerte en mode SaaS avec la plateforme Microsoft/Azure et n’existe pas en mode On-premise.
Configurer un projet Azure DevOps Pipelines
Création du pipeline
Un compte Azure est requis pour se connecter sur la plateforme Azure DevOps. Ensuite, il faut créer un projet et déposer le code dans le dépôt du projet.
Configuration du projet
Ajout du code source dans le dépôt
Création du pipeline à partir d’un dépôt Azure Repos Git
Cette étape ajoute un fichier azure-pipelines.yml à la racine de votre dépôt et à chaque sauvegarde le pipeline s’exécute !
Gestion des variables d’environnement
Afin de déployer l’application dans AWS, il est nécessaire d’ajouter dans les variables d’environnement du projet, les configurations d’identification à AWS.
Dans l’édition du pipeline, sélectionner le menu `Variables` et ajouter les clés AWS_ACCESS_KEY_ID et AWS_SECRET_ACCESS_KEY avec vos configurations à AWS, en cochant `Keep this value secret` pour ne jamais transmettre les valeurs dans les logs.
Ces variables sont maintenant accessibles comme variables d’environnement dans l’ensemble des tâches du projet !
Maintenant que le pipeline est configuré, passons à l’étape de configuration du pipeline !
Pipeline as code: let’s get started
Azure DevOps utilise des pipelines sous forme déclarative en YAML à l’inverse des pipelines de type scripting (voir Jenkinsfile).
Le pipeline codé dans cet article contient deux `JOB` soit `Build` et `Deploy`:
- Build: déclenche une compilation Maven, publie les résultats de tests et publie un artefact dans un dépôt interne au pipeline.
- Deploy: en cas de succès du Build, télécharge l’artefact et exécute un déploiement dans AWS grâce à l’image Docker chriscamicas/awscli-awsebcli.
L’exemple complet est détaillé ci-dessous, il suffit de remplacer votre pipeline .azure-pipelines.yml par le contenu suivant :
jobs:
# Execute a Maven build and publish artefact
- job: Build
pool:
vmImage: 'ubuntu-16.04'
steps:
- task: Maven@3
displayName: 'Build application'
inputs:
mavenPomFile: 'pom.xml'
goals: 'package'
publishJUnitResults: true
testResultsFiles: '**/surefire-reports/TEST-*.xml'
javaHomeOption: 'JDKVersion'
jdkVersionOption: '1.8'
mavenVersionOption: 'Default'
mavenOptions: '-Xmx3072m'
mavenAuthenticateFeed: false
effectivePomSkip: false
sonarQubeRunAnalysis: false
- task: PublishTestResults@2
displayName: 'Publish tests results'
inputs:
testResultsFormat: 'JUnit'
testResultsFiles: '**/surefire-reports/TEST-*.xml'
mergeTestResults: true
- task: PublishBuildArtifacts@1
displayName: 'Publish application'
inputs:
pathtoPublish: '$(System.DefaultWorkingDirectory)'
artifactName: continuous-deployment-demo
# download the artifact and deploy it only if the build job succeeded
- job: Deploy
pool:
vmImage: 'ubuntu-16.04'
dependsOn: Build
condition: succeeded()
container: chriscamicas/awscli-awsebcli:latest
steps:
- checkout: none #skip checking out the default repository resource
- task: DownloadBuildArtifacts@0
displayName: 'Download Build Artifacts'
inputs:
artifactName: continuous-deployment-demo
downloadPath: $(System.DefaultWorkingDirectory)
- script: |
printenv
ls -ltra
echo "Check AWS_ACCESS_KEY_ID=$(AWS_ACCESS_KEY_ID)"
eb init continuous-deployment-demo -p "64bit Amazon Linux 2017.09 v2.6.4 running Java 8" --region "ca-central-1"
eb create azuredevops-env --single || true;
eb use azuredevops-env
eb setenv SERVER_PORT=5000
eb deploy
eb status
eb health
workingDirectory: $(System.DefaultWorkingDirectory)/continuous-deployment-demo
displayName: "Provision environment and deploy application"
Dès l’ajout du fichier .azure-pipelines.yml dans le projet, le menu Pipelines affiche l’exécution du pipeline et les logs pour voir l’avancement des étapes du pipeline.
Conclusion
Azure DevOps propose une solution complète vraiment efficace pour gérer le cycle de développement d’une application.
Elle offre une édition facile du pipeline par le mode interactif et le mode `code`.
Elle intègre énormément de type de tâches `built-in` et propose un catalogue d’ajouts impressionnant.
Elle est disponible seulement en mode `Cloud`pouvant bloquer une intégration avec des dépôts `On premise`.
Il y a beaucoup de développement toujours en cours comme les jobs de déploiement.
