Sto riprogettando uno strumento CRM, di sorta, da zero. Stiamo creando l'applicazione e il database da zero. Affinché gli sviluppatori rimangano lontani gli uni dagli altri, ogni sviluppatore ha una copia locale del database dell'applicazione piuttosto che condividere un singolo database di sviluppo. Ciò evita il caso in cui lo sviluppatore 1 effettui una modifica al database che funzioni per loro, ma interrompe l'applicazione per tutti gli altri finché lo sviluppatore 1 non verifica le loro modifiche al codice.
Su suggerimento di una risposta a una simile domanda simile che ho visto quando stavamo iniziando, manteniamo nel controllo del codice sorgente una cartella di script SQL numerati sequenzialmente. Quando uno sviluppatore apporta modifiche al proprio database, esegue lo script di tutte le modifiche in un file SQL e lo controlla insieme alle modifiche al codice dell'applicazione. In teoria, suona bene, ma qui ci sono alcune difficoltà:
- Se 5.sql è l'ultimo script di modifica del database archiviato, tutti gli sviluppatori (di solito tutti) che apportano nuove modifiche al database creano un file denominato 6.sql perché si tratta di una situazione di tipo first-come-first-serve. Ma può esserci solo un 6.sql archiviato. Quindi devi controllare quali file stanno pianificando di controllare prima di creare il tuo prossimo file SQL o appena prima di fare il check-in, controllare cosa c'è già e rinominare il tuo file il prossimo (che è tecnicamente ancora soggetto a un conflitto se due sviluppatori effettuano il check-in contemporaneamente).
- Una volta aggiornato, è necessario eseguire gli ultimi file SQL per aggiornare il database con l'ultimo codice recuperato. Questo è facile da dimenticare fino a quando non si esegue l'applicazione e si fa esplodere qualcosa. Ma il problema più grande è che è difficile ricordare quale file è stato eseguito per ultimo, cioè su quale versione il tuo database è già acceso.
- Nessuna fusione o rilevamento di conflitti. Se 2 sviluppatori stanno controllando gli script di aggiornamento nello stesso momento, gli script di sviluppatore 2 potrebbero avere modifiche in conflitto con le nuove modifiche degli sviluppatori 1. PER ESEMPIO. Supponiamo che lo sviluppatore 2 scriva uno script per modificare la colonna Person.ModifiedDate su NOT NULL, ma appena prima che lo sviluppatore 2 effettui il check in, lo sviluppatore 1 controlla uno script che modifica il nome di Person.ModifiedDate in Person.LastModifiedDate. Lo sviluppatore 2 rinominerà il proprio file in modo che il nome del file non sia in conflitto e verifichi inconsapevolmente quello che ora è uno script rotto, o dovrà seguire un protocollo che non può controllare uno script sql fino a quando non applica tutti gli ultimi e convalida il loro script. Questo è un processo doloroso, specialmente se lo sviluppatore 2 è andato e ha applicato le modifiche dello sviluppatore 1, aggiornato i propri script e poi ha provato a fare il check-in solo per trovare lo sviluppatore 3 ha ora controllato uno script.
Quindi sto pensando di scrivere un'app console che viene eseguita prima della compilazione per afferrare i file di script ed eseguirli contro il database in ordine. Dovrebbe solo memorizzare l'ultimo file che ha eseguito da qualche parte in modo da sapere se ci sono nuovi script da eseguire la volta successiva. Sembra che sistemerà il n. 2, ma qualcuno usa una strategia migliore che risolva tutti i problemi? Finora abbiamo evitato i conflitti lavorando su parti non correlate dell'applicazione, ma man mano che andiamo avanti diventeremo sempre più difficili da fare e la strategia attuale richiede troppa disciplina per gli sviluppatori - sappiate che finirà per causare problemi.