Que faire de Gemfile.lock et compo­ser.lock

L’objec­tif du Gemfile c’est de dire « le projet a besoin de la biblio­thèque X en version 4.5 mini­mum, et de la biblio­thèque Y en version 1.3 à 1.5 ». L’objec­tif du Gemfile.lock c’est de dire « ici on a X en 4.5.6 et Y en 1.3.8, c’est cet ensemble précis qui est testé et mis en produc­tion ».

J’ai encore vu passer la ques­tion il y a quelques jours

Le Gemfile.lock, c’est quoi la bonne pratique, je le pousse sur le git ?

Et la réponse clas­sique « Oui, pour s’as­su­rer que la produc­tion soit en phase avec les versions que tu as testé », avec parfois quelqu’un qui ajoute « sauf pour les paquets gem / compo­ser, où là il ne faut pas le pous­ser dans le dépôt git ».

Sauf qu’en fait c’est plus complexe, et ce n’est pas une problé­ma­tique tech­nique. C’est une ques­tion d’or­ga­ni­sa­tion :

Qui fait la main­te­nance appli­ca­tive ? Qui suit les mises à jour de sécu­rité au jour le jour ? Qui est dispo­nible en astreinte en cas de besoin ? Avez-vous une procé­dure de test auto­ma­tisé suffi­sam­ment fiable ? Quelle est la poli­tique de numé­ro­ta­tion de vos dépen­dances ?

Plus exac­te­ment, le Gemfile.lock et le compo­ser.lock doivent être maitri­sés par l’équipe qui gère la main­te­nance de sécu­rité.

Équipe de déve­lop­pe­ment

Ce peut être l’équipe de déve­lop­pe­ment. Dans ce cas c’est à elle de pous­ser le .lock sur son outil de version­ne­ment, de le mettre à jour et de déclen­cher un déploie­ment en cas de besoin.

Atten­tion : Dire « je pousse les .lock dans le git », c’est dire, « personne d’autre que moi ne doit y toucher ». C’est parfois présomp­tueux, mais ça veut aussi dire être respon­sable de la mise à jour, y compris quand on n’en n’a pas envie.

Ça veut dire surveiller en perma­nence le besoin de mettre à jour une des dépen­dances pour des raisons de sécu­rité. Ça veut dire une veille active sur le sujet, du temps dédié à ça, et des outils ou proces­sus bien défi­nis. Très peu d’équipes de dev ont ça.

Est-ce le rôle de votre équipe de dev ? en a-t-elle les moyens ? le temps ? l’au­to­no­mie ?

Équipe de produc­tion

À l’in­verse ça peut être à l’équipe de produc­tion de gérer ces arte­facts. Dans ce cas c’est à cette dernière de pous­ser les .lock sur leur propre version­ne­ment, avec le reste des confi­gu­ra­tions. Eux ont des proces­sus établis pour faire les veilles de sécu­rité, des astreintes en cas de mise à jour en urgence, etc.

En échange ça veut dire que les dépen­dances sont spéci­fiées très sérieu­se­ment et plus préci­sé­ment dans le Gemfile. Parfois dire « je veux la version 4.5.* » et pas unique­ment « je veux une version 4 ou supé­rieure ». Pous­ser le Gemfile.lock sur le git de l’équipe de déve­lop­pe­ment peut aussi être un indi­ca­teur que le Gemfile d’ori­gine est géré avec légè­reté au départ.

L’équipe de produc­tion se basera sur ces défi­ni­tions précises, sur les notes de mises à jour des dépen­dances, puis mettra à jour le code et le Gemfile.lock en fonc­tion. Elle fera ensuite passer les tests auto­ma­ti­sés, peut être une équipe de QA. À la fin elle pren­dra – ou non – la respon­sa­bi­lité de déployer en produc­tion la mise à jour sans passer par l’équipe de déve­lop­pe­ment, en fonc­tion de l’ur­gence et du risque. Ça impose donc aussi des tests auto­ma­ti­sés suffi­sam­ment solides pour se baser dessus lors d’une mise à jour mineure.

Dans une grosse struc­ture, ou avec une équipe de produc­tion dédiée de qualité, c’est proba­ble­ment une des meilleures options. Mais… votre équipe de produc­tion est-elle compé­tente sur ces sujets ? a-t-elle l’au­to­no­mie suffi­sante pour cela ? le code, le Gemfile et les tests auto­ma­ti­sés sont-ils suffi­sa­ment à niveau ?


par

Étiquettes :

Commentaires

2 réponses à “Que faire de Gemfile.lock et compo­ser.lock”

  1. Avatar de Mikael Randy

    Concernant composer, SensioLabs a mis à disposition un outil qui permet, pour chaque dépendance installée, de vérifier si une faille de sécurité connue concerne la version installée.

    Chez M6Web, nous avons branché ça dans notre outil d’intégration continue : si une faille est détectée, le build est en failure.
    C’est partiel, puisqu’il faut que la faille de sécurité soit connue de la base de données liée (https://security.sensiolabs.org/database), mais c’est déjà un bon pas ;)

    PS : a priori, il semble exister la même chose pour les fichiers Gemfile

    1. Avatar de Julien Breux
      Julien Breux

      Effectivement, il existe la même chose pour le Gemfile.
      D’ailleurs, pour les plus JS d’entre nous, il existe aussi David…

      D’autre part, nous, chez iAdvize, nous conservons les *.lock aussi pour une question de résolution plus rapide des dépendances.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *