Automatisation as a service…
par la mise à disposition de chaînes de traitement
ou pipeline à l’échelle d’une organisation
Répondre plus rapidement aux nouveaux besoins pour rester compétitif
Dans un contexte où prendre du retard sur la concurrence se traduit par un impact direct sur leur économie, les organisations ne peuvent plus rester inertes. Il leur faut sans cesse apporter de la nouveauté à leurs clients, des services innovants, de la valeur ajoutée et ainsi se démarquer. Il est également indispensable de donner une image de dynamisme, de montrer sa capacité à avancer rapidement et démontrer ainsi sa réactivité à répondre aux besoins futurs.
L’automatisation en continue pour faire mieux et plus vite
Le DevOps tente d’apporter une réponse à ce besoin en visant à réduire le temps nécessaire pour aller de l’idée à la réalité. Un des axes essentiels mis en avant par la mouvance DevOps est l’automatisation par la mise en place de chaînes d’intégration continue (CI), de livraison et déploiement continu (CD), mais aussi de tests de non-régression continus ou encore d’analyse de qualité et de scan de sécurité continu etc. En 2017, le mantra du DevOps devient « automation, automation and automation » (automatisation, automatisation et automatisation).
Cette idée de « mouvement continu » remonte bien longtemps avant l’informatique et le DevOps. Les grecques ou assyriens l’utilisaient déjà à des fins de convoyage de matériaux pour l’exploitation minière ou lors de constructions. Avec le métier à tisser, Léonard de Vinci propose au XVIeme siècle une conception ou l’opérateur se contente de répéter de façon automatique les mêmes gestes. Puis à l’ère industriel, le travail à la chaîne fait son apparition lors de l’exposition universelle de 1862 avec toujours ce même objectif d’accroitre le rendement, d’améliorer la puissance productive.
Appliquer le « mouvement continu » qui a déjà fait ses preuves à travers le temps dans de nombreux domaines et pousser à l’automatisation apparaît ainsi comme un excellent point de départ et une préconisation pertinente du DevOps.
Les pipelines facilitent la mise en place d’automatisation
Intéressons-nous alors à la mise en œuvre. Pour ce faire, GitLab propose un outil très pratique, les pipelines ou chaînes de traitements. Ces derniers sont définis « as code », c’est à dire par du code et en l’occurrence le langage yaml. Ce n’était pas le cas des premiers pipelines de CI proposés par Jenkins, qui étaient construits à l’aide d’une interface Web avant l’introduction d’un DSL Groovy (Domain Specific Language – un langage propre à la programmation de pipeline Jenkins). Depuis les solutions de CI/CD comme GitHub Action, Attlassian Pipes, AWS CodeDeploy ou Google CloudBuild se sont toutes alignées sur l’utilisation du yaml pour décrire les pipelines.
Dans le but d’offrir de larges possibilités d’intégration avec n’importe quel système, les pipelines peuvent être déclenchés par un appel d’API. Si vous utilisez GitLab (ou simplement Git) pour le versionning du code source, qu’il s’agisse du code d’une application, d’une infrastructure ou même d’un pipeline, ils peuvent de plus être déclenchés en fonction des événements suivants :
• git push
• création d’un tag ou d’une branche
• création d’une « merge request » (ou « pull request ») ou modification de son contenu
• déclenchement manuel via l’interface web (CI / CD > Pipelines > Run Pipeline)
• déclenchement à une date souhaitée ou une fréquence souhaitée (Schedules – CI / CD > Schedules)
• déclenchement depuis une autre pipeline en utilisant le mot clé trigger
Pipeline « as socle »
Malgré le bel effort fourni par GitLab pour simplifier son installation et celle de ses runners chargés de l’exécution des pipelines, implémenter l’automatisation propre à chacune de vos applications est un travail conséquent parfois même plus lourd encore que celui de l’application elle-même.
A l’instar de l’automatisation, c’est aussi le cas de tout nouveau socle applicatif ou technique sur lequel repose les applications. Ces socles requièrent de l’énergie pour être construits et stabilisés au même titre qu’une application. Pour cette raison, les organisations qui comptent un large patrimoine d’applications limitent leur nombre et encadrent les nouveaux développements pour standardiser et aligner au maximum les applications sur un socle commun. Ce même principe est à appliquer à la CI/CD. L’automatisation et les pratiques de développement doivent être alignées comme le sont les socles. Si nous allons plus loin, un socle ne devrait plus être distribué sans être lui-même construit à l’aide de chaînes de traitements pour profiter des mêmes bénéfices qu’attendus pour les applications. Mais avant tout, un socle ne devrait plus être proposé aux équipes projet sans mettre à disposition une automatisation par défaut. Les pipelines de CI/CD doivent ainsi faire partie intégrante des socles applicatifs et techniques.
Avec AutoDevOps, GitLab va encore plus loin en proposant un pipeline unique couvrant les langages de programmation Java, python, ruby ou encore PHP montrant ainsi le chemin vers encore plus de mutualisation et standardisation.
Convaincre d’améliorer un pipeline profitant largement aux équipes projet à l’échelle de l’organisation sera toujours plus aisé que dans le cas où l’évolution ne profite qu’à un unique projet et une population limitée.
Continuer d’expérimenter
Attention cependant à ne pas se priver des bonnes idées venant des équipes utilisatrices confrontées à la réalité du terrain en les contraignant à utiliser le standard sans concession. Il est au contraire intéressant d’encourager les contributions (si possible sous forme de « merge request » ou « pull request ») pour que le travail de chacun puisse être partagé et profiter au plus grand nombre. Une équipe souhaite repartir de zéro ? Tant qu’elle est consciente des difficultés qu’elle va rencontrer avec un objectif précis, évitons de faire barrage. Vous obtiendrez au mieux la prochaine itération de votre automatisation souhaitée et au pire une expérimentation qui vous permettra de gagner en expérience.
Conçu pour être automatisé (Design for automation)
Le vrai piège que vous souhaitez éviter est de tenter d’automatiser un existant, qui n’a pas été conçu pour être automatisé. En se limitant à automatiser un existant sans le repenser pour en faciliter son automatisation, vous risquez en effet non seulement d’être confrontés à une forte complexité, de dépenser beaucoup d’énergie, mais aussi de parvenir à un résultat à peine satisfaisant.
La facilité de mise en œuvre de l’automatisation, d’intégration à une chaîne de CI/CD est une nouvelle exigence technique sur laquelle il n’est plus raisonnable de faire l’impasse lors d’un choix de solution ou d’architecture. Et comme tout exigence technique, une prise en compte tardive peut conduire à la réécriture partielle ou voire quasi-total d’un projet ou d’une solution.
Continuer de progresser
S’il est très facile de se décider à s’engager dans la voie de l’automatisation, savoir ensuite évaluer son avancement, le gain obtenu et la cible à atteindre est une tout autre affaire.
La première étape est d’élever la couverture de code des tests d’intégration et ainsi de détecter en continue les éventuelles régressions et d’en réduire le risque. De cette façon, l’introduction de dysfonctionnements lors des évolutions futures est maîtrisée. Ensuite il faut penser à la qualité du code (voire l’article de Martin Fowler sur le sujet). La performance, la sécurité, les déploiements d’infrastructures et d’applications, la mise en place de SLO (Service Level Objectives – Niveau de service attendu) et pour y répondre peut-être même ce que Google a introduit le concept de « Error budget » (dans son e-book sur SRE). Ce dernier est indexé sur le niveau de service et vous autorise les mises en production seulement si les indicateurs sont bons. Dans le cas contraire, un effort de stabilisation est demandé à l’équipe projet et il faudra attendre que les indicateurs redeviennent bons avant toutes opérations.
Par conséquent, le chemin s’avère long et il ne s’arrête pas là. En effet même en dehors de la CI/CD, ce que vous faites peut peut-être être également automatisé : ouvrir une issue pour la rétrospective avant chaque fin de sprint (voire comment GitLab gère ses rétrospectives mensuelles), déclencher l’envoi de mail et la publication de messages pour signaler la mise à disposition d’une nouvelle version, ajouter / retirer un membre, créer de nouveaux projets en respectant votre politique (2FA, code record, etc.).
C’est pourquoi, il est intéressant de maintenir une collection de pipelines « fer de lance » recommandée aux projets et d’autres moins matures, mais qui permettent de couvrir des besoins ou technologies différents. En s’inspirant de vos pipelines les plus avancés, les équipes projet peuvent elles-aussi contribuer en améliorant les pipelines moins matures qu’elles utilisent (Netflix parle de « paved road » ou « route pavée »).
Et vous, à quelle étape d’automatisation êtes-vous ? L’automatisation vous semble-t-elle une nécessité ? Avez-vous des remarques ou recettes à partager sur ce sujet ?
Références
Google – SRE book : https://landing.google.com/sre/sre-book/chapters/embracing-risk/#id-na2u1S2SKi1
Martin Fowler – Qualité du code : https://martinfowler.com/articles/is-quality-worth-cost.html
Netflix – “paved road” : https://www.oreilly.com/library/view/oscon-2017-/9781491976227/video306724.html
GitLab – Retrospective automatisée : https://about.gitlab.com/2019/03/07/how-we-used-gitlab-to-automate-our-monthly-retrospectives/
