Ho già parlato
in passato di come utilizzare
Visual Studio Online direttamente su
SQL Server usufruendo dell'estensione per SQL Server Management Studio,
Red-Gate SQL Source Control. Le operazioni di get e checkin hanno però un grosso problema di latenza, soprattutto durante la fase di lettura prima della sincronizzazione dei database. Questo accade perchè nella modalità direttamente collegata al source control si utilizzano le API di VSOnline. Ogni operazione utilizza una quantità considerevole di rete.
Proprio a causa di questo problema, ho deciso tempo fa di cambiare la tipologia di source control system, cambiando da "Team Foundation Server (TFS)" a "Working folder", così come indicato nella figura seguente:
Quando si crea questo tipo di link, non siamo più collegati direttamente al source control manager (e quindi non stiamo usando direttamente le API). Per questo motivo, le operazioni da cartella a database e viceversa si riducono a velocissime istruzioni di lettura e scrittura su e da file in locale. Utilizzare questo approccio riduce non di poco la latenza durante le operazioni di sincronizzazione. Ovviamente, non essendo più legati direttamente al source control, dovremo utilizzare un tool che mantiene la cartella sempre allineata, ma non credo si possa parlare di un vero e proprio "problema", visto che la maggior parte degli sviluppatori .net/sql possiede Visual Studio come IDE (o comunque un prodotto equivalente). Ragion per cui ognuno di noi dovrà mantenere costantemente aggiornate le working folder tramite il
Team Explorer fornito con l'installazione di Visual Studio (2010 e successive).
In realtà Team Explorer è strettamente necessario per la creazione del workspace, ma da quel momento in avanti si può usufruire del supporto dei power tools e della loro integrazione con l'esplora risorse di Windows (un video esplicativo qui).
Come lavora la modalità "Working Folder"?
Supponiamo di avere un workspace locale al percorso "C:\TFS_Workspace\Private" che, a sua volta, è mappato ad un repository remoto su Visual Studio Online:
Il database è collegato alla cartella "
C:\TFS_Workspace\Private\Databases\MyDatabase1". Ciò significa che ogni cambiamento fatto all'interno di questo path dovrà essere gestito dal Team Explorer. Per maggiori dettagli sul suo utilizzo,
leggere qui.
GET LATEST VERSION e sincronizzazione dal repository remoto
Utilizzando il source control explorer (di Team Explorer), premere il tasto destro sulla cartella del nostro database e selezionare "Get Latest Version":
L'operazione di get latest version è la più generica, ma è possible effettuare get di versioni passate, di changeset, di label e così via.
Siccome sul repository remoto di Visual Studio Online abbiamo, a titolo di esempio, una tabella già creata, l'operazione di get scaricherà l'aggiunta direttamente sul workspace, nella fattispecie al percorso "C:\TFS_Workspace\Private\Databases\MyDatabase1\Tables" (da notare che "Tables" è una cartella automaticamente creata dal tool di Red-Gate). Il workspace è aggiornato, ma il database non ancora, poichè abbiamo effettuato solo operazioni su Filesystem:
Stato del Filesystem
Stato su database
La tabella scaricata è proprio un file .sql al cui interno troviamo lo script di CREATE TABLE, le eventuali relazioni, i constraint, le proprietà estese e via discorrendo, il tutto scritto in t-SQL.
Andiamo ora ad applicare il changeset letto dal source control direttamente sul nostro database:
Dopo questa operazione la tabella è creata anche sul database.
Creare changeset e consolidare le modifiche sul worspace
Lanciamo ora qualche comando t-SQL per creare un nostro changeset. Ad esempio, andiamo a creare la seguente stored procedure:
CREATE PROCEDURE dbo.proc_Foo_Get
AS
BEGIN
SET NOCOUNT ON;
SELECT
id
, fooData
FROM
dbo.Foo
END;
GO
Andiamo poi a modificare anche la tabella precedentemente letta dal source control (dbo.Foo):
ALTER TABLE dbo.Foo ADD InsertTimestamp datetime NOT NULL DEFAULT(GETDATE());
Infine, spostiamoci sul tab del source control su SQL Server Management Studio nell'area "Commit Changes":
Vediamo la nuova colonna della tabella dbo.Foo e la nuova stored procedure aggiunta. In questo momento siamo solo sul nostro database e l'operazione "Save changes" non fa altro che creare il file della stored procedure e modificare il file della tabella SENZA ACCEDERE AL REPOSITORY REMOTO. Da notare che la stored procedure verrà creata sempre come un file .sql ma sotto al percorso "MyDatabase1\Stored procedures".
Commit dei file e invio verso il repository
La cartella ha al suo interno le nuove informazioni, in termini di nuovi file e modifiche a file esistenti. Non ci resta che spostarci su Visual Studio ed utilizzare il Team Explorer per controllare le "Included changes" su "Pending changes" ed inviare il changeset a VSOnline:
Nei cambiamenti da includere vediamo solamente la modifica sulla tabella. Questo accade perchè i nuovi file non creati con Visual Studio (come nel caso della stored procedure con Management Studio) non sono etichettati come "pronti per essere inviati per team explorer". Tuttavia, il Team Explorer si accorge ugualmente delle aggiunte e propone un link in cui è possibile recuperare e promuovere i cambiamenti notificati ma ignorati di default. Premendo su "Detected" avremo il riassunto delle operazioni fatte al di fuori dell'IDE:
Con "Promote" andiamo a forzare lo stato del file in modo da poterlo inviare al source control.
L'operazione di checkin rimane poi la medesima.
Conclusioni
Come abbiamo potuto constatare, ci sono differenze tra una gestione diretta del repository remoto e la modalità "Working folder":
1) dobbiamo utilizzare un source control management client per poter sincronizzare il repository remoto con le nostre cartelle locali
2) durante la fase di commit dei cambiamenti andiamo semplicemente ad effettuare operazioni sui file e non direttamente sul source control, cambiando, di fatto, solo lo stato dei nostri workspace
3) dobbiamo fare attenzione ai file aggiunti per la prima volta, poichè non sono automaticamente pronti per essere inviati al server
A prima vista queste operazioni potrebbero essere complicate, macchinose.. ma vi è anche da dire che le attese sulle operazioni di sincronizzazione calano drasticamente. E' vero, dobbiamo avere il Team Explorer, ma la curva di apprendimento è molto breve e i vantaggi ottenuti in produttività ripagano lo sforzo sostenuto. Inoltre, abbiamo un solo punto su cui gestire i nostri changeset. Lavorando in team, chiunque deve poter fare operazioni di checkin, di get, di merge (eventualmente).. E serve sempre tutto il pacchetto, non solo i cambiamenti a database. Esistono tante cose come l'applicazione che consuma le basi dati, i file di config, le risorse esterne ma salvate nei workspace, ecc. Diventa sempre più importante avere un solo punto in cui gestire il proprio lavoro unitamente alle versioni ed ai changeset che il team produce continuamente.
Stay Tuned!
