DevOps et CI/CD, intégration continue et déploiement automatisé
Le DevOps est une façon de travailler qui rapproche le développement d'un logiciel de son exploitation, avec un but simple, livrer plus souvent et se tromper moins. Pour y arriver, nous installons une chaîne CI/CD (intégration continue et déploiement continu). À chaque modification du code, des tests et des contrôles se lancent tout seuls. La version validée part ensuite en ligne sans que personne ait à toucher au serveur. Nous travaillons avec des PME, des start-up, des structures publiques, depuis Bastia ou à distance.
DevOps et CI/CD expliqués simplement
Dans beaucoup de structures, mettre en ligne une nouvelle version d'un site ou d'un logiciel se fait encore à la main. Quelqu'un copie des fichiers sur le serveur, tape quelques commandes, vérifie que la page s'affiche. Ça marche. Jusqu'au jour où une étape passe à la trappe. Le DevOps remplace ces gestes par des procédures automatiques, écrites une fois, testées, puis rejouées à l'identique.
- 01
L'intégration continue (CI)
Dès qu'un développeur envoie une modification, le code est assemblé puis passe une série de tests, sans intervention humaine. Un test échoue, et la modification est bloquée avant d'atteindre vos utilisateurs.
- 02
Le déploiement continu (CD)
Une fois validée, la nouvelle version se déploie automatiquement, ou d'un clic. Elle passe d'abord par un environnement de test, puis arrive en production, c'est-à-dire sur le site ou l'application qu'utilisent vos clients.
- 03
Les conteneurs
Un conteneur (Docker, par exemple) est une boîte standardisée qui contient l'application et tout ce qu'il lui faut pour tourner. Elle se comporte de la même façon sur le poste du développeur que sur le serveur de test ou en production.
- 04
La supervision
Après chaque déploiement, une surveillance automatique vérifie que l'application répond normalement. Au moindre écart, elle envoie une alerte.
Les signes qu'il est temps d'automatiser vos déploiements
- 01
Les mises en production font peur
On les repousse, on les regroupe, on les lance tard le soir. Et chacune apporte son lot de surprises.
- 02
Des bugs corrigés réapparaissent
Sans tests automatiques, une correction peut en casser une autre. Souvent, ce sont vos clients qui s'en aperçoivent les premiers.
- 03
Une seule personne sait déployer
La procédure n'est écrite nulle part. Si cette personne part en congé ou quitte l'entreprise, plus personne n'ose toucher au serveur.
- 04
Plusieurs développeurs ou prestataires interviennent
Chacun arrive avec ses habitudes et ses outils. Une chaîne commune impose les mêmes contrôles à tout le monde.
- 05
Vous devez rendre des comptes
Une structure publique, ou une entreprise qui traite des données sensibles, doit pouvoir dire qui a mis en ligne quoi, et à quel moment.
Une démarche DevOps à la taille d'une PME, d'une start-up ou d'une collectivité
Le DevOps n'est pas réservé aux grandes entreprises du numérique. La chaîne suit la taille du projet. Pour un site d'entreprise, quelques tests et un déploiement automatique suffisent ; une plateforme métier demandera plusieurs environnements, des contrôles de sécurité et des validations manuelles.
Nous travaillons avec des start-up qui livrent souvent et veulent garder ce rythme en grandissant. Avec des PME qui font évoluer un logiciel métier ou une boutique en ligne, aussi, et avec des structures publiques qui ont besoin de traçabilité. En Corse, beaucoup d'activités vivent au rythme de la saison. Pouvoir corriger un bug en pleine affluence, sans risquer de tout casser, a une valeur très concrète.
Mettre en place une chaîne d'intégration continue, étape par étape
- 01
État des lieux
Nous regardons votre code et les tests qui existent déjà, votre hébergement, la façon dont se font les mises en ligne aujourd'hui. Nous repérons les gestes manuels, les risques, et ce qui peut s'améliorer vite.
- 02
Conception de la chaîne
Nous fixons avec vous les contrôles à automatiser et les environnements nécessaires. Reste la question des secrets, autrement dit les mots de passe et les clés d'accès. Ils sont stockés à part, jamais dans le code.
- 03
Mise en œuvre progressive
D'abord l'intégration continue. Ensuite le déploiement automatique sur un environnement de test, puis la production, avec une procédure de retour arrière qui ramène à la version précédente si quelque chose se passe mal.
- 04
Passation
Nous documentons la chaîne et expliquons son fonctionnement à vos développeurs ou à votre prestataire. S'il faut l'ajuster plus tard, nous restons joignables.
Ce que vous obtenez, du pipeline CI/CD à la documentation
En fin de mission, vous disposez d'un pipeline CI/CD. C'est la suite d'étapes automatiques qui mène d'une modification du code à sa mise en ligne, configurée dans l'outil d'intégration continue qui convient le mieux à votre projet. Vous récupérez aussi les images Docker de vos applications, les environnements de test et de production, la procédure de retour arrière, les notifications en cas d'échec. Une documentation complète l'ensemble, pour que n'importe quelle personne compétente puisse reprendre la chaîne.
Nous appliquons ces principes à nos propres projets. L'un d'eux, La Forge, est une usine logicielle pilotée par des agents autonomes. Elle transforme un besoin en code testé et relu, et ses contrôles tournent grâce à Docker et à une chaîne d'intégration continue. Là-bas, le déploiement automatisé n'a rien d'une option. Tout repose dessus.
Les risques à vérifier avant d'automatiser
- 01
Des tests trop légers
Une chaîne automatique vaut ce que valent les contrôles qu'elle lance. Avec des tests trop minces, on se croit protégé alors qu'on ne l'est pas. Nous commençons donc par les parcours les plus critiques.
- 02
Des secrets exposés
Un mot de passe oublié dans le code, c'est une faille ouverte. Nous isolons les secrets, et la chaîne n'a que les droits dont elle a strictement besoin.
- 03
Les évolutions de base de données
Changer la structure d'une base de données pendant un déploiement demande des précautions, parce qu'un retour arrière n'est pas toujours possible si on ne l'a pas préparé.
- 04
La dépendance à un outil
Nous préférons des étapes portables, fondées sur Docker et des scripts standards. Changer de plateforme ne vous obligera pas à tout réécrire.
- 05
Une chaîne trop complexe
Une automatisation que personne ne comprend finit en boîte noire. Nous la calibrons pour l'équipe qui devra la faire vivre.
Ce qui fait varier le coût d'un projet DevOps, et la suite
Le coût dépend du nombre d'applications concernées et de l'état du code, des tests déjà en place, du nombre d'environnements à créer. La complexité de l'hébergement compte aussi, comme les exigences de sécurité ou le temps de formation de vos équipes. Écrire des tests là où il n'y en a pas est chiffré à part, ce qui vous laisse le planifier.
Une fois installée, la chaîne demande peu d'attention. Elle doit tout de même suivre la vie du projet, avec des outils à mettre à jour, de nouveaux tests, parfois un nouvel environnement. Nous pouvons en assurer le suivi seul, ou avec l'infogérance de vos serveurs.
Technologies et méthodes
- Docker
- Linux
- GitHub Actions
- CI/CD
- Tests automatisés
- Retour arrière
- Supervision
Questions fréquentes
Les tests utilisent-ils les données de nos clients ?
Non. Les tests tournent sur des données fictives ou anonymisées. Vos vraies données restent en production, ce qui réduit le risque de fuite et simplifie le respect du RGPD.
Faut-il réécrire notre logiciel pour mettre en place une chaîne CI/CD ?
Rarement. La plupart des applications entrent dans une chaîne d'intégration continue telles qu'elles sont. Il faut parfois les adapter pour qu'elles tournent dans un conteneur, ou sortir la configuration du code. Dans ce cas nous avançons par petites étapes, sans interrompre votre activité.
Quels outils utilisez-vous ?
Docker et Linux au quotidien, avec les outils d'intégration continue les plus répandus. Mais nous partons de ce que vous utilisez déjà. Si votre code est hébergé sur une autre plateforme ou si votre équipe a ses habitudes, nous adaptons la chaîne plutôt que de vous imposer un changement.
Que se passe-t-il si un déploiement automatique échoue ?
La version n'est pas mise en ligne si un test échoue, et l'équipe est prévenue. Quand un problème n'apparaît qu'après la mise en production, la procédure de retour arrière remet la version précédente le temps de corriger.
Notre équipe pourra-t-elle gérer la chaîne sans vous ?
Oui, c'est le but. La chaîne est documentée, enregistrée avec votre code, et expliquée à vos développeurs. Ensuite, vous la faites évoluer seuls ou vous nous appelez de temps en temps.