Un ramo "modello" è una pratica comune?

5

Ho pensato che potrebbe essere una buona cosa avere un ramo di controllo della versione dedicato per tutte le modifiche dello schema del database e volevo sapere se qualcun altro sta facendo lo stesso e quali sono stati i risultati.

Dì che stai lavorando con:

  1. Modello / documentazione dello schema (alcuni file in cui il database viene modellato visivamente per generare l'origine dello schema, ad esempio MySQL Workbench, con un file .mwb, che è binario)
  2. Sorgente dello schema (un file .sql)
  3. Generazione di codice basata sugli schemi

Il modo normale in cui stavamo lavorando era con i rami di funzionalità, quindi dovevamo apportare modifiche ai file di modello (quelli specifici del database), quindi dover rigenerare i punti 2 e 3, affrontando i possibili conflitti (o persino la riscrittura del codice ).

Ora dì che il tuo flusso di lavoro si comporta allo stesso modo della precedente numerazione degli articoli. Con un ramo del modello non dovresti riconciliare il modello dello schema con i binari in altri rami di funzionalità, o devi rigenerare lo schema di origine e rigenerare il codice (che potrebbe avere il codice umano sopra di esso).

Per me è molto sensato che sia strano non averlo visto prima come pratica comune.

Modifica : conto che le fusioni delle filiali siano le asserzioni per il modello che corrisponde al codice. Io uso un DVCS, quindi non ho paura di rami di lunga data o di fusioni dall'aspetto spaventoso. Sto anche facendo il branching delle funzionalità.

    
posta dukeofgaming 10.10.2012 - 07:28
fonte

3 risposte

6

Vorrei sconsigliarlo. Gli schemi del database cambiano insieme ad altri codici o risorse correlate. Per essere in grado di tracciare correttamente le modifiche, devi fare in modo che le modifiche coesive si colleghino tra loro e un commit condiviso è il modo migliore per farlo.

Considera il tuo suggerimento di mantenere lo schema in un ramo separato. Prima di tutto, tieni i rami in modo da poter spingere i cambiamenti indipendentemente da altre modifiche non correlate. Cosa succede se si esegue il push dello schema senza il codice corrispondente?

  1. Si crea la cronologia del commit che appare "inaspettatamente". È difficile seguire da dove viene o perché, dopo un po '.
  2. Se si commettono solo schemi, ricorda che anche altri possono farlo. Ciò significa che gli altri possono tirare e quindi riscrivere / modificare le tue modifiche dello schema e passare comunque tutti i loro test (perché non stanno testando il tuo codice ). Quindi, quando vuoi impegnare il tuo codice, ottieni dei conflitti, che altrimenti potrebbero essere evitati.

Potrebbero esserci altri svantaggi o anche vantaggi. Ma questi 2 qui sono una ragione sufficiente per non prendere questo approccio.

Spero che ti aiuti.

    
risposta data 10.10.2012 - 07:50
fonte
1

Suggerirei di mettere insieme tutti i tipi di codice sorgente che creano un sistema in esecuzione (includendo database-query e -schema)

Perché? Perché, quindi, hai sempre una relazione tra il tuo codice e il resto delle cose che creano il tuo sistema (configurazione, SQL, Readmes, Test, ...). Se apporti una modifica, ti verrà sicuramente ricordato di cambiare anche quegli altri artefatti. Se hai diversi rami, o anche diversi repository, è molto più difficile ricordare quale revisione del ramo A appartiene a quale revisione del ramo B, sebbene porti a errori.

Lavoravamo con le filiali di rilascio, una volta. A tale scopo, tutti gli sviluppatori hanno concordato una procedura comune:

  1. risolve un bug nel ramo di rilascio
  2. crea una patch / diff
  3. applica il diff al ramo principale

Questo non è molto bello, perché duplichi le modifiche che avrebbero potuto essere unite. Ma è un approccio semplice, ogni sviluppatore può gestire e l'unione SVN / CVS a volte è un dolore nel linguaggio.

    
risposta data 10.10.2012 - 10:42
fonte
0

È una cattiva idea in termini di "filosofia di sviluppo" e usabilità

  • hai rotto la regola "ramo per attività / funzione" - il ramo del modello non ha un'attività correlata (o più di un'attività in un intervallo di tempo)
  • Questo ramo sarà "sempre attivo"
  • ulteriore permanente si fonde con le feature-branch e le build danneggiate se l'unione fallisce dopo le modifiche allo schema
risposta data 10.10.2012 - 17:02
fonte

Leggi altre domande sui tag