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 ?