Quel pallino è un’aggiunta o modifica per il nostro source control plugin. In caso di rimozione, avremmo notato un pallino vuoto all’interno. 

Aprendo il database da un’altra postazione le nostre modifiche non saranno visibili. Esattamente come per il codice, solo un Get Lates Version (disponibile anche con i tool di terze parti che stiamo utilizzando) porterà le modifiche committate (non quelle pending) alla nuova workstation. In questo modo, ogni dev è libero di fare le proprie modifiche senza rischiare di intaccare il lavoro altrui. Estendendo, ogni team potrà effettuare il proprio lavoro senza disturbare gli altri.

Già questo comportamento aiuta molto ad evitare conflitti, almeno nel database di sviluppo che poi verrà utilizzato per la promozione del codice nei vari ambienti. 

Rimane tuttavia di estrema importanza una figura che comprenda le modifiche che ogni branch porta con sè per determinare, in caso di conflitto, quale sia la decisione da prendere. Una sorta di committer per ogni team per il rilascio delle modifiche e la gestione appunto dei conflitti. 

In base al programma determinato per i deploy è inoltre importante capire quando effettuare operazioni di merge. Nella realtà che sto seguendo, ogni branch, una volta portata nella main line, deve essere “mergiata” fin da subito verso le altre linee di sviluppo, il tutto per ridurre al minimo le possibilità di conflitto o di rottura. Ma su questo argomento ci sono vari tipi di approccio, e questo post non vuole essere una documentazione a riguardo 

Ma cerchiamo di fare qualcosa di più, andiamo a creare un backlog item e un paio di task figli per la gestione della tabella di esempio:

Possiamo notare che la nostra iterazione (Sprint 1) ha un solo Backlog Item (add dbo.Foo Table) il quale a sua volta ha due figli, uno per la creazione della tabella ed uno per il popolamento, guardacaso assegnati al sottoscritto .

Andiamo ora ad associare il nostro cambiamento al task che ha come id 421, utilizzando Sql Server Management Studio ed il plugin:

Ecco la nostra tabella, notate il commento “Table dbo.Foo created #R421“:

seguiti dall’id del task.

Premendo il pulsante Commit il task 421 verrà chiuso come Done. Infatti nel TFS avremo questo nel task 421:

Aprendo il task, vedremo il changeset legato alla sua chiusura:

Vedere il codice relativo è semplice.. spostiamoci nella parte relativa sul TFS e vediamo cosa contiene il changeset 283:

Si tratta dello script di creazione della nostra tabella all’interno di un file .sql. Fino all’atto del checkin la cartella Tables era vuota. 

Se volessimo mettere sotto controllo del codice sorgente anche i dati, è sufficiente legare anche i dati che il tool di terze parti chiama “static“:

Con la view successiva è possibile selezionare quali tabelle legare al source control. Selezioniamo appunto l’unica tabella creata. Questa operazione serve per il prossimo esempio.

Anche i dati infatti verranno inseriti con formato .sql sul source control server.

Ipotizziamo ora di lanciare uno script che modifica il tipo del campo FooData e che successivamente inserisce i dati all’interno della tabella:

ALTER TABLE dbo.Foo ALTER COLUMN FooData varchar(100) NULL;

GO

 

INSERT INTO dbo.Foo ( FooData )

VALUES

        ( ‘ONE’ ),

        ( ‘TWO’ ),

        ( ‘THREE’
),

        ( ‘FOUR’
),

        ( ‘FIVE’
);

GO

Noteremo una nuova entry nei cambiamenti in sospeso (Commit changes), poichè la tabella dbo.Foo è ora sotto controllo del codice sorgente anche per i suoi dati:

Oltre alla alter, notiamo anche un DATA LINK changeset, dedicato appunto alle insert.

Con questo checkin abbiamo risolto il task 422 e su TFS possiamo vedere le modifiche alla struttura con l’operazione di compare:

e i dati invece sono salvati all’interno della cartella dedicata:

Con questi semplici esempi abbiamo visto come direttamente da Sql Server Management Studio è possibile gestire la propria branch di sviluppo. Ovviamente con una sola tabella non è così importante, ma immaginate di avere tanti oggetti, tabelle, viste, stored procedure. Quello che non si vede poi ma che è di estrema importanza, è un progressivo che il tool di red-gate aggiunge nei metadati del nostro database per tenere un progressivo di versione e determinare appunto il flusso di ogni deploy, con tanto di alert in caso di mismatch di revisioni.

Con questo plugin, nessun dba o dbdev dovrà separarsi da Management Studio ed il track delle modifiche sarà molto più semplice e comodo, poichè sempre integrato nella shell.

Ecco, quanto abbiamo visto aiuta tantissimo l’organizzazione del team, del codice e dei rilasci, il che riduce, e non di poco, la superficie in cui si può incappare in seri problemi di gestione della vita dell’applicazione.

RISORSE:

Stay Tuned!