Imaginons une situation réelle, c’est le premier jour des soldes et vous naviguez sur le site de votre marque préférée. Vous repérez le t-shirt que vous convoitez depuis plusieurs mois. Ni une ni deux vous le placez dans votre panier et là, c’est le drame… le site ne répond plus. Quelques heures plus tard, vous retournez sur le site mais le t-shirt n’est plus disponible dans votre taille. Si l’équipe de développeurs et l’équipe opérationnelle avaient mieux communiqué, ce problème ne serait pas survenu.
Le DevOps ça vient d’où ? C’est la contraction de Développeur (Dev) et d'Opérationnel (Ops). Ce terme est apparu en 2008 lors de la conférence de Shafter et s’est largement diffusé en 2013 grâce au livre “The Phoenix project”. Historiquement les équipes de développeurs et les équipes opérationnelles ont des objectifs antagonistes, on parle du “wall of confusion”. Les Devs doivent produire de nouvelles fonctionnalités et les Ops s’assurent de la fiabilité du site ou de l’application.
Quand l'approche DevOps est mise en place, elle consiste à faire communiquer et collaborer les développeurs et les ops sur vos projets pour :
L’intégration continue est une manière de réduire les risques et de lancer des nouvelles features plus rapidement. C’est un bon moyen de rendre les Devs et le Ops complémentaires, pour ainsi casser les silos entre eux.
L’intégration continue est un ensemble de pratiques qui consistent à tester automatiquement chaque modification du code avant la mise en production. Autrement dit, lorsqu’un développeur révise son code, il est testé de manière automatique. Si une erreur est détectée, il est notifié et s’il n’y a pas d’erreur, le code est mis en production automatiquement. L’étape de la mise en production automatique est couramment appelée le déploiement continu.
Le déploiement continu ne doit pas être confondu avec la livraison continue qui a aussi pour objectif de déployer une app en production. Mais celle-ci, contrairement au premier, s'arrête avant la mise en production, qui reste une action manuelle.
Fun fact : le nom de Padok fait un parallèle avec le paddock de formule 1 qui permet aux pilotes de se concentrer sur leur conduite sans penser à l’état du véhicule.
Le but de l’intégration continue est simple : garantir un code de qualité rapidement. Les équipes de développement ont un retour immédiat, plus besoin d’attendre plusieurs semaines pour identifier les erreurs et les corriger. Ce qui impacte positivement la satisfaction des utilisateurs finaux, qui voient de nouvelles features sortir régulièrement, tout en conservant la même fluidité de navigation.
Comme vu précédemment, la culture DevOps repose sur l’idée de casser les silos entre les Devs et les Ops. Il n’est donc plus question de chercher un coupable, de se renvoyer la faute, et de mettre 24h à réparer un bug qui pourrait l’être en 10 minutes.
Laisser les ops sur le banc de touche n’est pas envisageable dans la méthodologie DevOps car la communication est le nerf de la guerre. Pour aligner les Devs et les Ops il faut communiquer et cela passe par cinq actions :
On entend de plus en plus parler de la méthodologie Agile. Mais la méthodologie agile est-elle compatible avec la culture DevOps ?
Le principal levier de la méthodologie agile est de raccourcir la durée des cycles de développement et donc la fréquence entre les différentes mises en production.
À ce stade, les deux méthodologies semblent se rejoindre puisqu’elles ont un but commun. Pourtant il y a bien une divergence. La méthodologie agile est par définition agile, flexible. Elle permet d’adapter les priorités des développements à des imprévus ou des changements de direction. Or, dans la méthodologie DevOps les imprévus ne sont pas faciles à faire rentrer dans le schéma traditionnel de priorisation des tâches.
Alors comment adapter la méthodologie Agile au DevOps ? La réponse est simple : il suffit de bien prendre en compte les problématiques liées aux métiers de Dev et d’Ops. Cela passe par trois actions :
Pour aligner vos Devs et vos Ops et adapter la méthodologie agile, la communication est primordiale, mais vous aurez aussi besoin d’outils pour tout mettre en place.
Le DevOps est donc une culture de collaboration entre les équipes de développement et les opérationnels et d’automatisation des processus entre elles. Pour collaborer et automatiser vous allez avoir besoin d’outils et il en existe un très grand nombre. Padok vous donne sa sélection pour vous aider à y voir plus clair. Si vous souhaitez avoir une liste d’outils DevOps plus complète consultez cet article.
Les outils de gestion de code source font partie des fondamentaux du développement mais il est important de les étendre et de les partager avec les opérationnels pour une meilleure communication. Cela permet de connaître les différentes modifications du code et les auteurs de celles-ci. Git et Github permettent notamment de créer un historique pour les fichiers code source.
Il vous faudra ensuite un outil de tests d’intégration continue et de déploiement continu (CI/CD). Comme expliqué plus haut, ces outils automatisent les tests des révisions du code source et lancent automatiquement le déploiement d’environnement de tests, voire de production. Chez Padok, nous utilisons GitlabCI mais il en existe un grand nombre, comme par exemple Jenkins (open source), Google, AWS, etc.
Pour éviter les mauvaises surprises au moment de la mise en production, nous vous conseillons d’utiliser des conteneurs. Vous pourrez isoler une application avec l’ensemble des éléments dont elle a besoin pour fonctionner. Les deux principaux outils sont Docker et RKT. Afin de simplifier le déploiement et la gestion des conteneurs nous vous conseillons d’utiliser un orchestrateur de conteneurs tel que Kubernetes.
Pour monitorer les clusters Kubernetes, Prometheus (outil open source) et Grafana sont efficaces. Et pour les analyses de logs et d’agrégation, la suite ELK (Elasticsearch, Logstash et Kibana) est répandue.
La communication étant le nerf de la guerre, il vous faut impérativement un outil de gestion de projet soit de type agile comme Jira ou soit généraliste tel que Trello.
Il n’existe pas d’outils parfaits en DevOps, tout dépend de vos projets. Le mieux est de les tester pour voir s’ils répondent à vos besoins. D’autant plus que tous les outils cités plus haut sont facilement disponibles et intégrables dans le cloud à des fins de tests et de production.
On entend de plus en plus parler de Cloud mais qu’est-ce que ça change pour le DevOps et qui sont les Cloud providers du marché ? Les Cloud providers sont des solutions d’hébergement distant, c’est-à-dire que les données et les outils sont stockés dans des data centers en dehors de l’entreprise.
Le Cloud et le DevOps sont indépendants mais sont des stratégies complémentaires car pour rester compétitif sur le marché, les entreprises doivent revoir leur approche du travail. Les cycles de production doivent être réduits pour apporter des améliorations constantes auprès des utilisateurs finaux. Le Cloud répond directement à ce besoin d’agilité. Pour imager tout cela, si le cloud est un instrument, le DevOps est le musicien qui en joue. Comme pour le paddock de formule 1, l’Ops peut se concentrer sur la mise en production des nouvelles fonctionnalités au lieu de penser à la coupure de serveurs physiques. En effet, les problématiques de load balancing et de redondance par exemple, sont nativement prises en compte dans ce contexte.
Il existe trois principaux Cloud providers sur le marché :Google Cloud Platform (GCP), Azure et AWS. Ils proposent tous les outils mentionnés précédemment et bien d’autres.
Vous avez maintenant toutes les clés pour comprendre ce qu’est le DevOps, comment l’appliquer, quels outils utiliser. Vous avez ainsi couvert toutes les bases du DevOps, vous êtes prêts pour faire changer votre organisation. N’hésitez pas à nous contacter si vous avez des questions, nos équipes DevOps sont présentes pour vous accompagner.