Je suis développeur web freelance et propose des formations à Symfony2 ! Contactez-moi pour en discuter.

Récemment, la question de savoir s’il faut ou non mettre en prod un projet en fin de semaine a fait apparaître quelques trucs humouristiques, tel que Estcequonmetenprodaujourdhui.info ou bien l’image de CommitStrip.

Mon opinion sur la question est plus proche de celle développée dans l’article d’Yves, même si je trouve sa vision un peu trop manichéenne.

Selon lui les clés d’un déploiement réussi c’est, entre autres :

  • Un système de déploiement
  • Des tests
  • La maîtrise du volume de changement

Toujours selon lui, lorsque l’on maîtrise ces 3 éléments, on peut déployer n’importe quand.

Je le rejoins tout à fait sur le système de déploiement. Sans avoir un process complexe d’intégration continue, il me semble irresponsable de travailler sans un outil de déploiement qui permette d’annuler une mise en prod en cas de problème, et de revenir à un état antérieur stable. Pas besoin d’un système complexe pourvu que ça marche et qu’il soit fiable : je travaille actuellement avec un outil qui doit faire bien moins 30 lignes de script shell, et qui fait très largement ce dont j’ai besoin. Je peux déployer en une commande dans un terminal, et en cas de problèmes, revenir en arrière en une commande. Plein de solutions plus complètes existent, mais cela pourrait être le sujet d’articles dédiés.

Pour le reste, je suis plus modéré : il arrive que du code soit non testé car difficile à tester de manière automatisé, ou qu’il y ait des effets de bords difficiles à reproduire… bref dans la vraie vie, un déploiement, ça ne se passe pas comme ça devrait. N’empêche qu’avec un peu de bon sens et de bons outils, on peut mettre en prod un vendredi, pourvu qu’on maîtrise ce qui est fait.

C’est justement là où je voudrais en venir. Le bon sens.

Voici la scène à laquelle j’ai participé, impuissant :
Il y a 5 développeurs.
Celui qui doit mettre en production est arrivé récemment dans la société et doit réaliser son premier déploiement. Il doit donc être assisté pour utiliser les outils (qu’il ne connait pas), et pour vérifier qu’il n’oublie rien.
Un des autres développeurs doit partir à 17h et faire du télétravail le lendemain. 2 autres donnent une formation à l’étranger (6h de décalage horaire, mais joignables via messagerie instantanée). Le dernier, sur les lieux, n’a que peu d’expérience sur le projet, et n’a pas la main sur de nombreux outils (base de prod, outils serveur, etc…).
La mise en production ayant déjà été retardée à cause de divers problèmes pratiques, le moment où la mise en production peut effectivement avoir est jeudi vers 16h30.
Outils de tests automatisés : aucuns (à mon grand désespoir).
Impact de la mise en production : l’intégralité du site, car liée aux URls (le but étant d’améliorer le SEO).

Fallait-il mettre en production ce jeudi-là ?

Tel que je le présente, il me semble évident que non.

En effet avec n’importe quel outil de gestion de version, comme celui utilisé ici, il est possible pour ce développeur de continuer à travailler sur d’autres choses en attendant de pouvoir mettre en ligne lorsque les conditions sont propices. Je n’aurais pas fait ce déploiement de type ‘big bang’ le lendemain, mais j’aurais attendu le lundi. Le développeur le plus expérimenté travaillant depuis chez lui et 2 des autres n’étant joignables qu’à partir de 15h, celà n’aurait pas été idéal, d’autant plus que l’essentiel de l’activité de la société a lieu au cours du weekend, et qu’il est inconcevable que le site soit KO durant cette période. Bref, dans l’idéal j’aurais attendu lundi. Si ce n’était pas possible (admettons), j’aurais au moins attendu le lendemain, plutôt que de presser un développeur déjà stressé par l’impact potentiellement néfaste de son travail, et par la journée déjà bien avancée.

La mise en production a donc bien eu lieu. La mise en préproduction ayant en effet déjà démarré, les autres développeurs étaient bloqués pour faire les leurs. Divers projets n’attendant que l’arrivée d’un développeur rendaient également pressant ce déploiement. Plutôt que de revenir en arrière et faire le déploiement tranquillement le lendemain, il a été demandé de finir ce qui avait été commencé, afin de laisser la place aux autres par la suite. Intérêt faible : le gain de ce déploiement se consaste après plusieurs semaines, et via la gestion de version, tout le monde aurait pu s’y retrouver convenablement.

Je suis donc convaincu que le choix qui a été réalisé était plus mauvais qui puisse être fait.

Il n’a pas fallu beaucoup de temps pour me donner raison : le déploiement a échoué à cause de nombreux effets de bord qui n’apparaissaient pas dans les autres environnements (ce qui aurait pu  être évité), le déploiement a finalement été repoussé, et une nouvelle branche de travail a du être mise en place pour travailler en parallèle. Quand au malheureux développeur, il est resté jusqu’à 23h pour essayer de déployer, puis revenir en arrière.

Bref, ne pas oublier d’avoir du bon sens. C’est ce que font de nombreuses boites, qui n’ont plus à prouver qu’elles savent avoir une application en ligne. Déployer ne doit pas avoir à ressembler à ceci.

2 Réponses à “Déploiement, fin de semaine et bon sens”

  1. Nabellaleen Dit:

    En outre, le contexte de développement joue beaucoup. L’idée de déploiement continu reste cantonné à une partie du développement, et même à une partie seulement du développement « pour le web ».

    Pour une boite qui, quand elle livre, patch : le serveur, les alimentations de données, … avec des temps de compilation de plusieurs heures pour les softs « lourds », le déploiement continu est un doux rêve 😉

    Qui plus est dans des domaines où le droit à l’erreur n’est pas permit (blocage des transactions, etc …) et où l’activité principale du client est le week-end.

    Donc en effet, comme tu le dit : il ne faut pas être trop manichéen ! 🙂

  2. CrEv Dit:

    Hum…

    Dans l’histoire présentée, ça c’est mal passé. Mais ça ne remet absolument pas en cause le principe. Là on dirait un peu « ça c’est mal passé donc non on ne peut pas déployer n’importe quand, c’est trop simpliste ».

    D’ailleurs on le voit très bien : « ce déploiement de type ‘big bang’ »
    Ben voilà, l’une des principales erreurs est là.

    Souvent ce genre de déploiement peut être éviter. Par exemple, plutôt que d’envoyer une modification qui va impacter toutes les urls, on le fait url par url (ou ensemble d’url).
    Ou alors en doublonnant, histoire qu’il y ait au même moment les anciennes et les nouvelles mais par exemple en ne référençant que les anciennes. Ainsi il est possible de tester les nouvelles sans que les utilisateurs y accèdent.
    Et on peut même faire les deux approches, pas toutes les urls et doublée.
    De cette manière les tests peuvent être réalisés en condition réelle, il ne reste plus qu’ensuite à passer une à une vers les nouvelles urls.

    Et non c’est ni simple, ni simpliste. Au contraire, ça demande du taff de le faire petit à petit. Mais c’est ce qui permet d’être serein et d’avoir l’assurance que ça fonctionne.

    Le déploiement en continue c’est surtout le déploiement de chaque fonctionnalité, de chaque amélioration, modification, correction. Le reste (tests et outil de déploiement) c’est justement de l’outillage pour rendre ça facile. Mais ce qui compte le plus c’est la première partie : de petites modifications.
    Et l’outillage fera qu’il devient négligeable de déployer (la partie technique j’entends) et donc fait qu’on peut se permettre de déployer 10, 20 fois par jours sans problème.

    Le bon sens il est surtout de ne pas s’entêter à faire des déploiements big bang. Et si on doit en faire, alors là on rentre dans un cadre totalement différent, et ça se fait, comme on dit, avec ceinture + bretelles.
    Mais très souvent on peut l’éviter, ne serait-ce qu’en poussant en production des fonctionnalités non utilisées par les utilisateurs / clients mais permettant de passer les modifications en douceur et utilisables pour les développeurs.

Répondre

Unable to load the Are You a Human PlayThru™. Please contact the site owner to report the problem.