Add an ADR about rollbacks and migrate down scripts

Author: BerengereC

docs/adr/0056-migrate-down.md

@@ -0,0 +1,63 @@
+# 56. Rollbacks et Migrate Down
+
+Date : 2024-12-19
+
+## État
+
+Draft
+
+## Contexte
+
+Nous souhaitons clarifier les procédures de rollback sur l'environnement production (retour en arrière de version classiquement).
+Meme si nous préférons privilégier l'application d'un patch en production pour résoudre un incident, il peut être nécessaire de faire un rollback de version, selon la nature de l'incident.
+Dans le contexte actuel, l'application d'un patch est une opération longue (25 min minimum). Une semi-automatisation permettrait d'amoindrir ce délai et de préférer cette solution au rollback de version dans certains cas.
+
+Les rollbacks de versions ne contenant pas de migration peuvent être effectués aujourd'hui en production. Pour cela, on redéploie la version précédante sur toutes les apps simultanément.
+
+Concernant les versions avec migration de données, le rollback est plus dangereux :
+- risque de perte de données,
+- un ordre d’exécution incertain peut causer des deadlocks,
+- incertitude quand à la qualité des « down » développés : pas toujours écrits, pas de tests, pas de validation…
+- Nécessité de synchroniser avec les responsables des différents incréments pour s’assurer que tout va bien se passer
+- Nécessité de bloquer les recettes potentielles en cours et corriger l'environnement de recette avant de refaire une Mise En Production.
+
+A l'avenir, le déploiement continu permettra de résoudre une partie des problèmes rencontrés et de limiter les risques.
+Dans le contexte d’aller vers du déploiement plus continu, l’effort à mettre transite ainsi vers notre rapidité à mettre en production.
+Le lien entre les captains et les équipes de dev reste essentiel, en cas de soucis les équipes doivent rester alerte pour prévenir de leurs incertitudes au plus tôt. Côté captains il faut continuer à bien remonter les alertes pour créer cet échange le plus rapidement possible.
+
+### Solution
+
+**Description**
+
+Après discussion en équipe, les captains proposent les préconisations suivantes :
+- Les PRs de migration de données ne doivent contenir que la migration. Idéalement dans 2 MEP différentes.
+- Séparer le code pour pouvoir revert plus facilement l’une ou l’autre.
+
+  (Idéalement, avoir une MEP échelonnée elles sont dans deux MEP différentes)
+- Les captains sont au courant au plus tot => On aimerait être reviewer de tous les scripts de migration
+- Nos précos pour les scripts de migration
+  - Les migrates down sont obligatoires 
+
+    (on peut en avoir besoin meme si on les fait manuellement, c’est une aide précieuse)
+
+  - On doit être capable de migrate up => migrate down => migrate up
+
+    Donc les scripts de migrations doivent être Idempotent,
+    
+    pas de modification de type,
+    
+    pas de pertes ni modifications de données (=> écrire un script différent dans ce cas, qui nécessitera une intervention captains, hors phase de mise en production)
+
+    La clause default sur le create/alter table est autorisée.
+
+
+**Avantage(s):**
+- Possiblité de mitiguer rapidement un incident en executant des rollbacks en production.
+- Pas de risque de perte de données sur un rollback.
+
+**Inconvénient(s):**
+- Risque  de délai supplémentaire pour les PR avec migration.
+
+## Décision
+
+## Conséquences