Maintenir
Mettre à jour son outil : pourquoi, et quand.
Un outil sur mesure repose sur des composants qui évoluent. Les tenir à jour protège sa sécurité et prolonge sa vie.
Pourquoi
Votre outil repose sur des briques qui évoluent.
Votre outil n'est pas écrit en entier à partir de rien : il repose sur un framework, Symfony, et sur des bibliothèques écrites par d'autres. On les appelle les dépendances. Leurs auteurs publient régulièrement des mises à jour, dont des correctifs de sécurité.
Ce que les mises à jour apportent
Ce qu'un outil à jour garde, et ce qu'un outil oublié perd.
- Les failles de sécurité connues sont corrigées
- Les bogues sont corrigés
- Il reste compatible avec les versions récentes de PHP et du serveur
- Il reste lisible et reprenable par un autre développeur
Un outil qu'on ne met jamais à jour accumule des failles connues, publiques, que les attaques automatiques recherchent.
Quand une version vieillit
Une version à support long ne dure pas toujours.
Chaque version à support long de Symfony reçoit des correctifs pendant une durée limitée, puis son support s'arrête. Passé ce terme, les failles découvertes ne sont plus corrigées.
Il faut alors passer à la version à support long suivante. C'est une mise à niveau, plus importante qu'une mise à jour courante, et elle se prévoit avant la fin du support.
Trois niveaux
Du correctif au changement de version.
-
Les correctifs
Ils corrigent des failles de sécurité et des bogues, sans rien changer à ce que fait votre outil.
-
Les mises à jour courantes
Le framework et les bibliothèques évoluent dans leur version : on met à jour, on teste, puis on met en ligne.
-
Le changement de version à support long
Quand une version arrive au bout de son support, l'outil passe à la suivante. C'est un chantier, qui se prévoit et se planifie.
Qui s'en charge
Pas depuis l'administration de votre site.
Votre outil se gère en deux parties. Dans son espace de gestion, vous modifiez vos contenus seul. Les mises à jour, elles, touchent les sources du projet : le code et ses dépendances. Elles ne se font pas depuis l'administration, et un administrateur ne peut pas les faire seul : un développeur les applique sur le projet lui-même.
On peut automatiser ces mises à jour avec une tâche planifiée (un cron). Le risque est de faire planter le projet : une mise à jour change du code dont d'autres parties dépendent, et personne ne s'en aperçoit.
C'est pourquoi une personne vérifie, et fait la recette après chaque mise à jour : elle teste l'outil, parcours par parcours, avant de le valider. Sans cette vérification, une mise à jour automatique est un pari.
Ce que nous faisons
Un suivi que vous composez avec nous.
Quand nous hébergeons votre projet, nous mettons à jour le serveur. Pour votre outil lui-même, vous composez votre suivi : mises à jour du framework, surveillance, intervention en cas de plantage, heures de maintenance. Nous ne mettons rien en production sans l'avoir testé.