Comment mener une évaluation sans concession de votre entreprise avant de passer à DevOps

DevOps n'est pas simple : son implémentation et sa gestion ne vont pas toujours de soi. En évaluant DevOps, vous saurez si l'entreprise et son service IT sont prêts à franchir le pas.

La méthode DevOps de développement et de déploiement logiciel implique des temps de traitement courts qui permettent de saisir plus rapidement les opportunités qu'avec les approches classiques de développement logiciel. Des modifications simples et progressives permettent de tester de nouvelles idées et de prendre plus de risques, voire de se tromper, sans conséquences lourdes. C'est ce qui explique, notamment, son avantage sur le développement traditionnel « en cascade » (waterfall).

DevOps permet d'accélérer le développement logiciel et de rationaliser l'interaction entre les équipes chargées respectivement des opérations et de l'assurance qualité (QA). En contrepartie, les entreprises doivent être prêtes à répondre à certaines exigences.

Avant de franchir le pas, répondez à ces cinq questions pour évaluer DevOps de façon réaliste.

1. Quelle est la valeur ajoutée de DevOps pour l'entreprise ?

Pensez aux bénéfices à long terme pour le projet. Dans les cycles traditionnels de développement, plusieurs années de codage et de test sont nécessaires avant de distribuer une version finale. La somme de travail pour un produit est colossale, et les ventes ne sont pas garanties. Les bogues - les défauts et les oublis - dans la version ainsi que la concurrence entament potentiellement le retour sur investissement.

En allégeant et en raccourcissant les cycles de développement et de mise sur le marché (time-to-market), DevOps modifie les effets du développement logiciel sur l'entreprise. Les développeurs et les équipes chargées de l'assurance qualité et des opérations travaillent constamment sur des portions du pipeline de livraison continue du produit. Chaque version apporte au produit son lot de fonctions et de fonctionnalités importantes. La mise sur le marché plus rapide évite cette longue période d'investissement risquée.

2. L'IT est-il assez souple pour DevOps ?

Le service IT doit déployer toutes les petites versions logicielles qui s'enchaînent rapidement. Il doit installer la nouvelle version de l'application sur au moins un serveur du datacenter ou du Cloud et interconnecter les bases de données, le stockage, le suivi des performances et toutes les ressources nécessaires. Ces activités font partie des missions des administrateurs IT, mais, ici, le rythme des changements peut alourdir les processus opérationnels habituels.

Les processus traditionnellement cloisonnés qui permettent d'approvisionner et de déployer une application d'entreprise classique durent des mois. Le service IT détermine les besoins de l'application, spécifie les demandes et approuve les nouveaux serveurs et les équipements. Il achète le système d'exploitation et les licences logicielles, installe les nouveaux équipements et procède au déploiement de la version finale approuvée. Toutes ces tâches demandent peu d'interaction avec les développeurs, voire aucune.

Des processus aussi figés sont tout à fait adaptés pour les équipes IT qui sortent occasionnellement de nouvelles versions logicielles, mais ces stratégies d'implémentation se révèlent vite dépassées et inutiles lorsque l'équipe déploie une nouvelle version d'application tous les mois ou plusieurs fois par mois.

Passer à DevOps implique plus qu'un nouveau cycle de développement. Lorsque vous évaluez DevOps, imaginez comment l'équipe IT actuelle fonctionnerait en l'état et quels changements cela impliquerait. Dans un groupe DevOps, l'IT collabore et interagit autrement avec les développeurs et l'équipe de l'assurance qualité (QA) pour fournir les ressources de stockage, de calcul et de réseau bien plus rapidement de façon à tester chaque nouvelle version et à en assurer le support.

3. L'entreprise est-elle assez développée pour DevOps ?

DevOps fonctionne uniquement avec un pipeline cyclique de développement, de test et de déploiement alimenté par au moins un projet. Lorsque le pipeline n'est pas alimenté, l'équipe n'a rien à faire.

Le passage à DevOps exige une entreprise assez importante pour assumer la charge du personnel, des processus et des outils qui alimentent DevOps. Les petites entreprises - disons jusqu'à 250 personnes - dont le budget global est directement affecté par le coût des talents peuvent avoir du mal, au départ, à assurer l'équilibre entre le personnel et les demandes de projets.

Elles préfèrent souvent sous-traiter le développement des applications ou investir dans des progiciels, comme Salesforce, au lieu de développer elles-mêmes un outil de gestion de la relation client.

L'alimentation et la gestion d'un pipeline DevOps sont donc plutôt une affaire de grande entreprise, souvent mieux à même d'embaucher le personnel en nombre suffisant pour respecter les délais du projet. Les entreprises entre 250 et 1 000 personnes ont sans doute intérêt à intégrer un processus DevOps, alors que celles de plus de 1 000 personnes ont probablement l'envergure nécessaire pour adopter une stratégie DevOps et en tirer parti.

4. L'entreprise connaît-elle sa stratégie DevOps ?

DevOps n'est pas une initiative ou un événement isolé : il ne suffit pas d'utiliser un logiciel ou un plan tiré d'un livre pour y parvenir. DevOps implique des moyens humains, des outils et des processus.

Il exige des développeurs talentueux, des testeurs acharnés et des responsables de l'exploitation expérimentés. Il exige de l'automatisation, un flux de travail, de la collaboration et les outils associés. Il exige des processus métier dynamiques et souples pour briser les silos traditionnels et assurer la collaboration de plusieurs équipes.

Lorsque tous ces éléments sont réunis, DevOps accélère spectaculairement les cycles de développement et de déploiement logiciels et génère des bénéfices tangibles.

Chaque entreprise adopte DevOps à sa façon, en ajustant et en adaptant les moyens humains, les outils et les processus pour répondre à ses objectifs uniques. Pour cela, elle doit disposer de développeurs rompus aux cycles et aux flux de travail DevOps, organiser une équipe IT capable d'assumer des plannings de livraison dynamiques, implémenter un ensemble d'outils qui facilitent la collaboration entre les développeurs, les équipes QA et IT, et appliquer une gouvernance clairement orientée vers l'adoption de DevOps.

La plupart des entreprises ayant récemment adopté DevOps ne se sont pas jetées dans l'aventure à corps perdu. Elles évaluent le potentiel de DevOps et l'adoptent progressivement. Elles enrichissent leur expertise en formant des groupes qui travaillent sur des projets de petite envergure, puis, au fil du temps, valorisent systématiquement les connaissances acquises et les outils sur des projets plus sensibles.

5. L'entreprise peut-elle s'engager dans la voie du changement permanent ?

Mettre en œuvre une stratégie DevOps demande un effort sur le long terme : les entreprises doivent en permanence ajuster leurs stratégies pour répondre aux changements de l'activité, aux évolutions technologiques et aux différentes demandes des utilisateurs.

Après le premier pas vers DevOps, l'entreprise devra faire face à un nouveau type de développement, migrer vers un autre flux de travail DevOps et une nouvelle plateforme de collaboration, mettre à jour les serveurs, implémenter un Cloud privé ou migrer vers un Cloud public, adopter une plus grande diversité d'outils clients - comme les logiciels pour tablettes et smartphones - et s'adapter au changement d'environnement et de priorités.

Optimiser et ajuster la méthode et les outils DevOps est une responsabilité de longue haleine.