Stored procedure sotto controllo del codice sorgente, best practice

Attualmente sto usando Tortoise SVN per il controllo del codice sorgente di un'applicazione Web .NET. Quale sarebbe il modo migliore per portare le nostre stored procedure di SQL Server nel controllo del codice sorgente? Attualmente sto usando VS 2010 come mio ambiente di sviluppo e mi sto collegando a un database SQL Server 2008 R2 fuori sede usando SQL Server Data Tools (SSDT).

Quello che ho fatto in passato è salvare i proc in un file .sql e mantenere questi file sotto il controllo del codice sorgente. Sono sicuro che ci deve essere un modo più efficiente di questo? Esiste un'estensione che posso installare su VS2010, SSDT o persino SQL Server sulla macchina di produzione?

Ci sono strumenti là fuori, come questo da Redgate , ma ho sempre scoperto che la cosa migliore è salvare come file SQL, forse anche in un progetto di database (SSDT?) Nella tua soluzione.

Insieme a questo, suggerisco le seguenti linee guida:

• Assumi sempre la versione SVN come "attuale" / "più recente"
• Assicurati che ogni script che esegui abbia un " if exists then drop" appropriato all'inizio
• Ricorda di scrivere le tue autorizzazioni, se presenti

Inizialmente puoi creare questi file SQL eseguendo script direttamente da SSMS e puoi impostare SSMS in modo da eseguire lo script di tutti i tuoi " drop" e " create", nonché i tuoi permessi.

Il salvataggio dei file SQL nel controllo del codice sorgente consente di controllare solo i file SQL. Non controlla le modifiche degli oggetti di database effettivi, né impedisce le modifiche simultanee dello stesso oggetto di database da parte di più utenti (e immagino che anche tu vorresti averlo sotto controllo). Quello che usiamo è uno strumento di terze parti ( versione ApexSQL), si integra sia con SSMS che con VS, è possibile scegliere se lavorare con una versione del database dell'oggetto o con una versione del controllo del codice sorgente. Se stai modificando una versione del database, viene automaticamente estratto solo da te, quindi nessun altro può modificarlo (non unisce le modifiche di utenti diversi). Solo quando lo ripeti, altri possono modificarlo. E puoi avere la tua versione SC diversa dalla versione di un oggetto live (lo uso quando parto per il giorno e ho intenzione di finire le modifiche e testarlo il prossimo)

Usa RedGate Source Control per collegarlo al tuo controllo sorgente.

http://www.red-gate.com/products/sql-development/sql-source-control/

Aggancerà il vostro SSMS direttamente al repository di controllo del codice sorgente e consentirà persino di controllare i dati statici.

Funziona come un fascino

Prova Ankhsvn , altamente raccomandato e gratuito.

Dalla homepage:

AnkhSVN è un provider di controllo del codice sorgente Subversion per Microsoft Visual Studio 2005, 2008, 2010 e 2012 .

AnkhSVN fornisce supporto per la gestione del codice sorgente di Apache ™ Subversion® a tutti i tipi di progetti supportati da Visual Studio e consente di eseguire le operazioni di controllo della versione più comuni direttamente dall'IDE di Microsoft Visual Studio.

La dashboard delle modifiche in sospeso offre una visione unica del processo di sviluppo e offre un facile accesso al codice sorgente e alle funzionalità di gestione dei problemi. L'integrazione del controllo del codice sorgente profondo (SCC) ti consente di concentrarti sullo sviluppo, mentre AnkhSVN tiene traccia di tutte le tue modifiche e ti fornisce gli strumenti per gestire efficacemente le tue esigenze specifiche.

Ho provato sia il progetto di database di RedGate che Visual Studio e preferisco memorizzare la definizione del database nel progetto di database. Non appena il database diventa parte della soluzione, è possibile utilizzare il provider di controllo del codice sorgente preferito. La maggior parte ha un'eccellente integrazione con Visual Studio.

Con gli strumenti SSDT hai la "versione più recente" della definizione del database, che ti consente di fare facilmente confronti tra schemi e generare script di aggiornamento dello schema.

Detto questo, lo schema di solito è solo una parte dell'equasion. Nella vita reale si scopre che i database hanno già molti dati. E i miei utenti tendono a rimanere piuttosto delusi quando lo perdono.

Quindi, non appena ho implementato la versione 1.0, è necessario mantenere gli script di aggiornamento. A volte questi contengono solo modifiche allo schema, ma molte volte ho bisogno di creare valori predefiniti basati sul contenuto di qualche altra tabella, ho bisogno di rilasciare un vincolo particolare fino a quando non ho seminato i dati, ecc. Di solito semplicemente l'aggiornamento dello schema non lo taglia del tutto. La mia preferenza è quella di avere questi script di aggiornamento in una cartella separata anche nel progetto del database. Questi di solito sembrano "aggiornamento da v1.0 a v1.1".

I miei database hanno sempre una tabella di riferimento che mi dice il numero di versione corrente, quindi posso bloccare gli aggiornamenti incompatibili. La prima affermazione nei miei script di aggiornamento controlla la versione corrente e salva se è diversa da quella prevista.

Un altro vantaggio dei progetti di database è la possibilità di distribuire diversi set di dati basati sullo stesso schema. Ho un set di dati diverso per lo sviluppo, il team QA, il test di accettazione dell'utente e per i test di integrazione automatizzata. Poiché un progetto di database può avere solo 1 script post-distribuzione, il trucco qui è creare un nuovo progetto di database che faccia riferimento al progetto "master" e rendere il set di dati personalizzato parte dei processi post-distribuzione di quel progetto.

Questi erano i miei 2 centesimi, qualunque cosa tu provenga, soprattutto, deve adattarsi a te e al tuo team e, si spera, supportarti con la maggior parte dei compiti comuni.

Ho finito per scrivere uno strumento da solo.

È disponibile per il download gratuito - http://www.gitsql.net

Spero che aiuti altre persone che vogliono raggiungere lo stesso obiettivo finale.

Ecco un articolo che descrive come eseguire il controllo del codice sorgente di SQL Server. http://gitsql.net/documentation-04_SQL_Server_and_GIT

Ho provato a renderlo il più semplice possibile. (3 schermi)

• Connetti a SQL Server
• Seleziona gli oggetti
• Scegli la cartella da cui esportare / importare

Ho anche - accidentalmente - aggiunto la funzione di poter scegliere selettivamente i singoli oggetti da importare o esportare. Il che lo rende molto semplice durante lo sviluppo.

Di solito vorrei apportare una modifica a una procedura memorizzata e una tabella, quindi esportare quei due oggetti in una directory GIT.

Quindi uso Source Tree per vedere visivamente le modifiche e poi le commetto in bitbucket se sono felice.

La mia azienda ha appena sviluppato questo nuovo strumento ( gratuito ) che consente di estrarre facilmente script per database SQL, fare confronti , avviare WinMerge per confrontare rapidamente gli script con database live e sincronizzare le differenze sia aggiornando gli script che applicando le modifiche al database (ad eccezione delle tabelle, che implicherebbero maggiore complessità e maggiori rischi).

Servantt è WinMerge per confrontare i database di SQL Server con gli script controllati dalla versione.

Supporta e incoraggia le migliori pratiche nello sviluppo di software:

• Mantenimento degli oggetti del database sotto controllo versione (*)
• Rimozione dei diritti di accesso dagli sviluppatori negli ambienti di produzione
• Revisione DBA delle modifiche nelle procedure / viste per colli di bottiglia delle prestazioni e standard di denominazione
• Denominazione di oggetti mediante identificatori completi e delimitatori tra parentesi (corregge gli script CREATE PROCEDURE / VIEW / FUNCTION / etc)

(*) Gli script vengono salvati in una cartella locale che può essere una copia funzionante di Git, Subversion, TFS, Source Safe o qualsiasi altro VCS.

Download gratuito: http://servantt.com

La versione professionale (che è ancora in fase di sviluppo) sarà una bestia completamente diversa: è mirata all'automazione della distribuzione (gestione delle versioni), all'automazione di attività come l'aggiornamento di IIS, l'aggiornamento dei servizi di Windows, ecc.