Conclusion du cours sur le DevOps

Pour la fin de ce cours nous répondons à notre problématique "Est-il pertinent d’adopter le DevOps pour tout projet applicatif ?"

Introduction

Aprés autant d'articles rédigés pour mieux comprendre le mouvement, l'histoire, la philosophie, méthodologie, les bonnes pratiques, les outils etc ... du DevOps avec des données et des faits concrets. Il est tant alors de répondre à notre problématique de départ "Est-il pertinent d’adopter le DevOps pour tout projet applicatif ?".

Est-il pertinent d’adopter le DevOps ?

La taille de l'entreprise

Pour répondre à cette question, on peut avant tout se fier au rapport de DORA résumé dans les chapitres précédent.

En effet, Les entreprises interrogées dans ce rapport qui disent adopter une approche DevOps sont de tailles et secteurs différents. On retrouve par exemple des TPE avec des effectifs compris entre 1 à 4, des PME avec des effectifs compris entre 20 à 99 salariés, etc. Cela démontre clairement qu’ une approche DevOps peut être accessible et applicable peu importe la structure et taille de l’entreprise.

Prenons par exemple le cas d’une Start-up qui embauche uniquement un seul développeur full stack pour tout son service IT. Ce développeur s’occupera donc à la fois du développement et de l’environnement de production. Il peut très bien appliquer et adapter les bonnes pratiques DevOps à ces tâches quotidiennes. Comment ? Il peut tirer parti des outils de contrôle de version pour tracer ces modifications, intégrer des tests, intégration et déploiement continue afin d’éliminer ses tâches manuelles et fastidieuses dans ses processus de publication de logiciels. Ainsi, il évitera les erreurs humaines et disposera de moins d'échecs de déploiement.

D'ailleurs pour ce type de cas, je peux me prendre moi-même comme exemple, car sur ce blog que je maintiens seul, j’utilise toutes les bonnes pratiques citées plus haut pour envoyer du code plus rapidement, fréquemment et stablement depuis mon ordinateur personnel jusqu’à mon serveur de production.

Fréquence des mises à jour

On peut également légitimement se demander, si pour une organisation qui fonctionne avec un modèle commercial ne nécessitant pas de mises à jour logicielles fréquentes pour répondre à la demande des clients, s'il est réellement nécessaire pour elle d’implémenter une démarche DevOps ?

La réponse est oui car le problème avec ce type d'organisation, c'est que le jour où elle publiera sa mise à jour logiciel, son processus peut être très coûteux et douloureux. Cette publication peut même nécessiter des semaines de mobilisation. À cela s'ajoutent les modifications d'infrastructure et les changements d'effectifs pouvant survenir entre temps en plus des complications non négligeables en cours d'opération. De ce fait, l'automatisation pourrait aider l'organisation à livrer plus sereinement leurs futures versions.

Ma réponse

Ainsi, pour répondre à la problématique de départ, à mon sens il est pertinent d’implémenter une démarche DevOps, même s’il est parfois très difficile d’implémenter toutes les bonnes pratiques du DevOps. Nous pouvons citer ici par exemple le cas du passage à des architectures microservices alors que les applications ont été conçues depuis des années avec des architectures monolithes. On peut néanmoins adopter les autres bonnes pratiques comme l’implémentation des tests unitaires dans un système d’intégration continue afin que les équipes puissent intégrer leur modification plus paisiblement pour ce type d’architecture monolithe et leur dégager plus de temps pour leurs tâches supplémentaires.

Préparation aux changements

Avant d’achever ce document, j’aimerais toutefois préciser que pour les entreprises disposant de plus de moyens avec des équipes de développement et d’exploitation distincts, si elles ne se préparent pas correctement au changement de culture de ses équipes, elles risquent malheureusement de créer une confusion lorsque l’objectif de telle philosophie n'est pas clairement défini.

En effet, il est vrai que les outils peuvent encourager l’adoption d’une démarche DevOps dans une organisation, mais le modèle ne garantit pas à lui seul le succès de l’entreprise. La gestion du changement est difficile et la peur de l'inconnu peut empêcher tout une équipe de développer leurs compétences. Dire verbalement que « nous faisons du DevOps » et rapprocher les bureaux des équipes, ne va pas implémenter comme par magie un processus réussi. Beaucoup seront confus et les membres de longue date de l'équipe se sentiront mécontents.

Pour éviter cette confusion, il faut prévoir une période de transition. En effet, les entreprises doivent laisser suffisamment de temps à leurs équipes pour s’habituer à ces nouvelles pratiques et de définir une responsabilité et une stratégie d’un objectif global et il faut s’assurer qu'ils ont la possibilité d'acquérir une expérience pratique des nouveaux processus et outils.

La communication honnête, respectueuse et ouverte des attentes entre les équipes est cruciale et le DevOps représente un mouvement culturel tout autant qu'une méthodologie de processus et d’outillages, et les équipes doivent avant tout posséder un état d'esprit collaboratif.

Conclusion

Je remercie particulièrement les courageux qui ont tenu jusqu'à la fin sur ce cours complet pour mieux comprendre le mouvement DevOps. J'espère que vous êtes maintenant en mesure non seulement de voir à quoi sert la philosophie DevOps, mais que vous pouvez également utiliser ces connaissances pour implémenter cette approche dans votre propre entreprise.

Espace commentaire

Écrire un commentaires

vous devez être connecté pour poster un message !

0 commentaire

D'autres articles

Rejoindre la communauté

Recevoir les derniers articles gratuitement en créant un compte !

S'inscrire