Actuellement, lorsque l’on entend parler des logiciels, il est désormais acquis que :

1. Ils apportent une valeur réelle aux entreprises, qu’elles que soit leur taille, leur permettant de transformer leurs processus et de créer de tout nouveaux business models reposant sur les applications.

2. Les organisations informatiques s’engagent à fournir des solutions pour les logiciels en suivant les tendances et pratiques actuelles, telles que l’intégration continue, le déploiement continu et le DevOps.

Bien des organisations pensent suivre ces pratiques d’intégration et de développement continu au mieux. Après une vérification plus approfondie, il s’avère que ce n’est pas toujours le cas.

Et qu’en est-il du DevOps ? Les organisations respectent-elles réellement les pratiques du DevOps correctement ? Si elles appliquent correctement l’intégration continue et/ou le déploiement continu, peuvent-elles encore ne pas être en adéquation parfaite avec le DevOps ? Une fois de plus, les entreprises doivent se poser ces questions afin de s’organiser et d’optimiser leurs performances dans une économie qui repose de plus en plus sur l’innovation des logiciels.

De manière générale, lorsqu’il est appliqué dans les règles de l’art, le DevOps peut être un réel catalyseur pour une organisation. A l’inverse, si les principes ne sont pas correctement respectés, le DevOps peut s’avérer contre-productif et affecter l’organisation de bien des manières. Voyons à présent ce qui se cache derrière le terme DevOps et quelles sont les règles majeures de ce concept.

Qu’est-ce que le DevOps ?

Selon moi le DevOps, l’intégration continue et le déploiement continu se rapportent tous à la même famille de mouvements agiles et lean dont l’objectif est la rationalisation des processus. Il existe toutefois des différences. L’intégration continue se concentre sur les processus tels que les builds automatiques et les modifications rapides sur la partie en amont du processus de déploiement. Le déploiement continu porte quant à lui sur les meilleures pratiques pour passer du pipeline à la production. Le DevOps se concentre sur les modifications organisationnelles nécessaires pour prendre en charge la collaboration entre les fonctions. Mais elles sont toutes liées les unes aux autres.

À plus haut niveau, le terme DevOps est culturel. Vous faites réellement du DevOps lorsque vous créez une culture de développement de logiciels prise en charge par les pratiques techniques. Au sein d’une culture DevOps, la compréhension des parties prenantes de développement logiciel est telle qu’elles partagent des objectifs communs pour le développement de logiciels de qualité rapidement et régulièrement.

Pouvez-vous appliquer correctement l’intégration continue et/ou le déploiement continu et ne pas suivre les principes de DevOps ? Tout à fait. L’intégration et le déploiement continus sont des pratiques que vous pouvez mettre en œuvre, voire maîtriser, et ce, sans pour autant avoir un impact sur le changement culturel nécessaire pour devenir une organisation de DevOps.

D’autre part, vous ne pouvez pas appliquer correctement le DevOps sans incorporer les composants fondamentaux des pratiques reconnues d’intégration et de déploiement continus. Comme le dit Jez Humble, vous pouvez mettre en œuvre des processus de DevOps à l’aide d’un script Bash. Le DevOps ne prescrit pas nécessairement de pratiques de composant. Cela dit, la mise en œuvre du DevOps de manière durable, régulière et évolutive requiert des engagements en matière d’intégration et de déploiement continus.

Appliquer les principes du DevOps

Au cours des dernières années, bien des personnes ont essayé d’identifier les signes permettant de savoir si une organisation pratique correctement le DevOps. Certaines des caractéristiques les plus communes attribuées aux organisations de DevOps efficaces sont les suivantes : elles définissent clairement des stratégies de DevOps et elles peuvent mettre en place des mesures dites de « bon sens » pour identifier les éléments prenant une mauvaise tournure. Certains des indicateurs clés révélant des initiatives de DevOps incorrectes incluent l’intolérance face à l’échec et la tentative d’effectuer des processus de test bien après la mise en œuvre.

Je résumerais l’évaluation aux six recommandations suivantes, visant toutes à atteindre une culture de DevOps :

1)    Définissez un processus complet, de A à Z

Les cultures de DevOps prospères se concentrent sur l’entreprise, les développeurs, les testeurs et les équipes d’opérations informatiques qui travaillent ensemble dans le but d’atteindre leurs objectifs communs. Ils partagent des informations sur des éléments tels que la façon de démarrer un processus, de construire un pipeline efficace, de mettre en œuvre un processus de déploiement et de mesurer les résultats.

2)    D’abord, appliquez un DevOps prospère au sein d’une équipe

Avant de vouloir appliquer un DevOps à l’ensemble de votre organisation, veillez à ce qu’il fonctionne à petite échelle, en vous assurant que son adoption va de bas en haut et que les cadres importants adhèrent à son implémentation. Lors de la mise en place, l’adhésion de la gestion peut être difficile et interminable, mais elle sera nécessaire pour que la transformation soit prospère au niveau de l’organisation. Elle aura un impact sur les calendriers, les budgets et l’organisation.

3)    Assurez-vous que votre organisation ne comporte pas de silos

Toutes les organisations ne peuvent pas éliminer les silos organisationnels. En engageant et en alignant l’ensemble des parties prenantes dans le processus de déploiement, au sein des services, vous pouvez créer virtuellement (ou réellement) des équipes produit, réduisant l’impact des silos organisationnels. Cela permettra de créer une meilleure compréhension des challenges entre les différentes équipes de l’organisation et de stimuler une culture de collaboration et de retours constructifs.

4)    Veillez à être entouré des bonnes personnes

Si vous essayez de créer une stratégie de DevOps dans laquelle chaque personne de l’organisation apporte sa contribution, vous risquez de faire face à une complexité sans fin (paralysie d’analyse) et de ne jamais vraiment commencer. Pour que votre transformation démarre rapidement, il est recommandé d’en réduire l’étendue. Concentrez l’initiative initiale sur quelques projets seulement. Si ces projets réussissent, vous pourrez progressivement étendre votre stratégie de DevOps sur les équipes, tout en incorpoant de nouveaux éléments.  Je vous recommande de commencer par rassembler les représentants, tels qu’un cadre et un contributeur individuel de chaque processus et de chaque groupe : un représentant de l’entreprise, un administrateur en gestion de projets, un développeur principal d’une équipe de développement et un développeur. Les contributeurs individuels sont essentiels puisqu’ils sont les seuls à pouvoir vraiment identifier les épreuves de l’expérience et ce qui doit être amélioré. Cela crée également l’empathie et l’adhésion nécessaires.

5)    N’essayez pas « d’acheter du DevOps »

Certaines organisations pensent qu’elles peuvent acheter un ensemble d’outils qui les feront devenir des organisations de DevOps. Ne vous faites pas avoir. Les outils sont un élément essentiel pour relier les équipes dans des silos et permettre l’automatisation qui prend en charge le DevOps. Mais ces outils seuls ne résoudront pas vos problèmes. Il est de votre ressort d’effectuer le gros du travail en créant et en analysant tous les aspects importants de l’intégration et du déploiement continu pour garantir que les outils effectuent leur travail.

6)    Veillez à bien mesurer vos progrès

Une culture de DevOps efficace inclut un engagement en matière de mesure des résultats et de rapport sur les indicateurs quantifiables. Pour construire votre pipeline de déploiement, vous devez intégrer la possibilité de réaliser ces tâches et suivre de manière continue vos progrès par rapport à ces objectifs.

Par exemple, des processus de déploiement de logiciels non optimaux ont tendance à occasionner des heures supplémentaires considérables. Les ingénieurs d’opérations et autres membres de l’équipe ont tendance à travailler de longues heures pour déployer des logiciels. Compter les heures des équipes dans l’objectif de réduire les heures supplémentaires de 50 à 70 % inculquera un niveau de discipline nécessaire et permettra de promouvoir une culture de l’excellence.

Les inconvénients d’un mauvais DevOps

Appliquer un mauvais DevOps n’est pas sans conséquence. Avant tout, vous allez passer à côté de certaines opportunités. Le marché actuel avance vite, et chaque entreprise fait face à des concurrents qui mettent en œuvre le DevOps correctement. Ces entreprises sont en pleine innovation et s’imposent sur le marché. Si vous passez du temps sur une initiative de DevOps qui a échoué ou qui a été mal mise à profit, un coût considérable de renoncement en découlera.

Vous devrez également gérer des coûts internes. Si une initiative de DevOps échoue, le moral de vos équipes en prendra un coup et les informaticiens expérimentés risquent d’avoir du mal à obtenir l’adhésion nécessaire pour une autre transformation de DevOps.

Il y a ensuite les coûts réels. Investir dans un projet de DevOps qui présente des failles est une perte d’argent, de temps et de ressources humaines, qui auraient pu être mis à profit sur un autre projet.

Les avantages d’un bon DevOps

Par ailleurs, des initiatives de DevOps fructueuses peuvent générer une forte valeur ajoutée :

– Des employés plus épanouis : créer une organisation de DevOps engagée et efficace peut permettre aux entreprises de conserver leurs meilleurs talents et d’en recruter de nouveaux.
– Une productivité accrue : passer moins de temps sur le cycle de vie de développement d’un logiciel se traduit par une meilleure valeur ajoutée en matière de flux de logiciels.
– De la vitesse : la capacité à innover plus rapidement tout en conservant une qualité élevée permet à l’entreprise de bénéficier d’un avantage concurrentiel non négligeable sur le marché.

Conclusion

Pour mettre en place le DevOps correctement, une organisation doit créer des liens entre les personnes, les outils et les objectifs de l’organisation. Ce n’est pas une mince affaire. Vous ne pourrez pas le mettre en place rapidement. Cependant, c’est tout à fait réalisable si les organisations s’engagent à créer une véritable culture de DevOps. Il ne vous suffit pas de vous réveiller un matin et de vous dire, « Aujourd’hui, je me mets au DevOps ». Utilisez les concepts d’intégration et de déploiement continus en tant que composants initiaux et ralliez le reste de votre organisation à votre vision. Déterminez votre positionnement aujourd’hui, la direction que vous souhaitez prendre et le chemin pour vous y rendre. C’est à partir de là que vous pourrez commencer à avancer.

___________
Brian Dawson est DevOps Evangelist CloudBees