La production n'est pas prête pour l'utilisateur
La livraison continue est l’objectif ultime des organisations qui adoptent DevOps. Ce n’est pas le but ultime, car cela impliquerait un déploiement continu.
On fait beaucoup de bruit dans les coulisses de DevOps en ce qui concerne la capacité à livrer des logiciels prêts à être mis en production plusieurs fois par jour.
C'est bien.
La raison pour laquelle cela ne m’enthousiasme pas trop est que, dans la majorité des entreprises, même celles qui adoptent DevOps, la livraison n’est que la première étape de la phase de « mise sur le marché » du cycle de vie d’une application. Peu d’applications sont « prêtes » pour les utilisateurs lors de cette notification de build et de publication finale. Il doit encore être déployé en production où une variété de procédures et de politiques assureront sa bonne livraison aux utilisateurs.
Voyez, le déploiement continu est (devrait être, pourrait être, sera) l’objectif ultime des organisations qui adoptent DevOps. Même si ce n’est pas le cas, le problème plus important est que la simple livraison à la production ne signifie pas qu’une application est « livrée » à ses composants. Cela nécessite un déploiement, en production, ainsi que tous les services requis pour faire évoluer, sécuriser et accélérer l'application afin de garantir qu'elle offre une expérience d'application optimale aux utilisateurs, qu'ils soient professionnels ou particuliers.
Cela peut impliquer un équilibrage de la charge, pour garantir l'évolutivité et la disponibilité. Cela signifie presque certainement la sécurité – au moins au niveau du pare-feu, espérons-le, la sécurité des applications, et peut-être plus encore. Cela peut également impliquer l’accès et l’identité. Peut-être pas pour les applications destinées aux consommateurs, mais celles destinées aux entreprises peuvent avoir besoin d'être incluses dans des politiques SSO ou fédérées pour garantir un accès fluide et sans problème. La vitesse, en termes de performances, peut également être requise.
Toutes ces choses doivent se produire avant qu’une application soit « prête » pour les utilisateurs. Et la « production » le sait. Parmi les 32 % de répondants à notre étude 2017 sur l'état de la distribution des applications qui se situaient dans la catégorie « nous avons 1 à 10 de ces services déployés », la majorité se situait dans la catégorie « nous en avons plus de 5 », 63 % indiquant que 6 à 10 sont déployés aujourd'hui.
Indépendamment des problèmes de « déploiement continu », ces services sont essentiels pour garantir que les applications sont « prêtes pour les utilisateurs » et pas seulement « prêtes pour la production ».
Livrer plusieurs fois en production c'est bien, mais livrer plus fréquemment sur le marché c'est le véritable objectif. Même si DevOps s'immisce dans la production (allez-y ! L'eau est bonne, vraiment !) pour gérer l'application et son infrastructure immédiate, il y aura toujours des services en amont qui devront être provisionnés, configurés et testés avant que l'application puisse être réellement considérée comme « livrée ».
La publication plus fréquente d'applications en production n'a pas réellement d'impact sur le calendrier de déploiement. Il y a une raison pour laquelle les projets open source ont une branche « stable » et une option « nightly build ». Bien sûr, je peux obtenir la dernière et la meilleure version, mais en tant qu’utilisateur, je préfère l’option « stable », car le fait que des applications se bloquent ou se plantent de manière aléatoire ne contribue en rien à une expérience d’application positive.
Le calendrier de déploiement doit être piloté par l'entreprise et mis en œuvre par le service informatique, ce qui implique d'impliquer le service informatique (les quatre opérations) pour commencer à automatiser autant que possible le processus. Parce qu’une application n’est pas prête à l’emploi dans sa production sécurisée et accélérée par les services qui l’entourent.