Stratégie de déploiement et séparation des environnements : un serveur de développement face aux revirements

Une phrase plus forte que tous les documents de conception : « Montrez-moi d’abord, pour voir »

Quand je me suis retrouvé à assurer seul tout le développement sur un projet d’intégration de systèmes (du développement sur commande) pour un organisme public, le plus grand obstacle n’était pas la technique. C’était l’« incertitude ». L’environnement idéal, où la conception découle d’un cahier des charges minutieux, n’existait pas. Les interlocuteurs côté client, qui avaient peu de connaissances en développement, ne savaient souvent même pas ce qu’ils voulaient avant d’avoir vu l’écran de leurs propres yeux.

« Hum, sur l’image, je ne me rends pas bien compte… On ne peut pas cliquer pour de vrai ? »

Chaque fois que je terminais une fonctionnalité, je la lançais en local (sur mon ordinateur), je faisais des captures d’écran et je préparais un « fichier de rapport » (HWP/PPT ; HWP est le format de traitement de texte courant en Corée) annoté au stylo rouge, que j’envoyais par mail. Mais de simples images statiques ne suffisaient pas à satisfaire l’interlocuteur.

« Ah, finalement, la fonctionnalité de tout à l’heure était mieux. Vous pouvez revenir en arrière ? » « Qu’est-ce qui se passe quand on clique sur ce bouton ? Faites-moi une vidéo. »

Hier, c’était A qui plaisait ; aujourd’hui, on réclame B. Modifier le code en local, refaire les captures, rédiger le rapport : une boucle infinie. Je passais plus de temps à écrire des rapports qu’à développer. Le monde à l’envers.

J’en ai pris douloureusement conscience : « Il ne s’agit pas d’envoyer des captures de mon écran. Il me faut un terrain de jeu (un serveur de développement) où l’interlocuteur peut entrer lui-même, cliquer tant qu’il veut et même tout casser. »

Les occasions arrivent par hasard : la redécouverte d’un serveur abandonné

Justement, lors de la scission de l’entreprise, notre équipe a eu la chance de se voir attribuer un serveur inutilisé (un ordinateur vide). Sa configuration n’avait rien d’extraordinaire, mais Linux y était installé et il disposait d’une IP publique : une ressource précieuse.

« Chef, je peux utiliser ce serveur qui traîne ? J’aimerais en faire un serveur sur lequel notre interlocuteur pourra tout vérifier lui-même. »

Feu vert. J’ai déversé dans cette carcasse vide tout ce que j’avais appris jusque-là et j’ai commencé à bâtir mon « petit empire d’infrastructure à moi ». C’était la synthèse de mes mois de galère (les séries Works on My Machine & The Pipeline).

1. GitLab (dépôt de code) : J’installe un dépôt privé pour gérer le code en toute sécurité.
2. Docker Registry (registre d’images) : Je crée notre propre entrepôt pour stocker les images Docker construites.
3. Portainer (gestion des conteneurs) : Pour moi qui ai peur de la CLI, il permet de gérer Docker via une GUI.
4. Nginx (serveur web) : Je poste un gardien qui règle la circulation des requêtes vers le frontend et le backend.

La solution : séparer complètement les environnements (Dev vs Prod)

J’avais désormais deux scènes (serveurs). Pour absorber les caprices de l’interlocuteur tout en protégeant le serveur de production, j’ai scindé ma stratégie de déploiement en deux.

1. Serveur de développement (Development) : « un laboratoire en toute liberté »
   • L’interlocuteur n’a même pas le temps de demander : « C’est fait ? »
   • Dès que du code arrive sur la branche develop, le pipeline se lance aussitôt et le code est déployé automatiquement.
   • L’interlocuteur peut se connecter à tout moment à l’URL du serveur de développement pour tester les fonctionnalités et donner son avis.
2. Serveur de production (Production) : « un sanctuaire où seul le validé entre »
   • Le déploiement n’a lieu que lorsque l’interlocuteur déclare : « C’est validé, on garde cette fonctionnalité ! »
   • Le code est fusionné (Merge) dans la branche master, et le déploiement n’a lieu que si j’appuie moi-même sur le « bouton de validation du déploiement » dans GitLab (Manual).

[Code Verification] Mettre de l’ordre grâce au déploiement conditionnel

GitLab CI permet de définir un chemin de déploiement différent pour chaque branche. Traduite en code, cette stratégie donne ceci :

stages:
  - build
  - deploy

# 1. Build (commun)
build_job:
  stage: build
  script:
    - ./gradlew build
    - docker build -t my-reg/app:$CI_COMMIT_SHA .
    - docker push my-reg/app:$CI_COMMIT_SHA

# 2. Déploiement sur le serveur de développement (automatique)
# Dès que du code arrive sur la branche 'develop', on déploie sans poser de questions.
deploy_to_dev:
  stage: deploy
  script:
    - ssh user@dev-server "docker service update --image my-reg/app:$CI_COMMIT_SHA app-dev"
  only:
    - develop 

# 3. Déploiement sur le serveur de production (validation manuelle)
# Même si du code arrive sur la branche 'master', rien n'est déployé tant que je n'ai pas appuyé sur le bouton.
deploy_to_prod:
  stage: deploy
  script:
    - ssh user@prod-server "docker service update --image my-reg/app:$CI_COMMIT_SHA app-prod"
  only:
    - master
  when: manual # Le point clé ! Ne s'exécute que 'si un humain appuie sur le bouton'.

Points clés :

• only: - develop : la branche de développement est toujours déployée automatiquement. La vitesse avant tout.
• when: manual : la branche de production a un garde-fou, puisqu’un humain vérifie encore une fois avant d’appuyer lui-même sur le bouton.

Pour conclure : enfin au complet, mon « Je vis seul » version développeur

Désormais, même moi, développeur solo, je dispose d’un système parfait.

1. Local : développement des fonctionnalités sur mon ordinateur.
2. Développement (Dev) : un simple git push, et cinq minutes plus tard, c’est en ligne sur le serveur de développement. L’interlocuteur vérifie lui-même.
3. Production (Prod) : seules les fonctionnalités validées sont regroupées puis déployées en toute sécurité, en un seul clic.

Fini le temps où, jeune recrue, je faisais des heures supplémentaires à lancer l’outil de capture et à annoter des fichiers HWP. Quand l’interlocuteur me dit « Vous pourriez changer ça ? », je réponds « Oui, c’est corrigé et en ligne sur le serveur de développement, vous pouvez vérifier », et je bois tranquillement mon café. Parce que le système travaille à ma place.

Ainsi s’achève le long projet [Re: Booting]. Des bases de l’informatique jusqu’à Linux, Docker et les pipelines CI/CD. J’espère que ces connaissances, accumulées à la dure en partant de zéro, serviront de petite lanterne à tous les « développeurs full-stack par nécessité » qui, quelque part, se battent encore seuls en ce moment.