Une approche pragmatique et efficace

Faire le déploiement en suivant les pratiques DevOps permet de minimiser les problématiques futures. Une base DevOps solide fournit les méthodes et outils nécessaires pour une conception et une maintenance efficace des applications. Cela inclut de bonnes pratiques de développement, une méthode de validation des changements, les pipelines de CI/CD, l’infrastructure as code, la télémétrie et les alertes pour ne citer qu’eux.

Si tous les outils sont en place et fonctionnent, les équipes de développement gagnent les avantages suivants :

• Réduire le risque en réalisant le déploiement d’applications plus petites et de manière plus fréquentes.
• Gagner de la visibilité sur les performances de l'application et ainsi, détecter les problèmes avant les clients.
• Identifier les problèmes avant qu’ils n’arrivent en ayant des environnements pour tester les applications avant d’aller en production.
• Gagner en vélocité et réduire les coûts de développement, car plus un problème est trouvé tôt dans le processus, moins coûteux sera le correctif.

« Avoir une base DevOps solide permet de livrer de la valeur en production plus rapidement et de manière plus fiable. La notion de DevOps est complexe et nécessite une compréhension approfondie des différents aspects techniques en jeux : le développement logiciel, sa livraison, son suivi en production et sa maintenance. Il ne faut pas oublier que son objectif est d’unifier le développement logiciel (Dev) et l’administration d’infrastructure informatique (Ops) »

Julien Maitrehenry, co-fondateur de Kumojin

NOS BONNES PRATIQUES – LA RECETTE KUMOJIN

• Suivre de près la méthodologie de développement en 12 facteurs - https://12factor.net/.
• Réaliser des tests automatisés (unitaire, intégrations, etc.).
• Obliger une revue des paires.
• Développer et tester localement avec l'utilisation de ressources locales seulement.
• Encourager la formation et la veille technologique.
• Privilégier les solutions open source.
• Éviter de se verrouiller à un fournisseur / être agnostique de l'environnement Cloud.

NOS RECOMMANDATIONS

Une approche DevOps doit se faire par étape et il est important de ne pas en ignorer. Avant de penser à déployer automatiquement en production, il est important d’avoir les outils de test pour limiter les risques de briser quelque chose une fois en production.

Lors d’un changement de code, celui-ci devrait passer par les étapes suivantes :

• La conception.
• L'approbation du changement.
• La mise en production du changement.

Lors de l’étape de conception, il est important que le développeur suive, au moins, les étapes suivantes :

• Tester son changement de manière manuelle et/ou automatisée.
• Ajouter des tests automatisés (test unitaire et/ou test d’intégration) pour valider le changement.
• Valider que tous les tests automatisés existant continuent de bien fonctionner.

Rendu à l’étape d’approbation, l’équipe de développement doit s’assurer de minimalement :

• Valider le changement écrit par une revue de code (peer review).
• Proposer des améliorations, si nécessaire.
• S’assurer que les tests automatisés fonctionnent et ne retournent pas d’erreur (et idéalement, avoir un outil pour automatiser cette tâche - Intégration Continue).
• S’assurer que la documentation du projet est toujours à jour (README, wiki, etc.).

Et, à la dernière étape, la mise en production du changement, il est important de valider quelques points :

• Tester le déploiement dans un environnement de test (staging).
• S’assurer que si l’application à besoin de nouvelles dépendances et/ou configuration, l’environnement soit prêt.

Pour cette dernière étape, il est possible d’automatiser cela en utilisant les bonnes pratiques d’Infrastructure as Code, ainsi que d’automatisation des déploiements (Déploiement Continue– CD). Par exemple, s’il y a un besoin de modifier le schéma de la base de données, cela devrait faire partie de l’application/du processus de déploiement de le faire et non une opération humaine. Plus le processus sera automatisé, moins il y aura d’erreurs humaines possibles et cela permettra à plusieurs personnes de prendre cela en charge.

Comme je le disais précédemment, il est important d’y aller par étape, vouloir déployer en production avant d’avoir des tests automatisés ou un processus de validation est dangereux et contre-productif.

Notre deuxième recommandation serait d’éviter de s’attacher à des solutions propriétaires. Il y a plusieurs avantages à cela, il est plus facile de trouver de la main d’œuvre sur une solution open source populaire que sur un outil propriétaire demandant une licence. De plus, sur une solution open source, vous trouverez plus facilement du support de la part de la communauté.

Il est important de garder à l'esprit que nous sommes dans un modèle en constante évolution et, par conséquent, il est difficile de prédire l'avenir ainsi que l’évolution d’un outil, d’une technologie ou d’un fournisseur. De plus, nous vous recommandons de toujours garder un œil sur les éventuels inconvénients des solutions propriétaires dans le cas d'un fournisseur #Cloud par exemple.

« L'objectif est de rester flexible, et de ne pas se mettre dans une situation difficile. Je faisais partie d'une entreprise qui a décidé de changer de fournisseur de Cloud. Depuis le début, mon équipe est restée agnostique du Cloud en choisissant des solutions comme Kubernetes, NATS et OpenTelemetry. Cela nous a permis de migrer nos applications très rapidement. »

Simon Bernier, développeur FullStack, Kumojin

LA VISION KUMOJIN

L’un de notre mantra est de rester pragmatique. Quand vient le temps de partir un projet, on va y aller par étape, dans le but de livrer de la valeur le plus rapidement possible. Pour cela, on va dès le début mettre en place les principes DevOps vus au-dessus : mettre en place des tests unitaires, la revue des paires, l’intégration continue et le déploiement continue. Par contre, l’ajout d’un environnement de staging se fera plus tard et les tests d’intégrations surement aussi.

Il est important de jauger la quantité d’effort à mettre par rapport aux besoins réels. Quand vous partez un produit de zéro, mettre en place des bonnes pratiques est beaucoup moins coûteux que le faire dans une seconde étape. Cependant, vouloir avoir 100% des outils est peut-être prématuré.

Si vous voulez implémenter la philosophie DevOps dans un projet existant, il faudra commencer par regarder les besoins de l’équipe et y aller par étape : est-ce que le projet possède des tests ? Est-ce qu’il y a une étape de validation avant de merger un changement de code ? Et regarder ensuite ce qui est faisable et réaliste.

Il ne faut pas oublier le plus important : avoir du plaisir ! Nous croyons que toute équipe de développement doivent avoir du plaisir à travailler sur un projet et le DevOps doit être là pour aider les équipes et les soutenir.