Comment réussir les DevOps

Les approches DevOps remontent à la fin des années 1990, elles ne sont donc pas nouvelles en principe. Pourtant, de nombreux projets n'aboutissent toujours pas au résultat escompté. Consol montre, sur la base de ses propres expériences tirées de nombreux projets clients DevOps, quels sont les cinq points à respecter dans tous les cas.

1. aborder activement le changement culturel

Il est clair qu'il existe tout d'abord un conflit d'intérêts entre le développement et l'exploitation. Si pour le développeur, la créativité et la flexibilité sont importantes, pour l'exploitation informatique, ce sont surtout les critères de stabilité et de disponibilité qui comptent.

Si, dans le cadre d'une stratégie DevOps, les développeurs et les responsables de l'exploitation informatique travaillent désormais ensemble en équipes pour concevoir, développer, tester et exploiter des applications, cela nécessite non seulement des changements organisationnels, mais aussi un changement de culture.

Cela signifie aussi, par exemple, que les membres de l'équipe doivent se familiariser avec les exigences et les processus respectifs tant du développement que de l'exploitation.

Le thème du changement de la culture d'entreprise doit être abordé activement avec la participation de la direction lors du lancement du projet DevOps, afin d'exclure de manière fiable les futures frictions au sein des équipes interdisciplinaires.

2. prendre en compte le volume d'investissement

Il est clair que les projets DevOps menés à bien apportent de nombreux avantages à moyen et long terme : d'une qualité et d'une flexibilité accrues à des cycles de release de logiciels plus rapides, en passant par des économies de coûts.

Toutefois, cet objectif ne peut être atteint que si les investissements initiaux nécessaires sont réalisés. Ce n'est souvent pas le cas. Chaque entreprise doit être consciente que l'introduction de DevOps est toujours liée dans un premier temps à une augmentation des coûts dans le domaine informatique.

La direction de l'entreprise doit donc être impliquée dès le début dans les projets DevOps et soutenir durablement toutes les décisions d'investissement nécessaires.

3. utiliser l'environnement de simulation

Les processus de développement et de production diffèrent considérablement. Par exemple, les applications dans la production sont toujours intégrées dans un environnement système plus large.

En revanche, le développeur travaille souvent de manière totalement autonome sur un logiciel sur son ordinateur de bureau ou portable, sans que celui-ci ne dispose par exemple de la connexion nécessaire à un système SAP.

Dans ce cas, fournir au développeur une licence SAP monoposte n'est généralement pas une solution viable, ne serait-ce que pour des raisons de coûts.

L'alternative est d'utiliser un environnement de simulation. Or, de nombreuses entreprises s'en abstiennent encore, bien que cela n'implique pas nécessairement des coûts élevés.

Il existe également des produits open source bon marché comme Citrus de Consol (www.citrusframework.org), un framework indépendant de la plateforme, qui peut être utilisé de manière flexible pour les technologies et les protocoles les plus divers.

4. éliminer les étapes manuelles du processus

Pour pouvoir profiter pleinement des avantages de DevOps, il faut bien sûr que tous les processus soient automatisés dans la mesure du possible. Or, les activités manuelles sont encore souvent à l'ordre du jour, surtout dans le domaine du testing.

Il n'est donc pas rare que les départements spécialisés vérifient manuellement l'intégrité fonctionnelle d'une application, ce qui demande beaucoup de travail. Mais cela va à l'encontre de l'approche DevOps, qui doit contribuer à une mise à disposition plus rapide des logiciels.

Certaines entreprises restent fidèles à l'approche manuelle, car de nombreux outils de test sont liés à des coûts non négligeables. Il existe en effet des solutions open source qui offrent des fonctionnalités de test complètes : tests fonctionnels, tests de charge, tests de performance et tests de bout en bout.

5. réduire les ruptures de système

Même dans les structures DevOps, les environnements de développement, d'intégration et de production sont souvent considérés de manière isolée. Des outils spécifiques sont utilisés dans chaque domaine, mais ils ne sont pas reliés entre eux en tant que solutions isolées.

Cela ne correspond pas non plus au concept intégratif de DevOps. L'objectif doit être d'assurer une mise en réseau centrale. Là encore, de nombreuses entreprises - souvent par ignorance - ne voient aucune possibilité.

Il suffit de penser aux outils dans l'environnement d'OpenShift ou d'Ansible.