|
Razvoj i deployment vs. kastomizacije
Do sad sam se trudio da uvek imam (manje-vise) istu verziju koda instaliranu kod svih klijenata, tako da uvek postoji samo jedan trunk na kome se rade sve izmene. Medjutim sad sam dobio ponudu za instalaciju aplikacije, ali uz veliku dozu kastomizacija. Razlike ce biti mozda u manje od 10% koda, ali ukljucujuci i neke core klase i dosta modula, znaci sa trenutnom arhitekturom nemam nacina da ih odvojim od ostatka koda. Taj isti app je instaliran kod jos 3 firme i razvija se polako, ali stalno, fixaju se bagovi, dodaju sitna poboljsanja, znaci svakog meseca ima nekih sitnih izmena.
Do sad je sve naprrosto bilo po svn-om i to je bilo dovoljno, na trunku razvoj, cim se to istestira izmena se pushuje prvo jednom klijentu, pa onda ako se nista ne zapali i ostalima. Sad se postavlja pitanje kako organizovati dalji razvoj tako da sto bezbolnije mozemo da upgrejdujemo svima app, fixamo bagove i sl., a da pri tome postoje (bar) 2 razlicite verzije koda i naravno da ne mora rucno da se radi merge svaki put.. Jel imate neki predlog? Kako vi to resavate? |
Šta fali ručnom mergeu jednom u par meseci? Koji procenat mergea SVN ne bi uspeo da razreši sam?
|
Možda bi pomoglo da si dao malo detalja o samoj aplikaciji, složenost, broj ljudi, platforma...
Različite verzije projekta za različite klijente kad tad doneće probleme. Najbolje je napraviti neki mehanizam podešavanja/plaginova, ukoliko imate dovoljan budžet ili planirate da dalje širite klijentelu... Za projekat neke normalne veličine, da kažem sa jednocifrenim brojem ljudi, je ok imati stable/release verziju i razvojnu, gde je ok ispraviti bug u stable verziji dok se radi na razvoju nove verzije, naravno sve sa idejom da se verzije merdžuju. Sve preko toga značajno komplikuje razvojni ciklus. |
Ramzmislite o prelasku sa SVN-a na Git ili Mercurial. Znacajno olaksava merge narocito u ovakvim situacijama.
|
Mislim da nemas nekog izbora pretjeranog osim ovog sto kaze BraMom odnosno podesavanja tj kreiranja opcija za mnogo toga.
Nisam koristio niti GIT ili Mercurial u razvoju pa da ih poznajem ali ne mogu ni logicki dokuciti kako ako imas u jednoj verziji a=1, a u drugoj a=2, kako bilo koji sistem moze znati sta je od toga 'ispravno'. tj interesuje me da li tako nesto postoji. |
ne moze naravno, moracu da razbijem sve u glavne fajlove i fajlove sa izmenama.
|
Citat:
Inače problem između toga da li je tačno a=1 ili a=2 će da reše testovi. Znači kada se odradi merge, mogu da se poteraju testovi i ako pukne negde, onda moraš ručno da vidiš šta je problem. Ivane, kako ti to imaš organizovano? Imaš trunk gde držiš current i... šta još imaš? Imaš neku brančicu? :-) |
Trenutno imam samo trunk, i par tagova za neke prethodne verzije... za sad je jos sve jedna linija razvoja, nije jos krenula kastomizacija.
Trenutno mislim da su mi svn Externals najbolje resenje, razbicu kod na vise delova pod svn-om(core klase, moduli, templejti), pa cu da ih linkujem kao external checkouts za svaki projekat posebno... moracu samo malo da pretumbam putanje i organizaciju... |
| Vreme je GMT +2. Trenutno vreme je 17:36. |
Powered by vBulletin® Verzija 3.6.8
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright © DevProTalk. All Rights Reserved.