Il y a quelques années, ces produits semblaient très limités et peu utilisables. On les apprenait pour les certifications, et puis on les oubliait. Mais la donne a changé !
Daveo a bien grandi. Les 2000 minutes gratuites de GitHub sont devenues insuffisantes. Et GitHub a commencé à facturer le ‘self hosting’. On a compris qu’il faudrait payer. Alors on a étudié à nouveau le marché de la CI/CD.
Surprise ! On a constaté que la solution Google a bien évolué. Elle couvre nos besoins. Elle est gratuite à notre échelle. Et, plus le projet est petit, plus elle apporte de bénéfices.
Une belle histoire : le petit projet et le développeur
Pour bien comprendre les enjeux, voici l’histoire d’Oryvalis, une jeune entreprise (fictive) de négoce d’agrumes. Elle compte 6 salariés, dont Déborah, Achille, Dave et Théo.
Déborah est la directrice commerciale et marketing. Elle supervise Achille, un acheteur de choc.
Théo est CTO et directeur logistique. Il supervise Dave, un jeune développeur qui travaille sur la plateforme logistique.
Dave a produit TopHA, un logiciel pour aider Achille, constitué d’un site web hébergé sur Google Cloud Run (un front et un back), et qui utilise Google Firestore comme base de données. Classique.
Achille a des idées géniales pour l’amélioration de TopHA et les décrit à Dave et à Déborah. Dave interrompt son travail sur la plateforme logistique, et prend quelques heures pour implémenter ces idées, et installer la nouvelle version dans un environnement de test. Il informe Déborah, qui demande à Achille de tester. Et il reprend son travail sur la logistique.
Achille est très content. Déborah demande à Dave d’installer en production. Dave interrompt son travail sur la logistique, et installe en production.
Jusqu’ici, tout va bien. Aucun intérêt à déployer une CI/CD comme font les grandes entreprises.
L’histoire commence à faire peur : le renfort qui fait chuter la productivité
Achille a d’autres idées géniales. Mais Théo explique à Déborah que Dave va devoir rester sur la plateforme logistique : c’est la priorité ! L’entreprise est en croissance et a les moyens d’investir. Théo décide de faire appel à Daveo pour qu’un autre développeur, Max, vienne améliorer TopHA.
Dave interrompt son travail sur la logistique, et prend deux heures pour expliquer à Max comment compiler et construire TopHA. Max est très efficace : en une moins d’une heure, il a implémenté les idées d’Achille. Il le dit à Dave, qui interrompt son travail sur la logistique, et prend deux heures pour montrer à Max comment installer en test. Dave reprend la logistique. Max informe Déborah, et Achille teste en quelques minutes. C’est bon ! Il faut installer en production. Max saurait installer en production : c’est la même procédure qu’en test. Mais Théo ne souhaite pas qu’on lui donne les mots de passe de la production. Alors Dave interrompt son travail sur la logistique, et prend une heure pour installer en production et vérifier que tout va bien.
Bilan de la journée :
- TopHA a été modifiée, testée et mise en production en une journée. C’était finalement un petit changement. Déborah et Achille n’ont eu à y consacrer que quelques minutes.
- Dave a été interrompu 3 fois. Il a travaillé 2 heures sur la logistique et 5 heures sur TopHA. Il est perplexe : s’il avait implémenté lui-même l’évolution, il n’y aurait passé que 3 heures en tout.
Bien sûr, c’est une histoire fictive. Dans la vraie vie, Dave n’aurait pas été libérable aussi vite. Il aurait fallu 3 semaines de délai. Déborah se serait demandé pourquoi l’évolution prenait tant de temps, et elle aurait été perplexe.
La solution : cliquer sur Cloud Deploy sans interrompre “le gars qui connait”
Les grandes entreprises déploient une CI/CD pour de nobles causes, comme l’homogénéisation des processus et la systématisation des scans de sécurité. L’un des bénéfices est applicable à toutes les tailles de projet : s’il suffit d’appuyer sur un bouton pour déployer, inutile de solliciter un sachant à chaque étape du projet.
Nous allons reprendre notre belle histoire, avec Google Cloud Deploy.
Quand Max aura fini son travail, Cloud Deploy installera automatiquement TopHA en test. Quand Achille aura testé, Déborah pourra cliquer elle-même sur un bouton, et Cloud Deploy installera TopHA en production. Dave ne sera plus interrompu, ni même sollicité.
Personne ne sera perplexe.
Le magicien de l’histoire : Cloud Build
Parce que les petites applications se ressemblent beaucoup, la manière de les construire peut souvent être devinée en étudiant leur code. De brillants ingénieurs ont créé les Buildpacks. Ces outils regardent le code source et devinent la manière de construire le logiciel.
Google Cloud Build utilise les Buildpacks pour construire une application. En une ligne de commande, et sans Dockerfile, on peut construire une image Docker et l’envoyer dans Google Artifact Registry.
Il est possible de configurer le build avec un fichier, comme avec toute solution de CI, mais l’écriture de ce fichier est optionnelle. Dave n’a donc pas d’effort particulier à fournir pour mettre en place Cloud Build lorsqu’il développe la première version de TopHA. En fait, il va même gagner un peu de temps.
Le truc du magicien : l’intégration avec GitHub
Même avec Cloud Build, Max n’est pas autonome pour construire l’application et pour la déployer en environnement de test. Pour obtenir cette autonomie, Dave doit travailler un peu, et automatiser le build et le déploiement.
Disons-le franchement : il y a peu de chances que Dave stocke son code source chez Google. Si Cloud Build et Cloud Deploy ont bien avancé, ce n’est pas le cas de Cloud Source Repositories. D’ailleurs, Google a arrêté de le commercialiser en 2024. À la place, un autre produit : Secure Source Manager. Il s’agit d’une implémentation de Git, fonctionnellement comparable à GitHub, mais avec un prix inadapté pour Dave : au minimum 1000$ par mois, plus 10$ par mois et par développeur.
Donc Dave utilise probablement GitHub, GitLab, Bitbucket ou une autre solution pour ranger son code source.
Cloud Build peut être déclenché à partir de chacun de ces produits. Dave doit mettre en place un trigger. Et là, il faut un peu de savoir-faire. Google a bien documenté les trois étapes nécessaires, mais Dave va vraiment devoir connaitre un peu Google Cloud.
Non, en fait, la magie n’existe pas : la configuration de Cloud Deploy
Maintenant que Dave est lancé dans Google Cloud, il va devoir continuer pour mettre en place Cloud Deploy. Le fonctionnement est similaire à Kubernetes. On écrit un fichier qui décrit un objet, et on lance une commande pour que Cloud Deploy crée cet objet.
Les objets nécessaires sont :
- Un “service” par composant à déployer (front, back), peut être décliné par environnement (pour la configuration spécifique de chaque environnement)
- Un fichier de configuration de Skaffold, l’open source qui se cache derrière Cloud Deploy. Ce fichier définit des profils, en s’appuyant sur les “services”.
- Un “target” par environnement (développement, test, production)
- Un “pipeline” qui décrit l’ordre des “targets” (développement, puis test, puis production) avec, pour chaque “target”, les profils à déployer.
Une fois que cette configuration est faite, Cloud Deploy sait afficher à Déborah, pour chaque livraison (release), la séquence des environnements (targets). Elle peut cliquer pour passer à la suite : installer en test et, quand c’est bon, installer en production. Le tout sans recourir à Dave.
Un dernier effort : Dave doit compléter la configuration Cloud Build, pour automatiser la création de la “release” dans Cloud Deploy. Aïe ! On avait dit que Cloud Build pouvait fonctionner sans configuration. Mais, pour l’utiliser avec Cloud Deploy, on va quand même devoir faire une configuration. On aura aussi la possibilité de lancer des tests juste après l’installation en développement. Au moins, Deborah ne demandera pas à Achille de tester quelque chose qui ne marche absolument pas. Et, tant qu’on y est, on peut aussi configurer l’envoi d’un mail à Deborah quand l’installation en test a été faite.
Enfin, ça c’est une solution. On peut aussi faire le contraire : déclencher Cloud Build à partir de Cloud Deploy.
Ce n’est pas si simple mais, la bonne nouvelle, c’est que Daveo peut vous aider.
Le happy ending : ça y est, ça marche !
Voilà. C’est fait. On peut demander à Max d’intervenir.
Chaque fois que Max a terminé une évolution dans le code source, Cloud Build prépare le logiciel, l’installe en environnement de développement, lance les tests automatisés, et indique à Cloud Deploy qu’il y a une nouvelle version. Cloud Deploy installe la version dans l’environnement de test, et notifie Deborah.
Quand Achille a donné son feu vert, Deborah peut appuyer sur un bouton, et Cloud Deploy installe cette version en production. En cas de problème, Deborah peut cliquer sur le bouton de la version précédente, pour revenir à une situation qui marche.
Dave a eu tout le temps nécessaire pour développer la plateforme logistique.
Et le meilleur : ça ne coûte presque rien. À la date de la rédaction de cet article, Cloud Build offre 2500 minutes gratuites par Billing Account, et environ un tiers de centime par minute supplémentaire. Cloud Deploy est gratuit pour un pipeline actif dans le mois. Chaque pipeline actif supplémentaire est facturé 5$ par mois.
Adieu perplexité, bienvenue productivité !
