Microsoft Azure

Découvrez comment ajouter du CI/CD à votre application

Pour réagir au contenu de ce tutoriel, un espace de dialogue vous est proposé sur le forum. Commentez Donner une note  l'article (5)

Article lu   fois.

Les deux auteur et traducteur

Traducteur : Profil Pro

Liens sociaux

Viadeo Twitter Facebook Share on Google+   

I. Introduction

Suivez-moi sur Twitter, je serais ravi de lire vos suggestions de sujets et d'améliorations /Chris

Le CI/CD. Vous avez peut-être déjà entendu cette expression plus d'une fois. Vous l’employez même peut-être tous les jours. Quoi qu'il en soit, nous vous expliquerons ce que c'est, et pourquoi sa valeur est inestimable pour tout développeur.

Cet article présente le concept d’intégration et de déploiement continus, autrement appelé le CI/CD (Continuous Integration/Continuous Delivery en anglais). Vous verrez également comment mettre en place une forme simple de déploiement continu (CD) pour votre application avec Azure. Cet article est un peu long, mais il vous emmène du code source à la mise en place du déploiement et vous y apprendrez à faire du A/B testing et un déploiement bleu/vert avec des emplacements de déploiement.

Il s'agit d'une série d'articles.

  • Partie 1, Déploiement de notre repo GitHub : nous y sommes.
  • Partie 2 - Azure DevOps : nous apprendrons à travailler avec des pipelines, à les créer et les déployer, et nous verrons ensemble comment configurer les fichiers YAML pour nous aider. À écrire.

Enfin, nous apprendrons comment travailler avec des créneaux de déploiement pour les déploiements bleu/vert et le A/B testing.

En réalité nous pourrions utiliser deux approches différentes pour mettre en place le déploiement continu dans Azure. Cependant, seul Azure DevOps permet d'obtenir à la fois l’intégration et le déploiement en continu.

Dans cet article, nous allons montrer comment obtenir un déploiement continu avec une approche plus simple. Si vous cherchez à obtenir à la fois l'intégration et le déploiement en continu, je crains que vous ne deviez attendre la deuxième partie de cette série.

Mais ne vous inquiétez pas, même si cette approche est plus simple et ne permet pas d'obtenir autant de résultats qu'Azure DevOps, elle peut vous apporter beaucoup en tant que développeur.

II. Références

III. Que veut dire CI/CD et pourquoi en ai-je besoin ?

CI/CD est l'acronyme de Continuous Integration(CI) et Continuous Deployment (CD).

Ça a l'air génial, mais qu'est-ce que c’est ?

L’intégration continue (CI) consiste à intégrer le plus tôt possible les modifications apportées par les différents développeurs de l'équipe dans une branche principale, de préférence plusieurs fois par jour.

Il y a deux aspects de l'intégration dont il faut tenir compte en matière de CI :

  1. La définition du terme ;
  2. L'objectif.

III-A. Définition

Abordons le premier point, le terme lui-même. Différents développeurs travaillent sur différentes parties du code. Vous voulez que leurs modifications parviennent à la branche principale le plus rapidement possible. Si cela prend trop de temps, vous risquez de passer du temps à fusionner et à résoudre les conflits de fusion.

III-B. Objectif

L'objectif principal de l'IC est que les changements de chacun touchent la branche principale le plus tôt possible. L'objectif secondaire est d’obtenir un code qui fonctionne, puisqu’un code défectueux ne profite à personne. Dans le cadre de ce processus, l'idée est de mettre en place des tests automatisés et de pouvoir vérifier l’utilisation de standards d’usages pour s’assurer de la bonne qualité de ce qui est mergé.

Plus d’infos sur ce sujet ici :

  • https://codeship.com/continuous-integration-essentials
  • https://dev.to/quii/gamifying-continuous-integration-o1d

Est-ce que c’est clair ?

Excellent ! Qu'en est-il du déploiement continu ? Ne me dites pas que cela signifie que je déploie dès que je push le code vers le repo ? Ça semble dangereux.

Nous avions auparavant l'habitude de laisser s’écouler plusieurs mois entre chaque déploiement. Nous avions de grandes équipes d’assurance qualité qui testaient tout en profondeur et des semaines plus tard elles approuvaient tout, et à chaque sortie s’en suivait une longue cérémonie de transmission de scripts de personne à personne, tel un relais de flamme olympique.

Qu'y a-t-il de mal à cela ? Avoir des équipes d'assurance qualité et effectuer des tests en profondeur, ça semble tout à fait raisonnable. Bien sûr, j'aimerais pouvoir déployer plus souvent, mais la sécurité passe avant tout.

Eh bien, en 2020, les choses ont changé. Nous devrions configurer nos logiciels et nos processus de manière à pouvoir construire tous les composants dont nous avons besoin en appuyant simplement sur un bouton et vous devriez obtenir un logiciel fonctionnel à la fin, un artefact.

Ça paraît incroyable. Mais vous savez, nous avons différentes équipes qui travaillent sur différents composants, et chacune a son propre carnet de commandes, ses priorités et ses stratégies à elle. Ai-je mentionné que nous avons aussi des OPS, et que les OPS et les devs… Bref, je ne suis pas sûr que soit possible ?

Eh bien, en fait, l'intégration continue est relativement facile : ajouter des tests à votre logiciel et les exécuter à chaque fois que vous poussez du code est tout à fait réalisable pour la plupart d'entre nous. Le déploiement continu, CD, est en revanche plus délicat parce que le problème n’est généralement pas technique : il s'agit plutôt de processus, de communication entre parties prenantes et de l’usage d’outils appropriés.

D'accord, mais disons que mon département dev parvient à s'organiser de manière à ce que toutes les équipes communiquent. Disons qu’on met en place des stratégies de gestion de versions sur lesquelles on peut compter, et ainsi de suite ? Est-ce que je peux faire du déploiement continu ?

Peut-être, mais il faudra une vigilance de tous les instants pour s’assurer que non seulement les équipes orientées « composant » se parlent, mais aussi que les équipes de dev et les ops communiquent et collaborent. Car c'est de cela qu'il s'agit en fin de compte : des personnes, des processus et des outils.

Vous avez dit que vous me montreriez comment faire cela correctement !

Oui, c'est exact. Nous allons utiliser Azure. J'espère que les principes et les modèles qui sous-tendent ce que je vais vous montrer sont suffisamment génériques pour que vous puissiez facilement les appliquer dans le système et l'outil que vous préférez.

IV. Deux approches

Quand on parle de CI/CD sur Azure, on peut voir deux approches ou chemins différents, que nous pouvons emprunter pour ajouter du CI/CD à un projet de code.

  • L'approche la plus simple : je vais ici décrire comment connecter un repo à Azure afin qu'il se déploie ensuite à chaque fois que vous pousserez vers une branche. Je décrirai également des concepts tels que les emplacements de déploiements et je vous expliquerai à quoi cela peut servir. Cet article traitera de cette approche.
  • L'approche la plus avancée : dans cette approche, nous connecterons un repo à un projet Azure DevOps et nous mettrons en place des pipelines de build et des pipelines de déploiement afin que vous puissiez vraiment contrôler chaque étape du processus. Nous utiliserons cette approche dans un article suivant.

V. Démo

Comme évoqué dans la section précédente, nous allons voir comment mettre en place un CI/CD en utilisant l'approche la plus simple. Cela signifie que nous commencerons en utilisant un repo GitHub. Avant d'en arriver là, nous allons créer une application Node.js avec Express. Elle deviendra une API REST avec laquelle nous pourrons interagir via HTTP et une URL de déploiement.

VI. Création du projet

Pour cela, vous aurez besoin d’installer Node.js. Voici un lien vers la page d'installation : https://nodejs.org/fr/download/.

Pour commencer, trouvez-vous un répertoire et ajoutez la commande suivante :

 
Sélectionnez
npm init -y

Cette étape permet de lancer un projet Node.js avec des valeurs par défaut intelligentes. Ensuite, créez un fichier d'application, app.js :

 
Sélectionnez
touch app.js

Ajoutez le code suivant à app.js :

 
Sélectionnez
1.
2.
3.
4.
5.
6.
7.
8.
9.
// app.js

const express = require('express')
const app = express()
const port = process.env.PORT || 3000

app.get('/', (req, res) => res.send('Hello World!'))

app.listen(port, () => console.log(`Example app listening on ${port} port!`))

Ensuite, installez la bibliothèque web express à l’aide de la commande suivante :

 
Sélectionnez
npm i express

Elle s’installera dans un répertoire appelé node_modules.

VII. Ajout de Git

Créez maintenant le repo Git et initialisez-le avec :

 
Sélectionnez
git init

Créez aussi un fichier .gitignore

 
Sélectionnez
touch .gitignore

Ajoutez le contenu suivant au .gitignore :

 
Sélectionnez
node_modules
package-lock.json

Le code ci-dessus permet de s’assurer de ne pas prendre en compte les fichiers et les dossiers dont vous n’avez pas besoin.

Créez un repo sur GitHub. Étant donné que vous n’y avez encore rien poussé, vous devriez voir uniquement le contenu suivant :

 
Sélectionnez
1.
2.
3.
4.
5.
6.
echo "# name of app" >> README.md
git init
git add README.md
git commit -m "first commit"
git remote add origin https://github.com/<your user>/<your app>.git
git push -u origin master

Ensuite, ajoutez simplement le code ci-dessous et pensez à bien ajouter votre nom d’utilisateur et le nom de votre repo.

git remote add origin https://github.com/<your user>/<your app>.git

Avant de pousser le code sur votre nouveau repo GitHub, il faut créer votre premier commit à l’aide des commandes suivantes :

 
Sélectionnez
git add .
git push -m "first commit"

Poussez maintenant le code vers le repo :

 
Sélectionnez
git push -u origin master

VIII. Création d’une application web dans Azure

Maintenant que le code a été poussé dans un repo GitHub, il est temps d’y ajouter le CI/CD. Si vous n’avez pas de compte Azure, vous pouvez en créer un ici : Free Azure account

Rendez-vous sur le portail : portal.azure.com

Nous allons faire deux choses :

  1. Provisionner : nous allons créer une ressource dans laquelle l'application sera située. Nous sélectionnerons le template Web app. Nous aurons ainsi un environnement dédié dans lequel l’application vivra. En fonction des choix que nous ferons par la suite, des bibliothèques y seront installées afin que l’application tourne correctement. Nous n’aurons à effectuer que quelques choix : le reste sera géré automatiquement. Ici, on utilise un PaaS ;
  2. Connecter le repo : une fois que nous avons créé notre ressource web, nous pouvons connecter notre ressource à un repo GitHub. Nous allons faire ça à l’aide d’App Service. Il s’agit d’un service Azure qui va à la fois déployer et faire tourner l’application web pour nous. App Service peut faire un tas d’autres choses pour nous comme gérer la mise à l’échelle (scaling), la sécurité, etc. Dans cette publication, nous l’utilisons pour héberger notre application web.

VIII-A. Provisionner les ressources web

Une fois la connexion effectuée, nous allons créer une web app. Il s’agira pour commencer d’une coquille vide, jusqu’à ce qu’on y pousser du code.

En haut à gauche du portail, vous trouverez le bouton « Créer une ressource ».

Cliquez dessus et tapez Web App dans le champ de recherche. Cliquez sur Créer. Vous allez arriver sur la page suivante :

Image non disponible

  1. Abonnement (Subscription): sélectionnez l'abonnement que vous souhaitez utiliser.
  2. Groupe de ressources (Resource Group) : c'est un regroupement logique. C'est là que vous allez placer toutes les ressources Azure qui vont ensemble comme : bases de données, WebApp, compte de stockage, etc. Vous pouvez choisir de créer une nouvelle ressource ou utiliser une ressource existante.
  3. Le nom (Name) doit être unique, car il fera partie d'une URL globale accessible à tous. L'URL complète sera <name>.azurewebsites.net.
  4. Publier (Publish) : choisir entre Code et Conteneur Docker. Cette fois-ci, nous utiliserons Code, mais nous verrons comment utiliser l'option Conteneur Docker dans un autre article.
  5. Pile d’exécution (Runtime stack): c'est l'endroit où nous pouvons choisir entre différents environnements de code comme Node.js, ASP.NET Core, Python et ainsi de suite. Cela signifie que la machine sur laquelle notre application web sera déployée aura installé les bibliothèques correspondant à votre option. Choisissons Node.js 12 LTS.
  6. Système d'exploitation (Operating System): choisissons Linux pour l'instant. Nous aurions facilement pu choisir Windows également.
  7. Région (Region) : sélectionnez la région la plus proche de vous.
  8. Plan App Service (App Service Plan): sélectionnez le plan par défaut.

Maintenant, cliquez sur Vérifier + Créer et à la dernière étape qui suit, cliquez sur Créer.

VIII-B. Connexion du repo

Cette étape devrait prendre une minute environ. Une fois que tout est bon, vous devriez voir quelque chose comme ça :

Image non disponible

L’onglet Centre de déploiement que vous trouverez dans le menu de gauche est ouvert. Vous devriez voir le titre Déploiement continu. En scrollant vers le bas vous verrez les options.

Image non disponible

Comme vous pouvez le voir, vous pouvez choisir parmi quatre sources de code. Choisissez GitHub.

Ensuite, on vous demandera le nom du fournisseur de générations. Vous avez le choix entre App Service et Azure Pipelines. Choisissez la première option :

Image non disponible

Ensuite, pour la configuration :

  • Organisation (Organization): il s’agit de l’organisation dont vous faites partie sur GitHub ;
  • Référentiel (Repository): le repo que nous venons de créer ;
  • Branche (Branch) : voilà qui est intéressant. Quand vous avez créé votre repository, il comportait uniquement une branche principale. Mais au fur et à mesure qu’il va s’étoffer, il aura des tas de branches, et vous pourrez les utiliser pour votre déploiement bleu/vert et votre A/B testing. Pour l’instant, choisissez la branche principale.

Image non disponible

Une fois que vous avez complété les différents champs, vous verrez une page récapitulative. Cliquez sur Terminer.

Image non disponible

Ce qui suit est une page qui montre l’activité de notre app et l’historique des commits. Vous pouvez voir plus d’infos sur l'état de l’app en cliquant sur l’icône en dessous de Logs :

Image non disponible

La dernière entrée indique que le déploiement est réussi.

Super, est-ce que mon application est en ligne ?

Voyons voir : cliquez sur Aperçu dans le menu de gauche et tapez une adresse sous le titre URL. Roulement de tambours… il se peut que le chargement prenne plusieurs secondes la première fois que vous faites le test, car Azure installe des bibliothèques. Le roulement de tambours continue…

Et maintenant ?

Pas encore, plus que quelques secondes… et voilà !

Narrateur : « C’est une page blanche »

Qu’est-ce qui ne va pas ?

À votre avis, qu’est-ce qu’il se passe ?

Aucune idée, c’est pour ça que je pose la question : qu’est-ce qui ne va pas ?

C’est une application Node, et les applications Node ont besoin de quoi pour tourner ?

Une sorte de commande de démarrage ?

Bingo !

Donc j’ai besoin d’ajouter une instruction à mon package.json.

Oui. Dans la section scripts, ajoutez la commande suivante :

 
Sélectionnez
"start": "node app.js"

Et maintenant ?

Maintenant il faut effectuer un comit sur le repo et le pousser sur GitHub. Grâce à notre configuration, Azure va le récupérer et le redéployer, et l’app devrait fonctionner. Voici la marche à suivre :

  1. Ajouter la modification du code à package.json ;
  2. Git add. ;
  3. Git commit – m « j’ajoute ce changement, car l’auteur de l’article m’a tendu un piège » ;
  4. Git push
Image non disponible

Ça fonctionne ! Mais je n’oublierai pas que tu m’as piégé !

IX. CI

CI signifie intégration continue, et veut dire qu’on intègre du code à un repo dès que possible. De plus, on va chercher à effectuer des tests complémentaires automatisés à chaque changement dans le code. On réalise ces tests pour s’assurer que le composant qu’on est en train de modifier fonctionne toujours et qu’il peut fonctionner correctement avec d’autres composants.

Alors comment ajouter de la CI à tout ça ?

Je sais, je sais ! je pourrais installer Jest, écrire un test, ajouter test à scripts dans package.json et son déploiement échouera en cas d’échec du test ?

Euh… non, désolé. Il te faudrait Azure DevOps pour faire ça. Il faudrait aussi dire à un fichier YAML que tu veux faire ces tests, et ça ne suffit pas de créer des tests et espérer qu’Azure DevOps va en tenir compte. Tout ça est décrit dans la deuxième partie : dans le prochain article.

Quelle déception !

Désolé :)

Mais il y a autre chose que le CD, non ?

Oui, il y a les emplacements de déploiement :)

Et ça fonctionne ?

Oui. Parlons-en maintenant.

X. Les emplacements de déploiement

De quoi s’agit-il ?

Imagine que tu peux déployer sous différents emplacements sous la même URL.

Pourquoi est-ce que je ferais ça ?

Supposons que tu veuilles contrôler le trafic vers ton app, pour que 50 % de ce trafic aillent dans l’un des deux emplacements, et les 50 % restants aillent dans l’autre emplacement. Tu vois où je veux en venir ?

Oui, pour tester des nouvelles versions ou expérimenter je peux envoyer la moitié du trafic à un endroit, et l’autre moitié à un autre ?

Exactement !

X-A. Création des emplacements

Cliquez sur Emplacement de déploiement dans le menu de gauche :

Image non disponible

Nous n’avons pour l’instant qu’un seul emplacement : Production.

Réfléchissons un peu. Comment appeler l’autre emplacement ?

Ça dépend de ce qu’on veut en faire. Et si on faisait un test ?

D’accord. Faisons un test, et mettons l’expérimentation sur une branche secondaire.

On va :

  1. Créer une branche dans git ;
  2. Effectuer des modifications ;
  3. Pousser la branche sur GitHub ;
  4. Créer un emplacement qui a l’air identique à la branche de production. Nous allons la déployer à partir de notre nouvelle branche.

Création de la branche

 
Sélectionnez
git checkout -b feature/new-experiment

Faire les modifications

Petit récap. - notre code ressemble à ça :

 
Sélectionnez
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
// app.js

const express = require('express')
const app = express()
const port = process.env.PORT || 3000

const products = [
  {
    id: 1,
    name: "Star Wars"
  }
];

app.get('/', (req, res) => res.send('Hello World!'))

app.listen(port, () => console.log(`Example app listening on ${port} port!`))

Modifiez le code, et ajoutez le chemin /products. Le code devrait maintenant ressembler à ça :

 
Sélectionnez
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
// app.js

const express = require('express')
const app = express()
const port = process.env.PORT || 3000

const products = [
  {
    id: 1,
    name: "Star Wars"
  }
];

app.get('/', (req, res) => res.send('Hello World!'))
app.get('/products', (req, res) => products)

app.listen(port, () => console.log(`Example app listening on ${port} port!`))

Pousser les changements sur GitHub

Commitez ce code :

 
Sélectionnez
git add.
git commit -m "adding new route /products"

Et poussez-le vers votre repo :

git push.

Vous avez donc poussé cette branche vers GitHub, mais comme votre CD écoute la branche principale, rien ne se passe. Il est temps de créer un emplacement.

Retournez au portail et la ressource de service Web. Sélectionnez Emplacements de déploiements dans le menu de gauche. Ensuite, cliquez sur Ajouter un emplacement dans le menu du haut comme indiqué ci-dessous :

Image non disponible

Vous allez maintenant cloner votre emplacement de production existant, puisqu’il contient presque tout ce que vous allez réutiliser.

Image non disponible

Il faut encore modifier le nom de la branche qui est analysée pour l’application des nouveaux changements.

  1. Sélectionnez votre branche à nouveau en cliquant sur son nom dans la liste. Vous devriez voir une nouvelle page.
  2. Sélectionnez Centre de déploiement dans le menu de gauche.
  3. Cliquez sur GitHub et Suivant.

Ajoutez maintenant le même nom d’Organisation et le même référentiel que pour votre emplacement de production. Remplacez la branche par votre branche secondaire :

Image non disponible

Enregistrez ce nouvel emplacement.

Contrôle du trafic

Maintenant que vous avez deux emplacements de déploiement, vous pouvez décider de la manière dont vous voulez contrôler le trafic vers votre site. Il suffit pour ça de modifier le pourcentage dans la zone de texte à droite de votre emplacement.

Image non disponible

L’objectif de cette expérience, est d'envoyer x % d’utilisateurs vers l’URL de production, et y % vers la branche secondaire. C’est à vous de voir comment évaluer le succès de cette expérience test. Ceci dit, penchons-nous sur ce sujet afin de mieux comprend l’A/B testing. L’objectif de ces tests est de répondre à une question, par exemple « Est-ce que ce design-ci est mieux que celui-là ? ». La notion de « mieux » correspond généralement aux clics ou à l’interaction des utilisateurs avec un contenu. En fonction du résultat, on modifie la page.

On peut aussi faire du A/B testing pour voir ce que les utilisateurs pensent d’un changement logique, par exemple, pour évaluer l’impact d’un changement de pourcentage de réduction d’un article, sur la décision d’achat des utilisateurs.

Comme vous pouvez le voir, les emplacements de déploiement ont deux utilités :

  1. Possibilité de déployer différents contenus à différents emplacements ;
  2. Possibilité de contrôler le trafic en envoyant un certain pourcentage d’utilisateurs vers certains tests.

Le déploiement bleu/vert

Voyons ensemble un autre cas d’usage pour les emplacements de déploiement : le zero downtime deployment. Vous pouvez utiliser cette technique pour mettre à jour votre site web et déployer des changements de manière responsable (resonsible en anglais), de manière à ce que l’utilisateur ne perçoive pas de down-time, d’où l’expression zero downtime.

Que veut dire responsable ? Et bien, quand on fait du déploiement continu, il ne s’agit pas simplement de déployer souvent, il s’agit aussi d’avoir les outils pour corriger rapidement des erreurs. Corriger très rapidement permet aux équipes d’oser déployer souvent. Alors comment corriger les erreurs ? LA réponse : le déploiement bleu/vert : on a deux emplacements. Un emplacement avec le logiciel qui tourne en production, qu’on va appeler l’emplacement de Prod, et on a un autre emplacement avec le logiciel qu’on veut lancer : l’emplacement Canary. On va employer la stratégie suivante :

  1. Migration des utilisateurs : envoyer les utilisateurs progressivement vers l’emplacement Canary ;
  2. Monitoring de l’application et des logs d’erreurs ;
  3. S’il y a des erreurs, renvoyer les utilisateurs Canary vers Prod en baissant le pourcentage Canary à 0 %;
  4. Sinon, s’il n’y a pas d’erreur, augmenter graduellement le nombre d’utilisateurs Canary. À un moment, vous serez suffisamment confiant dans votre release Canary et déciderez qu’il s’agit de votre nouvelle prod. Ce que vous pouvez faire à ce moment-là, c’est sélectionner Swap, ce qui changera Canary en Prod.

Image non disponible

Déployer souvent et sereinement – c'est cool, non ?

X-B. Résumé

Résumons ce que nous avons appris. Il s’agissait ici d’apprendre à ajouter une fonctionnalité de déploiement continu à notre application. Pour ça, nous avons :

  1. Créé une app ;
  2. Poussé l’app dans un repo GitHub ;
  3. Créé une ressource Web App dans Azure ;
  4. Connecté le repo avec notre Web App.

En plus de ça, nous avons également appris à utiliser le concept d’emplacements de déploiement pour faire du A/B testing et du déploiement bleu/vert.

Notez que cette approche est utile pour effectuer des tests sur de petits projets avec un ou deux développeurs, mais elle a ses limites. Pour de l’intégration continue, il est utile d’avoir des portes (gates) et des pipelines. Azure DevOps intègre toutes ces fonctionnalités qui manquent à cette approche, et il s’agit du sujet du prochain article de cette série.

XI. Remerciements Developpez.com

Ce tutoriel est la traduction de Learn how YOU can add CI/CD to your app. Nous tenons à remercier Maud pour la traduction, Claude Leloup pour la relecture orthographique et Malick pour la mise au gabarit et ainsi que la publication.

Vous avez aimé ce tutoriel ? Alors partagez-le en cliquant sur les boutons suivants : Viadeo Twitter Facebook Share on Google+   

  

Copyright © 2020 Chris Noring. Aucune reproduction, même partielle, ne peut être faite de ce site ni de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu'à trois ans de prison et jusqu'à 300 000 € de dommages et intérêts.