Ma définition

Le DevOps consiste à faire converger les pratiques de développement et d’exploitation pour fiabiliser et accélérer le cycle de vie logiciel : cela comprend la conteneurisation des applications pour garantir la reproductibilité des environnements d’un poste de développement à la production, la mise en place de pipelines d’intégration et de livraison continues (CI/CD) capables de bloquer automatiquement un déploiement défaillant et la supervision continue des services déployés, qu’ils soient en production ou en environnement d’expérimentation personnel.

Mes éléments de preuve

Pour le projet PMT de l’ISCOD, j’ai dockerisé l’application selon une approche Multi-Stage Build, séparant l’environnement de construction de l’environnement d’exécution pour optimiser la taille des images finales compilant le projet Maven, installant les dépendances et générant le bundle Angular de production, servi par un serveur Nginx dont la configuration a été spécifiquement ajustée pour rediriger toutes les routes vers la page « index.html », condition nécessaire au bon fonctionnement d’une Single Page Application. 

J’ai ensuite configuré une pipeline CI/CD, déclenchée à chaque push sur la branche principale, exécutant les tests automatisés des deux applications avant toute construction d’image puis authentification sécurisée au Docker Hub via les GitHub Secrets et publication automatisée des images.

Résultat : Des temps de traitement réduits, des processus simplifiés permettant d’apporter une valeur ajoutée directe grâce à l’outil, une pipeline CI/CD pleinement opérationnelle garantissant qu’aucune régression fonctionnelle ne peut être poussée vers une image de production.

Mon autocritique

Cette compétence est celle où j’ai progressé le plus récemment, notamment par le fait de construire soi-même une chaîne complète de bout en bout plutôt qu’en appliquant une procédure imposée par un tiers. Le principal enseignement tiré du projet PMT de l’ISCOD est la valeur concrète de ma première version des images Docker, construite sans séparation entre phase de build et phase d’exécution, produisait des artefacts inutilement lourds et lents à déployer, embarquant des outils de compilation totalement inutiles à l’exécution finale. 

Mon conseil est donc le suivant : toujours faire échouer volontairement un test en local avant de faire confiance à sa pipeline CI/CD. 

Cette réflexion peut surprendre mais c’est aussi un bon moyen de vérifier que le test bloque au déploiement en guise de vérification que j’ai moi-même systématisée sur PMT après avoir douté, en première configuration, du bon déclenchement réel de ce blocage en cas d’échec.

Mon évolution

Je souhaite approfondir l’orchestration à plus grande échelle (Kubernetes) au-delà du Docker Compose actuellement maîtrisé afin de pouvoir déployer mes conteneurs directement sur une infrastructure Cloud publique (sur AWS par exemple). Il s’agit déjà d’un objectif clairement identifié pour la prochaine itération de mon projet PMT, dans une logique de passage d’un environnement de démonstration local à un outil réellement accessible en production.

Dans le même temps, je souhaite également enrichir ma pipeline CI/CD actuelle, aujourd’hui centrée sur le déclenchement des tests et la publication d’images, avec des étapes supplémentaires de qualité continue pour me rapprocher des standards de sécurité DevSecOps attendus en environnement grand compte, à l’image de ce que j’ai pu observer chez CGI sur des chaînes de déploiement à plus grande échelle.