🥇Guide pour les débutants : créons un pipeline DevOps

Si vous êtes novice en DevOps, consultez ce guide pour créer votre premier pipeline en cinq étapes.

Le DevOps est devenu la solution standard pour remédier aux processus de développement logiciel lents, déconnectés ou non fonctionnels. Le problème, c'est que si vous êtes nouveau dans DevOps et ne savez pas par où commencer, vous risquez de manquer de compréhension de ces méthodes. Cet article s'intéresse à la définition d'un pipeline DevOps et propose un guide pour en créer un en cinq étapes. Bien que ce tutoriel ne soit pas exhaustif, il devrait vous fournir une base pour commencer votre parcours et élargir vos connaissances à l'avenir. Commençons par l'histoire.

Mon voyage dans le DevOps

J'ai auparavant travaillé au sein de l'équipe cloud de Citi Group, développant une application web Infrastructure-as-a-Service (IaaS) pour gérer l'infrastructure cloud de Citi, mais j'ai toujours été intéressé par la manière de rendre le processus de développement plus efficace et d'apporter des changements culturels positifs à l'équipe de développeurs. La réponse, je l'ai trouvée dans un livre recommandé par Greg Lavender, directeur technique de Citi pour l'architecture cloud et l'infrastructure. Le livre s'intitulait « The Phoenix Project »The Phoenix Project, et il explique les principes du DevOps tout en se lisant comme un roman.

Le tableau au dos du livre montre à quelle fréquence différentes entreprises déploient leurs systèmes dans un environnement de production :

Amazon : 23 000 par jour
Google : 5 500 par jour
Netflix : 500 par jour
Facebook : Une fois par jour
Twitter : 3 fois par semaine
Entreprise type : Une fois tous les 9 mois

Comment est-il possible pour Amazon, Google et Netflix d'atteindre de telles fréquences ? Tout simplement parce que ces entreprises ont découvert comment concevoir un pipeline DevOps presque parfait.

Nous étions loin de cela jusqu'à ce que nous introduisions DevOps chez Citi. À cette époque, mon équipe travaillait avec différents environnements, mais le déploiement sur le serveur de développement était entièrement manuel. Tous les développeurs n'avaient accès qu'à un seul serveur de développement basé sur IBM WebSphere Application Server Community Edition. Le problème était que le serveur s'éteignait dès que plusieurs utilisateurs essayaient de déployer simultanément, ce qui obligeait les développeurs à se communiquer leurs intentions, ce qui était assez pénible. De plus, il y avait des problèmes de couverture de code à bas niveau, des processus manuels de déploiement encombrants et l'absence de possibilité de suivre le déploiement du code lié à une tâche ou une histoire utilisateur spécifique.

J'ai réalisé qu'il fallait faire quelque chose et j'ai trouvé un collègue partageant les mêmes idées. Nous avons décidé de collaborer pour créer un premier pipeline DevOps – il a installé une machine virtuelle et un serveur d'applications Tomcat pendant que je travaillais sur Jenkins, intégrant Atlassian Jira et BitBucket, et travaillant également sur la couverture de code. Ce projet secondaire a été très réussi : nous avons presque entièrement automatisé de nombreux processus, atteint presque 100 % de disponibilité de notre serveur de développement, assuré le suivi et amélioré la couverture de code, et ajouté la possibilité de lier des branches dans Git aux tâches dans Jira ou aux déploiements. La plupart des outils que nous avons utilisés pour construire notre pipeline DevOps étaient open source.

Maintenant, je comprends à quel point notre pipeline DevOps était simple : nous n'utilisions pas d'extensions comme Jenkins files ou Ansible. Cependant, ce pipeline simple fonctionnait bien, peut-être grâce au principe de Pareto (également connu sous le nom de règle 80/20).

Introduction rapide à DevOps et au pipeline CI/CD

Si vous demandez à plusieurs personnes : « Qu'est-ce que DevOps ? », vous obtiendrez probablement plusieurs réponses différentes. DevOps, tout comme Agile, a évolué pour englober de nombreuses disciplines différentes, mais la plupart des gens s'accordent à dire certaines choses : DevOps est une pratique de développement logiciel ou un cycle de vie de développement logiciel (SDLC), dont le principe central est le changement de culture, où développeurs et non-développeurs coexistent dans un environnement où :

Les opérations qui étaient auparavant effectuées manuellement sont automatisées ;
Chacun fait ce qu'il sait faire le mieux ;
Le nombre de déploiements sur une période donnée augmente ; La capacité est accrue ;
La flexibilité du développement est améliorée.

Bien que posséder les bons outils logiciels ne soit pas la seule condition pour créer un environnement DevOps, certains outils sont nécessaires. L'outil clé est l'intégration continue et le déploiement continu (CI/CD). Dans ce pipeline, les environnements ont différentes étapes (par exemple, DEV, INT, TST, QA, UAT, STG, PROD), de nombreuses opérations sont automatisées, et les développeurs peuvent écrire du code de haute qualité, atteindre la flexibilité du développement et une haute fréquence de déploiements.

Cet article décrit une approche en cinq étapes pour créer un pipeline DevOps, similaire à celui illustré dans le diagramme suivant, en utilisant des outils open source.

Étape 1 : Méthodes CI/CD

La première chose dont vous avez besoin est un outil pour CI/CD. Jenkins, un outil open source basé sur Java et distribué sous licence MIT, est le moyen qui a popularisé la direction DevOps et est devenu le standard de facto.

Alors, qu'est-ce que Jenkins ? Considérez-le comme une sorte de télécommande universelle magique qui peut communiquer avec divers services et outils et les organiser. En soi, un outil CI/CD comme Jenkins est inutile, mais il devient plus puissant à mesure qu'il se connecte à différents outils et services.

Jenkins n'est qu'un des nombreux outils open source pour CI/CD que vous pouvez utiliser pour construire un pipeline DevOps.

Jenkins : Creative Commons et MIT
Travis CI : MIT
CruiseControl : BSD
Buildbot : GPL
Apache Gump : Apache 2.0
Cabie : GNU

Voici à quoi ressemblent les processus DevOps avec un outil CI/CD :

Vous avez un outil CI/CD fonctionnant sur votre localhost, mais pour le moment, vous ne pouvez pas faire grand-chose. Passons à l'étape suivante de notre voyage dans le monde DevOps.

Étape 2 : Gestion des systèmes de contrôle de version

La meilleure (et peut-être la plus simple) manière de vérifier que votre outil CI/CD peut faire des merveilles est de s'intégrer à un outil de contrôle de version (SCM). Pourquoi avez-vous besoin d'un contrôle de version ? Supposons que vous développiez une application. Chaque fois que vous créez une application, vous programmez, et peu importe si vous utilisez Java, Python, C++, Go, Ruby, JavaScript ou l'un des milliards de langages de programmation. Le code que vous écrivez est appelé le code source. Au début, surtout lorsque vous travaillez seul, il est probablement possible de tout placer dans un répertoire local. Mais lorsque le projet devient plus conséquent et que vous invitez d'autres personnes à collaborer, vous avez besoin d'un moyen d'éviter les conflits lors d'un échange efficace des modifications. Vous avez également besoin d'un moyen de restaurer les versions antérieures, car créer des sauvegardes et le copier/coller dans celles-ci est désormais obsolète. Vous (et vos collègues) avez besoin de quelque chose de mieux.

C'est ici que le système de contrôle de version devient pratiquement indispensable. Cet outil sauvegarde votre code dans des dépôts, gère les versions et coordonne le travail des participants au projet.

Bien qu'il existe de nombreux systèmes de contrôle de version, Git est la référence, et c'est vrai. Je vous recommande vivement d'utiliser Git, même s'il existe d'autres options open-source.

Git : GPLv2 et LGPL v2.1
Subversion : Apache 2.0
Concurrent Versions System (CVS) : GNU
Vesta : LGPL
Mercurial : GNU GPL v2+

Voici à quoi ressemble un pipeline DevOps avec l'ajout de systèmes de contrôle de version.

Un outil CI/CD peut automatiser les processus de vérification, d'obtention du code source et de collaboration entre les membres. Pas mal, non ? Mais comment transformer cela en application fonctionnelle pour que des milliards de personnes puissent l'utiliser et l'apprécier ?

Étape 3 : Création de l'outil d'automatisation de construction

Super ! Vous pouvez vérifier le code et apporter des modifications au système de contrôle de version, ainsi qu'inviter vos amis à collaborer au développement. Mais vous n'avez pas encore créé d'application. Pour créer une application web, il faut la compiler et la conditionner dans un format de paquet déployable ou la lancer sous forme de fichier exécutable. (Notez que les langages de programmation interprétés, tels que JavaScript ou PHP, n'ont pas besoin d'être compilés).

Utilisez un outil d'automatisation de la construction. Peu importe l'outil d'automatisation de la construction que vous choisissez d'utiliser, tous ont le même objectif : compiler le code source dans un format souhaité et automatiser la tâche de nettoyage, de compilation, de test et de déploiement dans un environnement spécifique. Les outils de construction varieront en fonction de votre langage de programmation, mais voici quelques options courantes open source.

Nom
Licence
Langage de programmation

Maven
Apache 2.0
Java

Ant
Apache 2.0
Java

Gradle
Apache 2.0
Java

Bazel
Apache 2.0
Java

Make
GNU
N/A

Grunt
MIT
JavaScript

Gulp
MIT
JavaScript

Buildr
Apache
Ruby

Rake
MIT
Ruby

A-A-P
GNU
Python

SCons
MIT
Python

BitBake
GPLv2
Python

Cake
MIT
C#

ASDF
Expat (MIT)
LISP

Cabal
(un système de distribution de logiciels), les premières sources avaient déjà le numéro de version 4.3. Pendant un certain temps, le serveur DNS était utilisé par les membres des laboratoires de l'université. Jusqu'à la version 4.8.3, le développement de BIND a été dirigé par des membres du Computer Systems Research Group (CSRG) de l'Université de Berkeley, mais dans la seconde moitié des années 1980, le serveur DNS a dépassé les murs de l'université — il a été remis à Paul Vixie de la société
Haskell

Génial ! Vous pouvez placer les fichiers de configuration de l'outil d'automatisation de la construction dans le système de gestion de version et permettre à votre outil CI/CD de tout rassembler.

Tout va bien, n'est-ce pas ? Mais où déployer votre application ?

Étape 4 : Serveur pour applications web

Pour l'instant, vous avez un fichier emballé qui peut être exécutable ou installable. Pour qu'une application soit réellement utile, elle doit fournir un service ou une interface, mais vous avez besoin d'un conteneur pour héberger votre application.

Le serveur pour applications web est justement ce conteneur. Le serveur fournit un environnement dans lequel la logique du paquet déployable peut être définie. Il offre également une interface et propose des services web, en ouvrant des sockets vers le monde extérieur. Vous avez besoin d'un serveur HTTP ainsi que d'un environnement (par exemple, une machine virtuelle) pour l'installer. En attendant, supposons que vous apprendrez cela plus tard (bien que je parlerai des conteneurs ci-dessous).

Il existe plusieurs serveurs d'applications web open source.

Nom
Licence
Langage de programmation

Tomcat
Apache 2.0
Java

Jetty
Apache 2.0
Java

WildFly
GNU Lesser Public
Java

GlassFish
CDDL & GNU Less Public
Java

Django
3-Clause BSD
Python

Tornado
Apache 2.0
Python

Gunicorn
MIT
Python

Python
MIT
Python

Rails
MIT
Ruby

Node.js
MIT
Javascript

Votre pipeline DevOps est presque prêt à l'emploi. Bon travail !

Bien que vous puissiez vous arrêter là et vous occuper de l'intégration vous-même, la qualité du code est importante pour les développeurs d'applications, et il est essentiel de s'en préoccuper.

Étape 5 : Couverture des tests de code

La mise en œuvre des tests peut être une exigence fastidieuse, mais les développeurs doivent identifier les erreurs dans l'application dès le début et améliorer la qualité du code pour garantir la satisfaction des utilisateurs finaux. Heureusement, il existe de nombreux outils open source pour tester votre code et fournir des recommandations d'amélioration de sa qualité. Mieux encore, la plupart des outils CI/CD peuvent se connecter à ces outils et automatiser le processus.

Les tests de code se composent de deux parties : des frameworks de test qui aident à écrire et à exécuter des tests, et des outils de suggestion qui aident à améliorer la qualité du code.

Systèmes de test de code

Nom
Licence
Langage de programmation

JUnit
Licence publique Eclipse
Java

EasyMock
Apache
Java

Mockito
MIT
Java

PowerMock
Apache 2.0
Java

Pytest
MIT
Python

Hypothesis
Mozilla
Python

Tox
MIT
Python

Systèmes de recommandations pour l'amélioration du code

Nom
Licence
Langage de programmation

Cobertura
GNU
Java

CodeCover
Eclipse Public (EPL)
Java

Coverage.py
Apache 2.0
Python

Emma
Licence publique commune
Java

JaCoCo
Licence publique Eclipse
Java

Hypothesis
Mozilla
Python

Tox
MIT
Python

Jasmine
MIT
JavaScript

Karma
MIT
JavaScript

Mocha
MIT
JavaScript

Jest
MIT
JavaScript

Notez que la plupart des outils et frameworks mentionnés ci-dessus sont écrits pour Java, Python et JavaScript, car C++ et C# sont des langages propriétaires (bien que GCC soit open source).

Maintenant que vous avez mis en œuvre des outils de couverture des tests de code, votre pipeline DevOps devrait ressembler au diagramme montré au début de ce guide.

Étapes supplémentaires

Conteneurs

Comme je l'ai déjà mentionné, vous pouvez héberger votre serveur sur une machine virtuelle ou un serveur, mais les conteneurs sont une solution populaire.

Qu'est-ce que les conteneurs ? En résumé, une machine virtuelle nécessite une grande quantité de mémoire du système d'exploitation, dépassant la taille de l'application, tandis qu'un conteneur n'a besoin que de quelques bibliothèques et configurations pour exécuter l'application. Il est évident que les machines virtuelles ont toujours des cas d'utilisation importants, mais un conteneur est une solution légère pour héberger une application, y compris un serveur d'applications.

Bien qu'il existe d'autres options de conteneurs, les plus populaires sont Docker et Kubernetes.

Docker : Apache 2.0
Kubernetes : Apache 2.0

Moyens d'automatisation intermédiaire

Notre pipeline DevOps est principalement axé sur la création et le déploiement collaboratifs d'applications, mais il existe de nombreuses autres choses à réaliser avec des outils DevOps. L'une d'elles est l'utilisation d'outils Infrastructure as Code (IaC), également connus sous le nom de moyens d'automatisation intermédiaire. Ces outils aident à automatiser l'installation, la gestion et d'autres tâches pour les logiciels intermédiaires. Par exemple, un outil d'automatisation peut extraire des applications telles qu'un serveur d'applications, une base de données et un outil de surveillance, avec les bonnes configurations, et les déployer sur le serveur d'applications.

Voici quelques outils d'automatisation intermédiaire open source :

Ansible : GNU Public
SaltStack : Apache 2.0
Chef : Apache 2.0
Puppet : Apache ou GPL

Découvrez les détails pour acquérir une profession recherchée depuis le début ou monter en niveau avec vos compétences et salaire en suivant des cours en ligne payants de SkillFactory :