Lors de la réalisation d’un projet, vous rencontrez probablement de nombreux problèmes : dette technique, mise en production houleuse, etc. Alors, se former au DevOps, recruter un DevOps ou partager cette philosophie peut être une très bonne idée.

Qu’est-ce que le DevOps ?

Qui sont les développeurs

Bon, pas de surprise, ce sont les personnes qui écrivent du code et développent les nouvelles fonctionnalités ou corrigent les bugs.

Qui sont les ops (opérationnels)

Chaque entreprise définit les opérations à sa manière mais ce sont généralement les personnes qui s’occupent du SI (système d’information), les sys. admin comme on les appelle couramment.

Avantages du DevOps

• accélération du déploiement des projets (déploiement d’un site, d’une application, etc.)
• réduction du temps nécessaire pour la mise sur le marché (Time-to-Market)
• fiabilisation

Bien sûr, dernier avantage logique par rapport aux avantages précédents : économie d’argent.

Désavantages du DevOps

Je n’en ai pas trouvé pour l’instant à part la difficulté à convaincre les équipes ou sa hiérarchie ce qui n’est pas à proprement parler un désavantage de cette philosophie.

Fondamentaux de la philosophie DevOps

La philosophie DevOps se résume avec le sigle CALMS, qui représente ses cinq piliers. CALMS signifie : Culture, Automation (automatisation), Lean, Measurement, Sharing (partage).

Culture

Pour que la philosophie soit adoptée, il faut mettre en place une culture. Pour ce faire, il faut que les développeurs et les opérationnels aient une vision commune et donc avoir les mêmes objectifs. L’idée est d’éviter qu’une équipe rejette la faute sur l’autre, les responsabilités doivent être communes. Ils doivent travailler ensemble et développer des valeurs communes. Le mieux est que cela fasse partie de la culture d’entreprise.

Automation / Automatisation

Toutes les tâches répétitives et où l’humain n’a pas une forte valeur ajoutée devraient être automatisées pour bénéficier de nombreux avantages.

Vous pourrez fiabiliser et accélérer les déploiements, grâce aux tests automatiques par exemple. Si votre projet le permet vous devriez faire des tests unitaires (fonction par fonction), des tests d’intégration (on vérifie comment s’intègre la fonction) et des tests de bout en bout (comme un utilisateur).

C’est donc terminé l’époque du « il faut être fou pour faire une mise en production un vendredi ». Vous serez bien plus confiant.

Lean (maigre)

L’idée est simple : faire les choses simplement, il faut se concentrer sur ce qui a de la valeur. Cela évite d’ajouter de la complexité cyclomatique par exemple. On limite le gaspillage, pas besoin de surdimensionner l’environnement de test, surtout si vous payez à la consommation.

Measurement / Mesure

Vous avez tous entendu au moins une fois dans votre vie cette phrase :

« On améliore que ce que l’on mesure. »

Une méthode de mesure peut être d’utiliser les KPI (Key Performance Indicator ou Indicateur de Performance Clé). Faire un état des lieux est important, ne serait-ce que pour savoir ensuite si vous progressez ou régressez.

En informatique on aime bien mesurer la latence d’un site, sa durée de chargement, la saturation mais aussi l’utilisation CPU d’un serveur, sa RAM, les performances de la base de données, etc.

Sharing / Partage

Pour fédérer les développeurs et les opérationnels, ils doivent partager des moments communs. Comme dit précédemment, ils doivent partager les responsabilités. Les deux équipes, lorsqu’elles collaboreront étroitement, travailleront plus simplement et cela favorisera l’innovation.

On peut partager une multitude de choses, les connaissances, les succès ou conseils d’une équipe mais aussi les échecs. Si avouer ou parler de ces échecs vous semble difficile dans l’entreprise par laquelle vous travaillez, alors il faudrait revoir la culture d’entreprise de celle-ci.

Rappel : toutes les équipes et toutes les entreprises ont des besoins différents, ces quelques exemples sont là pour vous inspirer mais ne sont pas des règles.

DevOps & CI/CD

Le terme CI/CD signifie Continuous Integration ou Intégration Continue en français et Continuous Deployment (certains disent Delivery) ou Déploiement Continu en français.

Ces deux étapes se déroulent dans un pipeline, c’est pour ça que vous entendrez parfois : pipeline CI/CD.

Le but lors de ces deux étapes et d’effectuer le build du projet, d’effectuer les tests, l’analyse de code par exemple (il y a de nombreux services open source ou payants qui proposent ça) puis le déploiement. Comme toutes les actions sont inscrites dans le pipeline, la marge d’erreur est très faible. Si le pipeline n’aboutit pas, le développeur peut être informé et savoir à quelle étape la chaine de CI/CD a échouée.

DevOps : les erreurs courantes

Mettre en place une philosophie DevOps est toujours une bonne idée à condition que cela soit bien fait, voici une liste non exhaustive de situations où l’un des 5 piliers n’est pas respecté :

• développer de nombreuses fonctionnalités en augmentant la dette technique (mauvaise qualité de code par exemple)
• livrer cette dette technique, surtout si c’est délibéré
• avoir un code ou un CI/CD qui bug constamment, qui ralentit les développeurs
• avoir un déploiement lent.

Conclusion

Le DevOps permet d’améliorer la cohésion au sein des équipes et entre les différentes équipes. De déployer plus de livrable et cela plus sereinement ! Voici un image qui résume simplement l’idée :