Source control za Oracle DB

Pozdrav,

vjerojatno su se svi koji se bave PLSQL razvojem susreli s problemom source controla u bazi podataka. U nekim firmama se source control uopće ne koristi pa si developeri redovito međusobno gaze verzije. Gubi se vrijeme na ručno uspoređivanje paketa (KDiff, WinMerge) itd.

Mene zanima na koji način vi koristite u svojim firmama source control, koji alat.

Čitao sam malo o produktu firme Red Gate (link). Ima li itko iskustva s tim komadom softvera? Uočene prednosti/mane?

Trenutno u firmi u kojoj radim koriste TortoiseSVN.

Ima svojih prednost i mana.

Ovakav im je modus operandi.

Najprije developer A koji radi na paketu X zaključa taj paket na svim okolinama (3 razvojne okoline dev, test, prod).

(mana: ako developer B drži lock, developer A mora ili čekati da dev B završi ili dogovoriti se na prepuštanje locka itd. Nema branchanja - postoji mogućnost naravno, ali je ne koriste).

Nakon locka, developer A može početi razvijati. Očekivano mjesto gdje developer razvija je IDE (SQL Developer ili PLSQL Developer). Nakon toga developer treba iskopirati svoje promjene u source control file (zapravo u tekstualnu datoteku). Nema direktno iz baze u source control. Napomena. Developer nema svoju razvojnu okolinu, nego je sve shared.

Tu fali ta dev okolina koju bi trebao svaki developer imati. Ali onda dolazimo do problema s podatcima i syncanjem istih (potrebno je imati podatke za kvalitetan tuning i optimizaciju).

I sve to ponoviti za svaku od 3 okoline.

Nakon što razvoj ode na produkciju, developer miče lock s paketa i onda može netko drugi raditi razvoj.

S grananjem i merganjem se omogućava da može više developer radit na istom paketu, ali zasad im je način rada ovakav.

Na "mojoj" bazi radi otprilike 50 developera.

Verzioniraju i fmb i xls datoteke.

Ima li boljih rješenja od ovog?

Hvala unaprijed na svim komentarima :)

Zato i istražujem malo koje su sve mogućnosti što se tiče source controla za DB.

Problem koji ja vidim kad svatko ima svoju okolinu su podatci (odnosno nedostatak istih).

Možeš imati svoj razvojni kod, ali ti fale podatci da bi mogao adekvatno testirati na local bazi.

Zato me i zanimaju rješenja koja imate u svojim firmama tako da možemo usporediti mane i prednosti.

Svjestan sam da postoji Gugl, ali eto htio sam i ovdje pokrenuti temu :)

P.S. Ne odlučujem ja o načinu kako će firma organizirati source control, ali istražujem druge mogućnosti.

Nema merganja u smislu da 2+ developera paralelno razvijaju na istom paketu, pa onda ubacuju svoje promjene i mergaju u glavnu granu.

Ovdje se radi po sljedećem principu. Developer 1 locka paket (to znači da nitko drugi ne može radit na tom paketu - odnosno ubacivat svoje promjene). Developer 2 može započeti svoj rad tek kad developer 1 završi.

Kad kažem završi, mislim kad razvoj od developera1 ode na produkciju (tu zna proći ohoho vremena).

Iz tog razloga kad developer 1 započne svoj razvoj, stavlja lock na paket (.bdy tekstualnu datoteku) u dev folderu, u test folderu, prod folderu.

Katastrofa za organizaciju/administraciju i totalno krivo korištenje source controla.

Evo iz prakse primjer...

U prosloj firmi svaki developer je imao svoju bazu. Kljucno je bilo da objekt na kojem planiras raditi imas u zadnjoj verziji. Npr od par tisuca stored procedura bitna ti je samo ona na kojoj ces raditi. Nakon sto si napravio i lokalno testirao izmjene - dodajes u header procedure datum, svoje ime i opis izmjene. Skriptu saljes db timu koji skriptu koju si poslao usporedjuje sa zadnjom verzijom koju oni imaju. Ako zadnja izmjena koju oni imaju odgovara onoj koja prethodi tvojoj u skripti koju si poslao - sve OK. Ako ne odgovara - znaci da si radio na starijoj verziji objekta. Ista stvar je sa view-ovima, funkcijama, triggerima...

Za tablice se slala alter skripta sa datumom, imenom developera i opisom zasto je promjena potrebna. 

Ne znam da li je db tim imao kod sebe nekakav source control (vjerujem da jesu). 

Na moje uporno inzistiranje napokon su nakon par mjeseci od mog dolaska svako jutro na jedan od shareanih diskova stavljali skripte koje su postavljali u glavnu bazu (baza koja je uvijek bila u sync-u sa softverom i u kojoj su bile ugradjene sve odobrene promjene). Znaci nisi morao nista puno misliti - ujutro samo uzmes .sql fajl i odvrtis ga na svojoj bazi. Onda znas da si na zadnjoj verziji.

Podaci su uvjetno receno nebitni.

@Friday. Sličan primjer koji si opisao sam imao u prošloj firmi. U timu svatko je imao svoju shemu, baza instalirana na serveru, pushali svako svoje promjene na SVN. Skriptom updejdali svoju shemu s novim stvarima. Milina.

Jedini nedostatak je taj da na svojoj shemi nije moguće istestirati performanse (karikiram: performanse joina s trilijun tablica). Te stvari su se mogle testirat samo pravim okolinama koje su pune podataka.

Možeš na dev okolinu, ali je tu većinom kaos. (stalno moraš paziti da li imaš zadnju verziju)

Ne možeš gurat na test okolinu jer bi ona trebala biti stabilna (pushanje novih stvari ide prije/poslije radnog vremena i u vrijeme ručka, to su neka standardna vremena).

Nemogu imat ovce i novce (nit to očekujem)

@ihush

ja sam samo mali developer, nisam release manager :)

Ovo kad kažeš "lokalna baza ne mora ni po čemu biti drugačija od glavne (kad spominješ podatke)". Misliš li na replikaciju podataka s recimo testne baze na lokalnu?

PS. Svjestan sam da sve ima i prednosti i mane. Ali tu ima pametnijih od mene, pa da vidim tuđa mišljenja, iskustva i preporuke. I hvala na tome.

-svaki posao je drugačiji-specifičan.. što reč, snalaženje u hodu. Jedino 'pravilo' za SVN koje je važno, KISS, što jednostavniji model, radi. Čim je nešto složenijeg, samo se nagomilavaju problemi, točno, ne idu i ovce i novce. Naravno, ako je izvedivo. Što veća firma, to je svaka promjena teža. Ako nešto nije u startu predviđeno.. ali to su samo floskule, jer neki fix-prijedlog, realno ne mogu dati. Za to moraš biti u konkretnoj situaciji.. sretno. :)