DevOps est un mot à la mode qui est souvent répandu. En fait, il s'agit d'un ensemble de principes conçus pour rationaliser et régir l'ensemble du processus de développement, du cerveau de vos programmeurs à vos serveurs.

Les bases

La plupart des équipes peuvent probablement diviser leurs développeurs en deux grandes catégories:

• Les développeurs, qui gèrent la mise à jour de la base de code, la correction des bogues et tout autour de la programmation. Vous pouvez également inclure d'autres rôles, tels que les concepteurs Web et d'interface utilisateur dans cette catégorie. En général, cela inclut toute personne impliquée dans la création de votre produit.
• SysAdmins ou l '«équipe des opérations». Ces personnes gèrent la mise à jour des serveurs avec un nouveau code, gèrent à la fois votre infrastructure de serveurs publics et internes, et tout en maintenant tout opérationnel.

Pour faire simple, DevOps consiste à intégrer ces deux équipes ensemble (d'où le portemanteau d'un nom). Cela ne fera pas de vos développeurs des administrateurs système, ou vice versa, mais cela devrait les aider à travailler ensemble.

Chaque aspect et phase est complété par des outils qui facilitent l'ensemble de ce processus. DevOps est plus que de simples outils et automatisation, et la mise en œuvre d'un ensemble d '«outils DevOps» ne fera pas automatiquement travailler votre équipe deux fois plus vite, mais ces outils sont une partie importante du processus, et il serait difficile de l'être aussi efficace sans certains d'entre eux.

Bien qu’il existe de nombreux autres mots à la mode sous l’égide de «DevOps», le concept de base est assez simple. Lorsqu'une équipe fonctionne correctement, DevOps se déroule généralement comme suit:

Pour expliquer, nous allons commencer par la phase de surveillance. Cela implique de garder un œil sur vos serveurs, de surveiller les analyses, d'analyser les journaux et d'identifier les problèmes avec votre base de code. Bien qu'une grande partie de cela soit liée au code, une grande partie relève également de l'aspect commercial. Atteignez-vous efficacement vos objectifs? Vos clients sont-ils satisfaits? Cette phase consiste à découvrir ce qui ne va pas afin que vous puissiez vous fixer des objectifs appropriés. Les outils de surveillance populaires incluent Nagios, AWS CloudWatchet des logiciels d'analyse comme Google Analytics.

Peut-être que vous obtenez un ticket directement d'un client et que vous commencez par la phase de planification. C'est ici que vous allez vous asseoir avec vos développeurs principaux et discuter de ce qui doit être fait pour terminer un ticket. Si vous utilisez un logiciel comme Jira, vous décomposerez probablement un gros ticket en histoires et problèmes individuels qui peuvent être suivis plus facilement et attribués à des développeurs individuels. Si vous planifiez un sprint de code pour la semaine ou les deux prochaines, vous souhaiterez que votre plan soit clairement défini pour réduire le temps passé à réitérer le code.

Plutôt que de tester et de construire une seule fois lorsque tout est terminé, dans un environnement DevOps, chaque développeur soumettra idéalement les modifications au contrôle de code source plusieurs fois par jour, chaque fois que les problèmes sont terminés ou qu'une étape mineure est atteinte. Cela permet aux phases de construction et de test de démarrer tôt et de s'assurer qu'aucun développeur ne s'éloigne trop de la tête du contrôle de source principal. Cette étape concerne principalement la gestion appropriée du contrôle des sources, il est donc essentiel de disposer d'un service git efficace comme GitHub, Gitlab ou BitBucket pour assurer le bon fonctionnement de l'intégration continue.

Vous n'êtes pas obligé de déployer tous les engagements en production immédiatement, mais les déploiements automatisés rapides sont un élément majeur pour pouvoir pousser des versions rapides. De plus, cela soulage votre équipe des opérations, ce qui lui permet de se concentrer sur des choses plus importantes que la mise à jour manuelle des serveurs avec un nouveau code.

Une fois les nouveaux changements déployés, le cycle recommence. Cette nouvelle fonctionnalité que vous avez ajoutée entraîne peut-être des heures supplémentaires sur le serveur de base de données intermédiaire et devra peut-être être marquée pour une évaluation des performances et corrigée avant le déploiement en production. Si tout se déroule correctement, DevOps cesse d'être une série d'étapes fixes et devient simplement une culture que tout le monde suit naturellement.

Intégration continue / Pipelines de livraison continue

L'automatisation et les outils sont une partie importante de tout environnement DevOps. Le plus gros outil à avoir est peut-être un pipeline d'intégration continue / livraison continue (CI / CD). Il s'agit d'un processus automatisé qui commence avec le code source et gère le processus de création, de test et de déploiement sur les serveurs.

CodePipeline d'AWS en est un bon exemple. Chaque fois qu'une modification est détectée dans le contrôle de code source (GitHub, BitBucket ou AWS CodeCommit), elle est envoyée à AWS CodeBuild pour création et test. Alternativement, Jenkins est utilisé assez souvent pour gérer cette phase de construction.

En règle générale, une fois la construction terminée, vous souhaiterez l’envoyer vers un environnement de test avant de passer directement à la production. Même encore, l'automatisation des déploiements sur les serveurs de test et de production accélérera considérablement les temps d'itération. Dans le pipeline d'AWS, cela est géré par CodeDeploy. Jenkins peut également gérer le déploiement, ainsi que des logiciels tels que Ansible.

Dans l'ensemble, un pipeline CI / CD peut automatiser la majeure partie du flux DevOps, de la construction au déploiement, ce qui en fait un élément crucial pour toute équipe qui cherche à travailler efficacement.