Présentation de DevOps

1. Vue d'ensemble

Dans cet article, nous allons comprendre les bases des principes et pratiques DevOps. Nous verrons pourquoi cela est pertinent et utile dans le développement de logiciels. Nous comprendrons également comment nous pouvons adopter DevOps de manière significative et quels outils sont là pour nous aider tout au long de cette aventure.

2. Contexte historique

Nous ne pourrons pas apprécier le DevOps tel qu'il se présente aujourd'hui sans revenir un peu sur l'histoire. Les débuts du développement de logiciels ont été principalement caractérisés par ce que nous appelons la méthodologie en cascade. Cela signifie effectivement que le logiciel a été conceptualisé, conçu, développé, testé et distribué successivement .

Chaque étape était aussi détaillée que possible, car le retour était très coûteux . Cela signifiait effectivement une période d'attente beaucoup plus longue entre la réflexion et l'action. Cependant, ce n'était pas un tel problème car le paysage technologique était beaucoup moins volatil et les perturbations bien trop répandues.

Fait intéressant, ce modèle n'a pas duré longtemps. À mesure que le rythme de la technologie changeait et que les perturbations commençaient à se produire souvent, les entreprises ont commencé à ressentir la chaleur. Ils avaient besoin de nouvelles idées pour être testées plus rapidement . Cela signifiait des changements plus rapides dans tous les aspects de l'entreprise, y compris les logiciels.

Cela a donné naissance à un tout nouveau monde de méthodologies de développement logiciel qui sont vaguement vues sous l'égide d'Agile. Le manifeste agile énonce un ensemble de principes à suivre pour la livraison de logiciels par petits incréments avec une boucle de rétroaction plus rapide . Il existe plusieurs frameworks agiles comme Scrum et Kanban en pratique.

3. Qu'est-ce que DevOps ?

Nous avons vu que le développement incrémentiel avec une rétroaction plus rapide est devenu la pierre angulaire de la livraison de logiciels aujourd'hui. Mais comment y parvenir? Bien que les méthodologies agiles traditionnelles nous amènent à un point raisonnable, elles ne sont toujours pas idéales.

Les méthodologies agiles continuent de se perfectionner alors qu'elles s'efforcent continuellement de briser les silos.

Traditionnellement, nous avons toujours eu des équipes différentes qui étaient responsables du développement et de la livraison des logiciels. Ces équipes opéraient souvent dans leurs silos. Cela s'est effectivement traduit par un cycle de rétroaction beaucoup plus long, ce que nous ne souhaitons pas avec les méthodologies agiles.

Il ne faut donc pas beaucoup de raisonnement pour comprendre que des équipes agiles bien intégrées et interfonctionnelles sont bien mieux adaptées pour atteindre leurs objectifs. DevOps est la pratique qui encourage la communication, la collaboration, l'intégration et l'automatisation entre les équipes de développement logiciel et d'exploitation . Cela nous permet de mieux réaliser un développement incrémentiel avec un retour d'information plus rapide.

Le diagramme suivant explique un flux de travail possible pour pratiquer DevOps:

Bien que nous détaillerons ces étapes plus loin dans le didacticiel, comprenons certains des principes clés de DevOps:

  • Approche centrée sur la valeur (telle que réalisée par l'utilisateur final)
  • Culture collaborative (avec communication, processus et outils efficaces)
  • Automatisation des processus (pour améliorer l'efficacité et réduire les erreurs)
  • Résultats mesurables (à mesurer par rapport aux objectifs)
  • Rétroaction continue (avec une tendance à s'améliorer rapidement)

4. Comment démarrer le voyage?

Bien que la théorie soit simple et attrayante, le vrai défi consiste à pratiquer le DevOps de manière significative. Comme nous l'avons constaté jusqu'à présent, DevOps concerne principalement les personnes, plutôt que les équipes .

Des objectifs communs, une communication efficace et des compétences transversales sont les caractéristiques de ces équipes. Étant donné qu'une grande partie de ce changement est culturel, il est souvent lent et non sans frictions.

4.1. Motivation

Le simple fait qu'il existe une pratique populaire ne la rend pas nécessairement appropriée pour nous. Nous devons comprendre notre motivation pour tout changement, d'autant plus si nous passons à l'agilité. Il est utile de se lancer en définissant les objectifs que l'on souhaite atteindre .

Les objectifs de DevOps dans toute organisation dépendent de l'ambition, de la culture et de la maturité de cette organisation. Voici quelques-uns des objectifs DevOps les plus courants:

  • Meilleure expérience pour les utilisateurs finaux
  • Mise sur le marché plus rapide
  • Temps moyen de récupération amélioré

4.2. Adoption

N'oubliez pas que DevOps n'est pas un état final mais un processus continu d'amélioration pour atteindre les objectifs. Par conséquent, tous les membres de l'équipe doivent s'efforcer d'identifier les obstacles et de les éliminer rapidement . Voici quelques activités qui peuvent nous aider à démarrer:

  • Comprendre clairement l'état actuel de l'idéation au cycle de production
  • Rassemblez certains des goulots d'étranglement évidents et utilisez des métriques pour prendre des décisions factuelles
  • Hiérarchisez les goulots d'étranglement qui ajouteront le plus de valeur lorsqu'ils seront supprimés
  • Définir un plan itératif pour fournir de la valeur de manière incrémentielle pour les éléments prioritaires
  • Suivez les cycles courts de Développer-Déployer-Mesurer pour atteindre les objectifs

5. Pratiques DevOps

Il y a plusieurs pratiques à suivre, mais l'idée ne devrait pas en utiliser comme étalon-or. Nous devons examiner attentivement chaque pratique dans le contexte de notre état et de nos objectifs, puis prendre des décisions éclairées. Cependant, presque toutes les pratiques ont tendance à se concentrer autant que possible sur l'automatisation des processus.

5.1. Planification agile

La planification agile consiste à définir le travail par petits incréments. Bien que l'objectif final doive être clair, il n'est pas nécessaire de définir et de détailler à l'avance l'ensemble de l'application. La clé ici est de hiérarchiser le travail en fonction de la valeur qu'il peut offrir .

Ensuite, il doit être interrompu dans une itération d'incréments courts mais fonctionnels.

5.2. Infrastructure en tant que code (IaC)

Il s'agit de la pratique de gestion et de provisionnement de l'infrastructure via des fichiers de configuration lisibles par machine . Nous gérons également ces configurations dans un système de contrôle de version comme nous gérons notre base de code. Il existe de nombreux langages spécifiques au domaine disponibles pour créer ces fichiers de configuration de manière déclarative.

5.3. Automatisation des tests

Les tests de logiciels sont traditionnellement un effort manuel souvent mené en silos. Cela ne se marie pas bien avec les principes agiles. Par conséquent, il est impératif que nous essayions d'automatiser les tests logiciels à tous les niveaux, tels que les tests unitaires, les tests fonctionnels, les tests de sécurité et les tests de performances .

5.4. Intégration continue (CI)

L'intégration continue consiste à fusionner le code de travail plus souvent par petits incréments dans un référentiel partagé . Habituellement, des builds et des contrôles automatisés sont fréquemment exécutés sur ce référentiel partagé pour nous alerter de toute rupture de code dès que possible.

5.5. Livraison / déploiement continus (CD)

La livraison continue consiste à publier un logiciel par petits incréments dès qu'il réussit tous les contrôles . Ceci est souvent mis en pratique avec l'intégration continue et peut bénéficier d'un mécanisme de libération automatisé (appelé déploiement continu).

5.6. Contrôle continu

La surveillance - peut-être le centre de DevOps - permet des boucles de rétroaction plus rapides. Identifier les bonnes mesures pour surveiller tous les aspects du logiciel, y compris l'infrastructure, est crucial . Le fait de disposer des mesures appropriées, associées à des analyses efficaces en temps réel, peut aider à identifier et à résoudre les problèmes plus rapidement. De plus, il alimente directement la planification agile.

Cette liste est loin d'être complète et est en constante évolution. Les équipes qui pratiquent le DevOps cherchent en permanence de meilleures façons d'atteindre leurs objectifs. Certaines des autres pratiques qui méritent d'être mentionnées sont la conteneurisation, le développement cloud natif et les microservices, pour n'en nommer que quelques-unes.

6. Outils du métier

Aucune discussion sur DevOps ne peut être complète sans parler des outils. C'est un domaine où il y a eu une explosion ces dernières années. Il se peut qu'un nouvel outil soit disponible au moment où nous aurons fini de lire ce didacticiel! Bien que cela soit à la fois tentant et accablant, il faut faire preuve de prudence.

Nous ne devons pas commencer notre aventure DevOps avec des outils comme première chose dans notre esprit. Nous devons explorer et établir nos objectifs, nos personnes (culture) et nos pratiques avant de trouver les bons outils . Pour être clair à ce sujet, voyons quels sont certains des outils qui ont fait leurs preuves à notre disposition.

6.1. Planification

Comme nous l'avons vu, un DevOps mature commence toujours par une planification agile. Bien que les objectifs soient clairs, il suffit de hiérarchiser et de définir le travail pour quelques courtes itérations. Le retour d'expérience de ces premières itérations est inestimable pour façonner les futures et éventuellement l'ensemble du logiciel. Un outil efficace ici nous aiderait à exercer ce processus avec facilité.

Jira est un produit de suivi des problèmes de premier ordre développé par Atlassian. Il dispose de nombreux outils de planification et de surveillance agiles intégrés. Il s'agit en grande partie d'un produit commercial que nous pouvons exécuter sur site ou utiliser en tant qu'application hébergée.

6.2. Développement

L'idée derrière l'agilité est de prototyper plus rapidement et d'obtenir des commentaires sur le logiciel réel. Les développeurs doivent apporter des modifications et fusionner plus rapidement dans une version partagée du logiciel. Il est encore plus important que la communication entre les membres de l'équipe soit fluide et rapide.

Regardons certains des outils omniprésents dans ce domaine.

Git est un système de contrôle de version distribué. C'est assez populaire, et il existe de nombreux services hébergés fournissant des référentiels git et des fonctions à valeur ajoutée. Développé à l'origine par Linus Torvalds, il facilite la collaboration entre les développeurs de logiciels.

Confluence est un outil de collaboration développé par Atlassian . La collaboration est la clé du succès pour toute équipe agile. La sémantique réelle de la collaboration est assez contextuelle, mais un outil qui rend un effort transparent est néanmoins inestimable. Confluence adapte cet endroit avec précision. De plus, il s'intègre bien avec Jira!

Slack est une plate-forme de messagerie instantanée développée par Slack Technologies. Comme nous en avons discuté, les équipes agiles devraient être capables de collaborer et de communiquer, de préférence en temps réel . Outre la messagerie instantanée, Slack offre de nombreuses façons de communiquer avec un seul utilisateur ou un groupe d'utilisateurs - et il s'intègre bien avec d'autres outils comme Jira et GitHub!

6.3. L'intégration

Les modifications fusionnées par les développeurs doivent être inspectées en permanence pour vérifier leur conformité. Ce qui constitue la conformité est spécifique à l'équipe et à l'application. Cependant, il est courant de voir l'analyse de code statique et dynamique, ainsi que les mesures métriques fonctionnelles et non fonctionnelles, comme des composants de la conformité.

Examinons brièvement quelques outils d'intégration populaires.

Jenkins est un serveur d'automatisation convaincant, open source et gratuit. Il existe dans l'industrie depuis des années et a suffisamment mûri pour répondre à un large éventail de cas d'utilisation d'automatisation. Il offre un moyen déclaratif de définir une routine d'automatisation et une variété de façons de la déclencher automatiquement ou manuellement. De plus, il dispose d'un riche ensemble de plugins qui servent plusieurs fonctionnalités supplémentaires pour créer de puissants pipelines d'automatisation.

SonarQube est une plateforme d'inspection continue open source développée par SonarSource. SonarQube dispose d'un riche ensemble de règles d'analyse statique pour de nombreux langages de programmation. Cela permet de détecter les odeurs de code le plus tôt possible. De plus, SonarQube propose un tableau de bord qui peut intégrer d'autres métriques telles que la couverture du code, la complexité du code et bien d'autres. Et cela fonctionne bien avec Jenkins Server.

6.4. Livraison

Il est important d'apporter rapidement des changements et de nouvelles fonctionnalités au logiciel. Dès que nous avons établi que les changements fusionnés dans le référentiel sont conformes à nos normes et politiques, nous devrions être en mesure de les fournir rapidement aux utilisateurs finaux. Cela nous aide à recueillir des commentaires et à mieux façonner le logiciel.

Il existe plusieurs outils ici qui peuvent nous aider à automatiser certains aspects de la livraison au point où nous réalisons un déploiement continu.

Docker est un outil répandu pour la conteneurisation rapide de tout type d'application. Il exploite la virtualisation au niveau du système d'exploitation pour isoler les logiciels dans des packages appelés conteneurs. La conteneurisation a un avantage immédiat en termes de livraison de logiciels plus fiable . Les conteneurs Docker se parlent via des canaux bien définis. De plus, c'est assez léger par rapport à d'autres moyens d'isolation comme les machines virtuelles.

Chef / Puppet / Ansible sont des outils de gestion de configuration. Comme nous le savons, une instance en cours d'exécution réelle d'une application logicielle est une combinaison de la construction de la base de code et de ses configurations. Et si la construction de la base de code est souvent immuable dans les environnements, les configurations ne le sont pas. C'est là que nous avons besoin d'un outil de gestion de configuration pour déployer notre application avec facilité et rapidité . Il existe plusieurs outils populaires dans cet espace, chacun ayant ses particularités, mais Chef, Puppet et Ansible couvrent à peu près les bases.

HashiCorp Terraform peut nous aider avec le provisionnement d'infrastructure , qui a été une tâche fastidieuse et longue depuis l'époque des centres de données privés. Mais avec l'adoption croissante du cloud, l'infrastructure est souvent considérée comme une construction jetable et répétable. Cependant, cela ne peut être réalisé que si nous disposons d' un outil avec lequel nous pouvons définir une infrastructure simple à complexe de manière déclarative et la créer en un clic . Cela peut ressembler à une séquence de rêve, mais Terraform essaie activement de combler cet écart!

6.5. surveillance

Enfin, pouvoir observer le déploiement et le mesurer par rapport aux objectifs est essentiel. Il peut y avoir une multitude de mesures que nous pouvons collecter à partir des systèmes et des applications. Celles-ci incluent certaines des métriques métier spécifiques à notre application.

L'idée ici est de pouvoir collecter, organiser, stocker et analyser ces métriques presque en temps réel. Il existe plusieurs nouveaux produits, à la fois open source et commerciaux, qui sont disponibles dans cet espace.

Elastic-Logstash-Kibana (ELK) est une pile de trois projets open source - Elasticsearch, Logstash et Kibana. Elasticsearch est un moteur de recherche et d'analyse hautement évolutif. Logstash nous fournit un pipeline de traitement de données côté serveur capable de consommer des données provenant d'une grande variété de sources. Enfin, Kibana nous aide à visualiser ces données. Ensemble, cette pile peut être utilisée pour agréger des données telles que des journaux de toutes les applications et les analyser en temps réel .

Prometheus est un outil open-source de surveillance et d'alerte du système développé à l'origine par SoundCloud. Il est livré avec un modèle de données multidimensionnel, un langage de requête flexible et peut extraire des données chronologiques via HTTP. Grafana est une autre solution d'analyse et de surveillance open source qui fonctionne avec plusieurs bases de données. Ensemble, Prometheus et Grafana peuvent nous donner une idée en temps réel de pratiquement toutes les métriques que nos systèmes sont capables de produire .

7. Extensions DevOps (ou le sont-elles vraiment!)

Nous avons vu que DevOp, fondamentalement, est un effort continu pour éliminer les obstacles à une livraison de logiciels plus rapide et itérative basée sur la valeur. Maintenant, une des conclusions immédiates est qu'il ne peut y avoir d 'état final ici.

Ce que les gens ont compris comme une friction entre les équipes de développement et d'exploitation n'est pas la seule friction. Briser les silos au sein d'une organisation pour accroître la collaboration est l'idée centrale. Maintenant, les gens ont rapidement commencé à se rendre compte que des frictions similaires existaient entre les équipes de développement et de test, et entre les équipes de développement et de sécurité . De nombreuses configurations traditionnelles ont des équipes de sécurité et de performance dédiées.

Le plein potentiel de DevOps ne pourra jamais être réalisé tant que nous ne pourrons pas briser presque toutes les frontières entre les équipes et les aider à collaborer beaucoup plus efficacement. Cela signifie intrinsèquement intégrer des équipes telles que les tests, la sécurité et les performances .

La confusion est en grande partie dans sa nomenclature. DevOps nous fait comprendre qu'il s'agit principalement d'équipes de développement et d'exploitation. Ainsi, au fil du temps, de nouveaux termes sont apparus, englobant d'autres équipes. Mais en grande partie, c'est juste que DevOps est réalisé plus efficacement!

7.1. DevTestOps

La pierre angulaire de DevOps est de fournir des logiciels de haute qualité par petits incréments et plus souvent. L'accent mis sur la qualité comporte ici de nombreux aspects. Dans un sens, nous supposons souvent que les pratiques DevOps que nous adoptons nous aideront à atteindre cet objectif. Et il est également vrai que bon nombre des pratiques dont nous avons discuté précédemment visent à garantir une qualité élevée à tout moment.

Mais les tests fonctionnels des logiciels ont une portée beaucoup plus large. Très souvent, nous avons tendance à conserver les tests d'ordre supérieur comme les tests de bout en bout vers la fin de la livraison du logiciel. Plus important encore, c'est souvent la responsabilité d'une équipe distincte qui s'engage tardivement dans le processus. C'est là que les choses commencent à s'écarter des principes DevOps.

Ce que nous devrions plutôt faire, c'est intégrer les tests logiciels, à tous les niveaux, dès le début . Dès la phase de planification, les tests de logiciels doivent être considérés comme un aspect intégral de la livraison. De plus, la même équipe devrait être responsable du développement et du test du logiciel. C'est ce que la pratique de DevTestOps est largement connue. Ceci est souvent également appelé test continu et décalage vers la gauche.

7.2. DevSecOps

La sécurité fait partie intégrante de tout développement logiciel et a sa part de complexité. Cela signifie souvent que nous avons une équipe distincte de spécialistes de la sécurité avec qui nous collaborons dès que nous sommes prêts à expédier le produit. Les vulnérabilités qu'ils identifient à ce stade peuvent être coûteuses à corriger. Encore une fois, cela ne résonne pas bien avec les principes de DevOps.

À ce stade, nous devrions déjà avoir la solution que nous devons appliquer, et c'est-à-dire que nous devrions aborder les problèmes de sécurité et le personnel au début du jeu . Nous devons motiver les équipes à réfléchir à la sécurité à chaque étape. La sécurité est sans aucun doute un domaine très spécialisé, et nous pouvons donc avoir besoin de faire appel à un spécialiste au sein de l'équipe. Mais l'idée ici est de considérer certaines des meilleures pratiques dès le début.

Au fur et à mesure que nous progressons, il existe plusieurs outils disponibles qui peuvent automatiser l'analyse d'un grand nombre de vulnérabilités . Nous pouvons également le brancher dans nos cycles d'intégration continue pour obtenir un retour rapide! Maintenant, nous ne pouvons pas tout intégrer dans l'intégration continue car nous devons le garder léger, mais il peut toujours y avoir d'autres analyses périodiques exécutées séparément.

8. Conclusion

Dans cet article, nous avons passé en revue les bases des principes, pratiques et outils DevOps disponibles. Nous avons compris le contexte dans lequel DevOps est pertinent et les raisons pour lesquelles il peut nous être utile. Nous avons également discuté brièvement par où commencer dans le processus d'adoption de DevOps.

De plus, nous avons abordé certaines des pratiques et outils populaires que nous pouvons utiliser dans ce voyage. Nous avons également compris certains des autres termes populaires autour de DevOps tels que DevTestOps et DevSecOps.

Enfin, nous devons comprendre que DevOps n'est pas un état final, mais plutôt un voyage qui ne finira peut-être jamais! Mais la partie amusante ici est le voyage lui-même. Pendant tout ce temps, nous ne devons jamais perdre de vue nos objectifs et nous devons nous concentrer sur les principes clés. Il est assez facile de tomber sous le charme d'un outil ou d'un terme populaire dans l'industrie. Mais nous devons toujours nous rappeler que tout n'est utile que si cela nous aide à offrir plus efficacement de la valeur à notre public.