49 lines
2.6 KiB
Plaintext
49 lines
2.6 KiB
Plaintext
---
|
||
description: Workflow MS1 — JIRA, validation avant gros changements, code legacy, promotion BD
|
||
alwaysApply: true
|
||
---
|
||
|
||
# Workflow MS1 inscription
|
||
|
||
## Numéro JIRA (MSIN-xxxx)
|
||
|
||
- Au début d'une tâche de développement (nouvelle feature, correctif, refactor), **demander le numéro JIRA** si l'utilisateur ne l'a pas fourni.
|
||
- Préfixe courant features : `MSIN-xxxx`. Continuité / ops BD peut aussi être `CON-xxxx`.
|
||
- Ne pas bloquer une simple question ou une lecture du code — seulement quand on s'apprête à modifier des fichiers.
|
||
- Référencer le ticket dans le code et les scripts SQL : `// MSIN-4290` ou `-- MSIN-4379 — description`.
|
||
- Nommer les nouveaux scripts SQL : `sql/MSIN-xxxx-description-courte.sql`.
|
||
|
||
## Promotion BD (règle absolue)
|
||
|
||
Ordre **non négociable** pour faire passer structure + données vers d’autres environnements :
|
||
|
||
1. **Scripts SQL** (`sql/MSIN-*.sql`) → exécutés **uniquement** sur **dev préprod**.
|
||
2. **Navicat** → copie de **structure** (préprod → autres env : dev prod, client préprod, client prod).
|
||
3. **Outil soft sync** (`php/sync_static_db.php`, CON-333) → peupler / aligner les **données** (manquants + corrections).
|
||
|
||
**Interdit** : demander ou suggérer de « rejouer le SQL » sur prod, préprod client, ou tout env autre que **dev préprod**.
|
||
|
||
- Table absente / Erreur lecture ailleurs = d’abord **structure Navicat** depuis préprod, **puis** sync outil.
|
||
- `info` : jamais de DELETE (auto-création `afficheTexte`). Soft only.
|
||
- Catalogues (droits, pages, doc…) : pas d’auto-création ; l’alignement données passe par l’outil, pas par un second import SQL.
|
||
|
||
## Portée des changements
|
||
|
||
- **Changement minimal** : corriger uniquement ce qui est demandé.
|
||
- Pas de refactor large, renommage massif ou « nettoyage » opportuniste sans accord explicite.
|
||
- Pour le code legacy (~10 ans), privilégier la cohérence locale (fichier / module touché) plutôt qu'une modernisation globale.
|
||
|
||
## Incohérences repérées
|
||
|
||
Quand du code voisin contredit le pattern du fichier ou du module :
|
||
|
||
1. **Signaler** brièvement l'incohérence à l'utilisateur.
|
||
2. **Proposer** une correction ciblée ou l'alignement sur le pattern dominant du module.
|
||
3. **Attendre confirmation** avant de corriger du code hors périmètre de la tâche.
|
||
|
||
## Fin de tâche
|
||
|
||
- Résumer ce qui a changé (fichiers, comportement).
|
||
- Pour le SQL : rappeler qu’il s’exécute **seulement en dev préprod**, puis structure Navicat + sync outil pour le reste — **pas** « exécuter ce script en prod ».
|
||
- Mentionner les étapes manuelles restantes (déploiement code, Navicat, sync soft, cache).
|