Bien démarrer avec DevOps
Cet article récence tout ce dont vous avez besoin pour comprendre le mouvement DevOps, de l’identification des objectifs aux freins, en passant par les outils pour passer à DevOps.
A nouvelles approches en matière de développement, nouvelles difficultés. Le développement logiciel s’est radicalement transformé avec le concept DevOps, cet ensemble de pratiques qui permet d’associer développement et opérations. L’approche traditionnelle, qui implique des mises à jour majeures, mais rares, calées sur de longs cycles de développements et de tests, a souvent conduit à la frustration des utilisateurs. L’approche DevOps – qui permet de publier de petites mises à jour, mais de façon plus fréquentes – réduit les erreurs et renforce les relations critiques entre les équipes d’ingénierie, d’assurance qualité et l’IT.
Les pratiques DevOps font la promesse de réduire les silos et de faciliter la communication entre les équipes d’ingénieurs, l’IT et la qualité, parmi tant d’autres départements d’une entreprise. DevOps doit créer une forme de transparence complète au sein de l’entreprise pour faciliter la planification agile et accélérer la prise de décision.
Les longs cycles de mise à jour traditionnels apportent certes des changements majeures et ajoutent des fonctionnalités clés, mais peuvent également créer des bugs importants ou avoir des conséquences imprévues. La mise à jour suivante étant publiée plusieurs mois après la découverte de ces bugs ; ils ne seront pas corrigés rapidement ; la correction n’arrive que tardivement. Les longs cycles de développement créent souvent une coupure entre les équipes métiers et logicielles ; les objectifs des métiers changent et ceux des équipes logicielles ne s’adaptent pas en fonction. Ainsi les logiciels peuvent ne jamais satisfaire les objectifs de l’entreprise.
Les projets DevOps doivent identifier et s’aligner avec les besoins métiers – il faut toujours se demander pourquoi opter pour une approche DevOps et ce qu’il faut en attendre. Par exemple, si une entreprise perd des clients à cause de bugs, une des raisons d’opter pour DevOps pourrait être de raccourcir les cycles et étaler la correction de bugs dans plusieurs releases, améliorant la rétention des clients.
Les cycles courts de développement des projets DevOps offrent des possibilités étendues pour capturer les retours utilisateurs et mesurer l’impact des développements. Une approche DevOps peut en effet manquer son but si les bons critères ne sont pas mesurés ou du moins, régulièrement pris en compte. Par exemple, lorsqu’il s’agit d’un problème de bug, il s’agit de décider comment contrôler les critères de rétentions de clients, ou de satisfaction, puis analyser régulièrement ces métriques pour évaluer la réussite d’un projet DevOps. Les entreprises peuvent rapidement comprendre ce qui fonctionne et ce qui ne fonctionne pas, pour au final réaliser les ajustements nécessaires.
Les fournisseurs de l’IT, qui ont bâti leur modèle sur des pratiques de développements classiques, rencontrent certains obstacles lorsqu’ils passent à DevOps. Imaginez une approche projet par projet, plutôt qu’un changement brutal vers DevOps. Commencez par les projets les moins critiques, puis identifiez et levez les barrières qui se présentent. Au fur et à mesure que la culture et les processus de l’entreprise commencent à s’adapter aux pratiques DevOps, l’approche peut être portée à des projets plus importants.
Les outils DevOps
DevOps tient d’avantage de la gestion de projets que de langages particuliers et de plateformes. L’ingénierie, l’IT, l’assurance qualité doivent par exemple collaborer. Les outils de gestion organisationnelle fonctionnent généralement bien pour commencer. Lorsque l’approche DevOps monte en puissance et se généralise, d’autres outils peuvent l’améliorer :
- Git et Github proposent des dépôts de code qui supportent le contrôle de version et le téléchargement ;
- Le test de code peut être pris en charge par des outils Open Source comme Jenkins ;
- Nagios et Sensu contrôlent la façon dont les modifications de code influencent l’environnement ;
- LogStash passe en revue les logs pour connaître les performances du code ;
- Des plateformes de gestion de configuration comme Chef et Puppet peuvent aussi être optimisés avec d’autres outils comme Berkshelf.
Ce n’est là qu’un échantillon des outils qui mettent en valeur une démarche DevOps. Il en existe une kyrielle qu’il ne tient qu’à vous de tester et d’évaluer selon les besoins spécifiques de votre entreprise.
Le Cloud est-il une nécessité pour DevOps ?
Avec les pratiques traditionnelles de développement, les nouvelles versions sont rarement testées dans des environnements de production. Des erreurs en termes fonctionnels ou liées aux performances passent inaperçues dans les environnements de développements, non confrontées au contraintes de la production. Les capacités de dimensionnement et de self-service proposées par le Cloud permettent de provisionner des ressources et d’y placer de nouvelles versions pour effectuer des tests, sans trop dépendre des administrateurs IT. Cela permet donc d’accélérer les tests et de simplifier les demandes auprès de l’IT.
D’un point de vue global, le Cloud public est ici préférable car il offre des possibilités de scalabilité et de self-service sans risquer d’épuiser les ressources IT en interne. Lorsque les tests sont complets, les ressources peuvent être libérées pour réduire les coûts, jusqu’aux prochaines phases de test.
