Wdrazanie aplikacji webowej - organizacja pracy

0

Jest sobie aplikacja webowa i zespol ok 10 programistow. W firmie jest SVN oraz jira. W jaki sposob organizowac prace programistow oraz wdrazanie aplikacji na serwer klienta? Od razu mowie, ze aplikacja nie jest wersjonowana, obecnie wszystko wpada do trunka.

Kazdy z programistow pisze jakis fragment funkcjonalnosci, caly modul lub poprawia blad. Nie raz zdarza sie, ze trzeba na szybko poprawic bug w jakims pliku oraz wdrozyc poprawke na serwer klienta. Jak zapewne sobie wyobrazacie, przy braku galezi w SVN, moze to byc problem (np. gdy dany plik jest juz rozgrzebany, bo dodajemy nowa funkcjonalnosc).

W niektorych firmach, kazdy programista pracuje na osobnej, wlasnej galezi. Po zakonczeniu pracy nastepuje mergowanie kodu z takiej galezi do trunka.

W innych natomiast taguja. Tzn. po kazdym commicie (dodaniu nowej funkcjonalnosci, poprawie buga) automatycznie tworzony jest tag.

Inne podejscie to praca jednoczesnie na branchu oraz trunku.

Jakie jest Wasze podejscie do tej sprawy? Jak to wyglada u Was, jak najprosciej rozwiazac sprawe wdrazania poprawek na serwerze klienta?

0

Gałąź dla każdego release dla klienta, w przypadku błędów poprawki dokonywane są na niej. Nowe funkcjonalności dodawane do gałęzi głównej, co jakiś czas poprawki z gałęzi klienckiego są wciągane do głównej. Dodatkowe gałęzie wg uznania (np. nową super funkcję, która wymaga zmiany w połowie klas w projekcie warto przeprowadzić w oddzielnym branchu).

0

Aplikacja nie jest wersjonowana. Czyli kazda nowa funkcjonalnosc laduje prosto na serwerze klienta. Rowniez poprawki. Czyli w tym przypadku bedzie trunk z kodem niestabilnym oraz jeden branch stable z kodem stabilnym, z ktorego to beda dokonywane uaktualnienia na serwerze produkcyjnym?

0

Po pierwsze primo - branche oraz tagi w SVN tylko tak sie nazywaja, tak naprawde sa zwyklymi kopiami z jakimis tam dodatkowymi metadanymi. Mergowanie w ogolnym przypadku nie dziala, sami programisci SVN sie przyznaja ze jest to trudne (dla ciekawskich, przeczytajcie uwaznie caly rozdzial o branchach i mergach w SVN red bean book) nawet w wersji 1.7. Nie dziwie sie ze nie macie galezi.
Po drugie primo - z SVN bardzo latwo jest zmigrowac na mercuriala (hg) / gita. Polecam mercuriala bo jest duzo latwiejszy na poczatek, lecz jesli sie nie boicie to sprobujcie oba (git ma duzo trudniejsza linie polecen, ale sam w sobie jest prosty).
Po takiej migracji wszelkie problemy z branchami i mergami odchodza w niepamiec.

Pozwoli to na bardzo proste zarzadzanie aplikacja.

Wersja gdy jest wielu klientow i maja rozne stany (skoro nie wersjonujecie ;d) aplikacji - np. biezace programowanie na masterze (git) / default (hg); nowe releasy zaczynaja nowe branche na ktorych robione sa bugfixy; nowe funkcjonalnosci to rowniez nowe branche. Zaimplementowanie nowego featuresa powoduje merge z master / default; bugfixy dodaje zmany na release branchach nie ditykajac nowych niegotowych featursow. Instalacja releasa z bugfixem nie wymusza rowniez instalacji nowych featuresow, o ktorych release branch po prostu nie ma pojecia. Bugfixy z releasow musza najczesciej sie dostac rowniez do default / mastera, co jest banalnym mergem / graftem (hg) / cherrypickiem (git) z releasa na default / master. Jesli bugfix jest potrzebny w kazdym releasie, szukacie najmlodszego wspieranego brancha z bugiem, robicie fix, mergujecie / graftujecie / cherrypickujecie (:D) to do nastepnego pod wzgledem wieku releasa, i tak dalej (to nie jest niezbedne, ale doswiadczenie mowi mi ze pozwala na latwe merge, gdyz z wersji na wersje zmiany sa dosc male i latwo sie polapac co zmienic), ostatecznie z najnowszego releasa idzie merge na default / master aby i tam byl fix. Bugfix backporty sa rownie proste.
W ten sposob macie w sumie niejawne proste wersjonowanie aplikacji, ale nie musicie tego uzywac. W sensie - po bugfixie mozecie zainstalowac wersje z tego samego release brancha z bugfixem (uzywacie wersji aplikacji) lub po prostu budujecie default / master po tym jak bugfix tam sie rowniez znalazl i instalujecie to. Nie uwazam tego drugiego za dobry pomysl.

Gdy macie tylko jednego klienta i chcecie zawsze mu dawac najnowsza wersje, po prostu olewacie release branche i robicie male bugfixy od razu na default / master, lub dla duzych osobne branche i jak gotowe robicie merge, po czym build i instalacja tego ostatniego kodu.Branche z nowymi featurami sa niezalezne i nie przeszkadzaja / nie rozgrzebuja kodu.

Jelsi jest duzo nowych featerow i sa dynamicznie rozwijane, i jest duzo bugfixow i sa czeste (zespol 10 programistow to juz cos), polecam w feature branchach robic raz na jakis czas (zalezy od dynamiki projektu - raz na dzien wieczorem, raz na 3 dni, raz na tydzien) robic merge z defaulta / mastera do feature brancha - zapobiegnie to pozniej trudnych mergy powrotnych, majacych na celu integracje feature z defaultem. Ale to tez zalezy czy inne featuresy maja byc wciagniete czy nie...

Dobra jest zasada - master / default, lub jakis dedykowany branch, np. stable, sa stabilne i zawsze dzialaja. Jak cos nie dziala (Jenkins sie wywalil) to caly zespol naprawia. Osobiscie nie uzywam za czesto dedykowanego stabilnego brancha, default (wole hg) najczesciej w zupelnosci wystarcza.

1 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0