Come si fa a lavorare sui pacchetti di Oracle in un ambiente versione a controllo collaborativo?

Question

Sto lavorando in un ambiente multi-sviluppatore in Oracle con un pacchetto di grandi dimensioni. Abbiamo un DEV => TST => modello di promozione PRD. Attualmente, tutte le modifiche pacchetti vengono inviati direttamente in ROSPO e poi compilati nel pacchetto DEV.

Corriamo in due problemi:

1. modifiche simultanee devono essere promosse su orari diversi. Per esempio, lo sviluppatore Un apporta una modifica che ha bisogno di essere promosso domani, mentre lo sviluppatore B è contemporaneamente lavorando ad un cambiamento che non sarà promosso per altre due settimane. Quando arriva il momento di promozione, ci troviamo a commentare manualmente cose che non si sta ancora promosso e poi commentando che dopo ... che schifo !!!

2. Se due sviluppatori stanno facendo le modifiche allo stesso tempo esatto e uno di loro compila, si spazza via le modifiche dell'altro sviluppatore. Non C'è una bella fusione; invece l'ultima compilazione vince.

Quali strategie mi consiglia per aggirare il problema? Stiamo usando TFS per la nostra fonte-controllo, ma non abbiamo ancora utilizzato questo con i nostri pacchetti Oracle.

PS Ho visto questo distacco, ma non risponde pienamente alla mia domanda.

Answer 1

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

Answer 2

La chiave è quello di adottare una pratica di soli distribuzione del codice dal sistema di controllo del codice sorgente. Non ho familiarità con TSF, ma è necessario implementare i concetti di rami, tag, ecc La questione di cosa da distribuire poi cade fuori del costruire e rilasciare il tagging 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 pacchetto). Se si utilizza un processo di compilazione automatica in grado di elaborare modelli di file, allora si può costruire tutte le specifiche e poi i corpi. Questo riduce al minimo anche invalidazione degli oggetti, se si sta distribuendo solo un corpo pacchetto.

• mettere il tempo per configurare un processo di compilazione automatica che è guidato da una release o costruire lo stato del sistema di controllo del codice sorgente. Se avete anche un discreto numero di codice db oggetti sarà pagare per essere in grado di costruire il codice in un sistema di riferimento e confrontarlo con il vostro qa o sistema di produzione.

Answer 3

la mia risposta su Strumenti per lavorare con immagazzinata procedure in Oracle, in una squadra (che ho appena rimarcato).

Linea di fondo: non modificare le procedure direttamente con rospo. Conservare la fonte come file, che si memorizzare nel controllo del codice sorgente, modificare quindi eseguire.

Inoltre, vi consiglio vivamente che ogni sviluppatore lavora sulla propria copia del database (Oracle utilizzare Express, che è gratuito). Si può fare se si memorizzano tutti gli script per creare il database di controllo del codice sorgente. Un quadro più chiaro può essere trovato qui .

Answer 4

Per evitare di 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 di versione; nessun altro può controllare il pacchetto fuori fino a questo sviluppatore controlla nuovamente.

2) Non lavorare direttamente sul codice pacchetto Toad o qualsiasi altro IDE. Lei ha alcun indizio se il codice che si sta lavorando non è corretto o è stato modificato da uno o più altri sviluppatori. I lavori per il codice nello script che avete verificato dal controllo di versione, ed eseguire che nel database per compilare il pacchetto. La mia preferenza è quella di utilizzare un editor di testo bello (TextPad) e SQL più, ma si può fare questo in rospo troppo.

3) Una volta terminato, controllare lo script di nuovo in controllo di versione. Non copia e incollare il codice fuori il database nello script (vedi punto 2 di nuovo).

Il lato negativo (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 a patto che:

• mantenere i pacchetti verso il basso per una dimensione ragionevole (in termini di quello che fanno, non quante righe di codice o numero di procedure a loro). Non hai ancora un grande pacchetto che contiene tutto il codice.
• Gli sviluppatori sono invitati a controllare il codice solo quando pronti a lavorare su di esso, e di verificare di nuovo nel non appena hanno finito di fare e testare i loro cambiamenti.

Answer 5

lo facciamo con un database Dev per ogni flusso, e le etichette per i vari 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 6

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

Answer 7

Usiamo Toad for Oracle con il provider TFS MSSCCI contro TFS 2008. Usiamo un strumento personalizzato che tira di database checkins dal controllo di origine e li pacchetti per il rilascio.

A mia conoscenza di Oracle Developer Tools per Visual Studio.Net non hanno alcun controllo integrazione fonte reale con TFS o in altro modo.

Si potrebbe considerare estensioni Toad for Visual Studio anche se non è a buon mercato, forse $ 4k credo.

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