|
Web aplikacije, web servisi i software Frameworks, web servisi, programi, plugin-ovi, ekstenzije korisni za razvoj web sajtova. Sponzor: |
|
Alati teme | Način prikaza |
16. 05. 2011. | #1 |
Ivan Dilber
Sir Write-a-Lot
|
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?
__________________
Leadership is the art of getting people to want to do what you know must be done. |
16. 05. 2011. | #3 |
Branimir Momcilovic
Qualified
Datum učlanjenja: 15.02.2006
Lokacija: Beograd
Poruke: 167
Hvala: 47
25 "Hvala" u 8 poruka
|
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.
__________________
Važnije je biti ljubazan, nego biti u pravu. |
16. 05. 2011. | #5 |
majstor
Wrote a book
|
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.
__________________
|
16. 05. 2011. | #6 |
Ivan Dilber
Sir Write-a-Lot
|
ne moze naravno, moracu da razbijem sve u glavne fajlove i fajlove sa izmenama.
__________________
Leadership is the art of getting people to want to do what you know must be done. |
17. 05. 2011. | #7 | |
I'm a PC too.
Wrote a book
Datum učlanjenja: 06.06.2005
Lokacija: Kanada
Poruke: 1.354
Hvala: 82
130 "Hvala" u 89 poruka
|
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? :-)
__________________
Commercial-Free !!! |
|
17. 05. 2011. | #8 |
Ivan Dilber
Sir Write-a-Lot
|
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...
__________________
Leadership is the art of getting people to want to do what you know must be done. |
|
|