Come si lavora sui pacchetti Oracle in un ambiente collaborativo e controllato dalla versione?

Question

Sto lavorando in un ambiente multi-sviluppatore in Oracle con un pacchetto di grandi dimensioni. Abbiamo un modello di promozione DEV => TST => PRD. Attualmente, tutte le modifiche ai pacchetti vengono eseguite direttamente in TOAD e quindi compilate nel pacchetto DEV.

ci imbattiamo in due problemi:

1. modifiche simultanee devono essere promosse su orari diversi. Ad esempio, lo sviluppatore A apporta una modifica che deve essere promossa domani mentre lo sviluppatore B sta lavorando contemporaneamente su una modifica che non verrà promossa per altre due settimane. Quando arriva il momento della promozione, ci ritroviamo a commentare manualmente cose che non sono ancora state promosse e poi decommentarle in seguito ... schifo !!!

2. Se due sviluppatori eseguono modifiche allo stesso tempo e una di esse viene compilata, cancella le modifiche dell'altro sviluppatore. Non c'è una bella unione; invece vince l'ultima compilazione.

Quali strategie consiglieresti per aggirare questo? Stiamo usando TFS per il nostro controllo sorgente ma non lo abbiamo ancora utilizzato con i nostri pacchetti Oracle.

P.S. Ho visto la pubblicazione this, ma non risponde completamente alla mia domanda.

Answer 1

Usiamo Oracle Developer Tools for Visual Studio.NET ... spine a destra in TFS

Answer 2

lo facciamo con un database Dev per ogni flusso e le etichette per i diversi flussi.

La nostra licenza Oracle ci dà dev illimitato/casi di test, ma siamo un ISV, si può avere una diversa opzione di licenza

Answer 3

La chiave è quella di adottare una pratica di distribuzione solo del codice dal sistema di controllo del codice sorgente. Non ho familiarità con TSF, ma deve implementare i concetti di rami, tag, ecc. La domanda su cosa distribuire poi cade fuori dalla build e rilascia i tag nel sistema di controllo del codice sorgente.

Ulteriori suggerimenti (per Oracle):

• funziona meglio se si divide la specifica del pacchetto e il corpo in file diversi che utilizzano un modello di file corrispondente per ognuna (ad esempio ".pks" per il pacchetto spec, e ".pkb" per il corpo del pacchetto). Se si utilizza un processo di compilazione automatizzato in grado di elaborare modelli di file, è possibile creare tutte le specifiche e quindi i corpi. Ciò minimizza anche le invalidazioni degli oggetti se si distribuisce solo un corpo del pacchetto.

• inserire l'ora per configurare un processo di compilazione automatizzato che è guidato da uno stato di release o build del sistema di controllo del codice sorgente. Se hai anche un numero moderato di oggetti di codice db pagherà per essere in grado di costruire il codice in un sistema di riferimento e confrontarlo con il tuo qa o sistema di produzione.

Answer 4

È possibile utilizzare gli strumenti di sviluppo Oracle per VS oppure è possibile utilizzare lo sviluppatore sql. Lo sviluppatore SQL si integra con Subversion e CVS e puoi scaricarlo gratuitamente. Vedi qui: http://www.oracle.com/technology/products/database/sql_developer/files/what_is_sqldev.html

Answer 5

Vedere my answer su Tools to work with stored procedures in Oracle, in a team (che ho appena ricatturato).

Riga inferiore: non modificare le procedure direttamente con TOAD. Archiviare il sorgente come file, che verranno archiviati nel controllo del codice sorgente, quindi modificati ed eseguiti.

Inoltre, consiglio vivamente che ogni sviluppatore lavori sulla propria copia del database (utilizzare Oracle Express, che è gratuito). È possibile farlo se si archiviano tutti gli script per creare il database nel controllo del codice sorgente. Maggiori informazioni can be found here.

Answer 6

Per evitare 2 sviluppatori che lavorano sullo stesso pacchetto allo stesso tempo:

1) utilizzare il sistema di controllo di versione come l'origine del codice di pacchetto. Per lavorare su un pacchetto, lo sviluppatore deve prima controllare il pacchetto dal controllo della versione; nessun altro può controllare il pacchetto fino a quando questo sviluppatore non lo ricontrolla.

2) Non lavorare direttamente sul codice del pacchetto in Toad o qualsiasi altro IDE. Hai senza indizio se il codice su cui stai lavorando è corretto o è stato modificato da uno o più sviluppatori. Lavora sul codice nello script che hai estratto dal controllo di versione ed eseguilo nel database per compilare il pacchetto. La mia preferenza è usare un editor di testo (TextPad) e SQL Plus, ma puoi farlo anche in Toad.

3) Al termine, ricontrollare lo script nel controllo della versione. Non copiare dal database nel copione (consultare nuovamente il punto 2).

Lo svantaggio (se si tratta di uno) di questo approccio controllato è che solo uno sviluppatore alla volta può lavorare su un pacchetto. Questo non dovrebbe essere un grosso problema finchè:

• Si mantengono i pacchetti di dimensioni ragionevoli (in termini di CHE COSA fanno, non quante linee di codice o numero di procedure in essi). Non ho un grande pacchetto che contiene tutto il codice.
• Gli sviluppatori sono invitati a controllare il codice solo quando sono pronti a lavorare su di esso, e a ricontrollarlo non appena hanno finito di fare e testare le loro modifiche.

Answer 7

Usiamo Toad for Oracle con il provider TFS MSSCCI contro TFS 2008. Usiamo un Custom Tool che tira checkin di database dal controllo di origine e li confeziona per il rilascio.

A mia conoscenza Oracle Developer Tools per Visual Studio.Net non ha alcuna reale integrazione di controllo del codice sorgente con TFS o altro.

Si potrebbe considerare Toad Extensions for Visual Studio anche se non è economico, forse 4 dollari credo.

Un'altra opzione è la Oracle Change Management Pack ma credo che richieda l'edizione Enterprise di Oracle che è molto più costosa.