DevOps : les résultats de notre enquête

Zenika a lancé en avril dernier un sondage sur le DevOps, afin de prendre la tendance de son positionnement dans les entreprises.
Nous vous partageons notre synthèse.

DevOps et nos participants

Avec 95% des répondants sensibilisés ou pratiquant le DevOps dans leur entreprise, les sondés sont une population d’initiés.
Pour autant, 50% de cette population n’en parle pas vraiment sur leur lieu de travail, ce qui montre que le DevOps est, encore une culture inconnue pour un grand nombre d’entreprises. Nos participants pensent majoritairement que le DevOps est un changement de culture, une modification des processus qui passe par la communication mais aussi par de l’outillage.
Le DevOps, selon 65 % des sondés, permet principalement de diminuer le “time to release” (temps entre l’expression d’un besoin et sa livraison aux opérationnels), d’augmenter la qualité des applications mais surtout pour 85% d’entre eux de favoriser la communication et la collaboration inter silos.

Les projets de nos participants

Alors que 80% des participants ont mis en place un build automatisé avec, pour 70% d’entre eux, des tests automatisés, seulement 50% ont une livraison automatisée. Les parties prenantes qui prennent part au processus de livraison sont, pour toute les entreprises, les développeurs, mais aussi à 61% les chefs de projets (en particulier pour les petites équipes) et à 40% les exploitants et les équipes chargés des tests.
On perçoit ici, véritablement, la difficulté des entreprises d’impliquer toute les parties prenantes d’un projet, lors d’une livraison.
La fréquence des déploiements :

• 40% des sondés déploient des applications à raison de une fois par mois
• 30% déploient une fois par semaine
• 60% estiment pouvoir déployer plus régulièrement.

Il est intéressant de voir que 60% des sondés estiment que le “time to market” d’une idée et pratiquement toujours à plus de 3 mois.
Quand on s’intéresse d’un peu plus près aux déploiements, on s’aperçoit que 70% de ceux-ci prennent plus de deux heures et que, pour 60% d’entre eux, le taux d’échec relatif à ces déploiements est très faible.
Néanmoins 60% des répondants estiment que les échecs s’expliquent principalement par le manque de qualité logicielle ainsi que par les erreurs humaines.
Seulement 55% des entreprises utilisent un outil de plannings collaboratifs de type JIRA, Trello, ou Redmine, et 66% utilisent le mail avec pièce jointe.
Toutefois et ceci est plutôt rassurant : 50% des participants travaillent dans des open-spaces ce qui favorise les échanges oraux.
Bien que, 50% des sondés pensent disposer d’un processus de livraison automatisé, seulement 10% estiment avoir une automatisation complète ne demandant quasiment aucune actions manuelles répétitives.

Les outils utilisés

10% des répondants n’utilisent pas d’outil de gestion de version.
Pour les autres, les deux outils utilisés sont, sans surprise, Git et Svn. Sans conteste (et sans surprise encore) Maven est utilisé par 80% des “java-iste” comme outil de build et pour 90% d’entre eux comme un outil de packaging. Les autres outils de build utilisés sont Gradle et ant, respectivement 5% et 15%.
Les archives simples et les formats Java standards de packaging type jar, war, ear sont préférés unanimement pour les projet Java.
Le sondage montre que 80% des répondants utilisent le serveur d’intégration continue Jenkins.
La gestion du changement n’est outillé que pour 50% des sondés qui utilisent Jira (80%) et Mantis (20%). Le seul outil de release manager, est un plugin, le Maven Release Plugin, utilisé par presque 35% des sondés.
Aucun de nos sondés n’utilise un outil de déploiement automatisé et seulement 15% utilisent un outil de gestion de configuration, qui est principalement Puppet.
Étonnamment, peu d’opérationnels utilisent un outil de virtualisation d’infrastructure, et quand c’est le cas ils utilisent Esx Vmware (65%) ou KVM (35%).

Interactions exploitants / développeurs

Il est étonnant de remarquer que 50% des développeurs qui ont répondu, ne connaissent rien des outils utilisés par les exploitants qui déploient leur code. De plus, seulement 35% des développeurs ayant répondu utilisent les métriques métiers et le monitoring de l’environnement de production.
Alors que 80% des exploitants estiment les livrables d’une qualité jugée “correcte”, 50% pensent que les logs des applications ne sont pas exploitables directement et sont difficiles à explorer. Nous avons observé très peu de mise en place de capacity planning (10%).
60% des développeurs ont la perception (peut-être erronée) que les exploitants comprennent sans ambiguïté les procédures de déploiement des équipes de développement.

Les défis des entreprises

D’après notre sondage, le principal défi à relever pour les entreprises réside dans l’amélioration des processus, de leurs définitions, il convient aussi pour eux, d’augmenter le support apporté à la livraison logicielle (57%) et d’optimiser les coûts de livraisons afin d’en augmenter leurs fréquences (42%). Nous avons été surpris de constater que la traçabilité des problématiques n’est pas un élément d’optimisation majeur tout comme la reproductibilité des livrables, bien que nous comprenons ces résultats par le besoin d’aller de l’avant des entreprises. Les métriques de succès d’un projet sont (par ordre d’importance) selon les répondants sont:

1. Améliorer la satisfaction client
2. Réduire les erreurs de processus de livraison
3. Réduire les coûts de chaque livraison
4. Réduire le temps entre le début du développement d’une fonctionnalité et l’utilisation de celle-ci par le client final (ce qui revient à réduire le temps entre la demande et son accomplissement)
5. Réduire le nombre de retour-arrières lors des livraisons

Les principales difficultés rencontrées lors des déploiements sont les étapes manuelles résultants d’erreurs dans les procédures et de la difficulté à configurer plusieurs type d’environnements pour une même application.
84% des sondés pensent que les erreurs de production auraient pu être détectées plus en amont, preuve que la démarche DevOps est donc toutefois très attendue sur le domaine de la qualité.
Un des points d’amélioration important pour près de 70% des répondants est d’optimiser la transparence entre deux versions d’application pour les exploitants.

Freins et besoins des entreprises

Aujourd’hui, les principaux freins au DevOps sont : devoir affronter la peur du changement et une certaine résistance à celui-ci des équipes et de l’organisation, mais aussi de la démarche n’est pas jugée prioritaire ce qui ralentit son adoption. Par ailleurs de nombreux chefs de projet estiment qu’il est difficile de mesurer et justifier l’intérêt des coûts dans ce domaine ainsi qu’il est difficile de mesurer le retour sur investissement (en particulier sur le court terme)
Toutefois, et malgré ces difficultés, nos participants ont montrés un réel intérêt pour travailler dans des projets où on applique des principes DevOps. 60% des participants souhaiteraient pour leur entreprise et eux-mêmes des formations et du conseil, en particulier sur les bonnes pratiques. Ils sont très peu, 15%, à attendre une assistance technique ou un audit de leurs processus de livraison logicielle.

Conclusion

DevOps – une culture au profit du rendement. Ce sondage a été majoritairement effectué des développeurs (presque 60%). Pour eux, DevOps est surtout un changement de culture soutenu par des outils spécifiques. Le niveau de sensibilisation est pour autant très faible voir nul. Ceci est dû à différen
tes craintes :

• Peur du changement
• Gestion des conflits de priorités
• Arriver à mesurer et justifier les coûts investis dans cette transformation, trouver les bons outils ou les bonnes compétences.

Les enjeux perçus pour l’entreprise sont nombreux mais les plus importants selon les répondants sont des enjeux autour de la valeur de la démarche :

• L’amélioration de la satisfaction client
• La réduction des erreurs dans le processus de livraison
• La baisse des coûts de livraison
• De manière un peu moindre mais substantielle on retrouve aussi : “Assurer plus de transparence entre deux versions d’une application”.

Autant d’enjeux auquel la démarche doit donc apporter des réponses sans plus tarder pour faciliter son intégration dans les sociétés.