Podrška #25435
Zatvoren
agilni release management
Dodano od Ernad Husremović prije oko 13 godina. Izmjenjeno prije oko 13 godina.
100%
Povezani tiketi 2 (0 otvoreno — 2 zatvorenih)
Izmjenjeno od Ernad Husremović prije oko 13 godina
Toko to mora biti ?!¶
kada su kolege uočile da stalno "pushiram" izbacivanje F18 kod korisnika prokomentarisali su:
Uh kad to počne kod korisnika "frcati"
ukazujući da je prerano da se aplikacija na teren izbaci da puno toga ima za testirati.
Međutim, mi za to nemamo vremena. Ako otegnemo sa F18 gubimo korak sa dinamikom P1, M3 a to je najveći rizik za projekat.
Zato F18 mora izaći kod bring.out i ostalih korisnika što prije. Očigledno, znatno ranije nego li to kolege smatraju realnim u smislu spremnosti aplikacije.
Izmjenjeno od Ernad Husremović prije oko 13 godina
Međutim, ovaj ticket se neće baviti rokom i vremenom za knowhow nego onom što sam iz gornjih navoda kolega uočio:
oni su vođeni dosadašnjim načinom razvoja i realease strategijom FMK.
F18 kao podprojekat knowhow ERP, iako nasljeđuje legacy FMK kod NIJE FMK. Ono treba i može unijeti novu vrijednost kako za korisnike tako i za bring.out kao provajdera.
naš način razvoja se već sada značajno promjenio, ali to je samo početak.
Ovdje ću pričati o release strategiji
Izmjenjeno od Ernad Husremović prije oko 13 godina
automatsko update od strane novog klijenta - customer wise¶
otvorena google code download sekcija nam otvaran mnoge nove mogućnosti
moguće je da klijent sam obavi posao update-a čitajući manifest update:
MANIFEST_UPDATE.txt
0.9.0 0.9.0p1 ramag 0.9.0 0.9.1 all
na osnovu ovog update-a će korisnici organizacije "ramag" koji imaju verziju 0.9.0 update-ovati verziju 0.9.0p1 dok će svi ostali sa verzije 0.9.0 izvršiti update na verziju 0.9.1
ovaj jednostavni algoritam omogućiće nam automatski, customer-wise upgrade
Izmjenjeno od Ernad Husremović prije oko 13 godina
Brzi patch¶
Gore pomenuti primjer 0.9.0z je primjer onoga što se često u praksi dešava.
Bug se pojavi za specifičnog klijenta, dok za druge određena verzija ne predstavlja problem. git/gihub nam omogućava da se prave posebni branch-ovi unutar kojih će se razvijati patch verzije.
Mergiranje patch-eva u standardne verzije¶
Kada se naprave detaljnije analize patch branchovi se mergiraju u glavni branch i izdaje u gornjem primjeru (ver 0.9.2 koja je prihvatljiva za sve korisnike) ili se odbacuju
Izmjenjeno od Ernad Husremović prije oko 13 godina
database_version¶
trenutna verzija baze treba biti sinhronizirana sa klijentom. modifikacije struktura dbf-ova i serverske baze moraju biti prepoznate od strane klijenta.
sa F18 jednostavan remote adminin pristup svakoj bazi putem VPN-a. znači da naš admin može izvršiti administrativne opcije baze koje nije poželjno vršiti od strane klijenta.
database admin paket sa sql alter skriptama pokreće admin iz bring.out, taj paket vrši upgrade data_base vrersion-a nakon čega je F18 klijent sinhroniziran i sa verzijom baze.
Sve dok se to ne obezbjedi F18 klijent prijavljuje "client version 0.9.0z nije kompatibilan sa database version 0.9.0"
to smo vidjeli u xtuple-u i to je dobar fol. "sekunda posla" nam je to staviti i u F18 logiku.
Izmjenjeno od Ernad Husremović prije oko 13 godina
modstru dbf-ova¶
sa F18 dbf-ovi u najvećoj mjeri predstavljaju keš podataka i nemaju vitalnu važnost.
neke upgrade stvari možemo realizovati brisi dbf/kreiraj novi sa novom strukturuom.
na drugim mjestima možemo upotrijebiti modstru koju već imamo ali bez eksternih .chs-ova. to nam više ne treba.
treba napraviti upgrade funkciju upgrade(old_version, new_version)
koja će u sebi sadržavati logiku zamjene sa starije na noviju verziju.
naravno kada treba napraviti skok od više verzija to se vrši inkrementalno dok se ne dođe do tekuće verzije.
Izmjenjeno od Ernad Husremović prije oko 13 godina
šta će raditi serviseri ?!¶
kada ovaj sistem stavimo u funkciju masa servisnih operacija prenosi se na područje kvalitetnijeg razvoja.
kada se ovaj sistem uhoda, korisnik neće ni znati da se desio upgrade verzije.
A serviser ? Serviser treba raditi pamentije poslove. Ostaće mu vremena da korisnicima da dodatnu obuku, napravi novu instalaciju aplikacije. Da radi profitabilne poslove.
Izmjenjeno od Ernad Husremović prije oko 13 godina
Agilni release management traži vrijeme¶
Traži.
Ali ga sada možemo bez ikakvih problem realizovati. S obzirom da izvršene pripreme i tehničku infrastrukturu F18 on postaje realna opcija.
U slučaju FMK ovakvo šta je moglo biti samo san.
Treba uočiti da je činjenica da se knowhow ERP/F18 razvoja kao opensource software ovu stvar olakšava i značajno pojeftinjuje.
"google code" hostira samo opensource projekte.
Izmjenjeno od Ernad Husremović prije oko 13 godina
[1:38pm] hernad: bjasko zato sam i rekao vsasa da svaki novi build evidentira [1:38pm] bjasko: dobro onda sale setuj 0.96 za novi build [1:38pm] hernad: da se prije njega update-uju verzije [1:39pm] hernad: 0.9.6 [1:39pm] hernad: a može se stavljati i 0.9.6b [1:39pm] hernad: 0.9.6b [1:39pm] hernad: iako ne treba [1:39pm] hernad: imaš do 0.9.99 ići ako želiš [1:40pm] hernad: al valjda ćemo prije doći do 1.0.0 [1:40pm] hernad: postoje li na google code neki alati da se radi sa komandne linije put bjasko ? [1:41pm] hernad: ubijeđen sam da postoje [1:41pm] bjasko: moguće [1:41pm] bjasko: nisam setime bavio [1:41pm] hernad: onda bi u ./build_release.sh mogao pushirati nver automatski [1:42pm] hernad: i čitava ova priča o release-u bi se svala na minut posla i to developera [1:42pm] hernad: možeš se kutarisati tog posla skroz [1:43pm] hernad: šta je http://code.google.com/p/knowhow-erp-f18/downloads/list [1:43pm] hernad: F18_0.9.5.tar.gz ? [1:43pm] bjasko: to je samo binary [1:44pm] hernad: čega ? [1:44pm] bjasko: F18 [1:44pm] hernad: koji OS ? [1:44pm] hernad: ne valja to briši [1:44pm] bjasko: linux [1:44pm] hernad: ne valja ti uopšte numeracija [1:44pm] hernad: nisi je dobro osmislio [1:44pm] hernad: pardon [1:44pm] hernad: imenovanje [1:45pm] bjasko: mislim da je to najlakše izmjeniti [1:45pm] hernad: ja mislim da je to potrebno ODMAH riješiti kako treba [1:45pm] hernad: i VRLO bitno odmah riješiti [1:45pm] hernad: jer se svaka promjena povlači promjenu update.bat, update.sh [1:46pm] bjasko: to je meni jasno daj kako želiš i da setujem [1:46pm] hernad: daj ti [1:46pm] hernad: ja sam dao okvire [1:46pm] hernad: u tim okvira se sjećam da sam rekao da treba postojati _3rd_party ... [1:46pm] hernad: ne mislim se ponavljavati [1:46pm] hernad: prati te okvire [1:47pm] hernad: u _3rd_ party stavi sed, grep, bz2, tar [1:47pm] hernad: gzip ... tako da svaki os može otpakovati tar.bz2 recimo [1:47pm] bjasko: sada odmah ? [1:48pm] hernad: napamet sigurno ovako ozbiljne zadatke ne možemo rješavati zato sam i otvarao tickete [1:48pm] hernad: ali vidim da ova download lista ne valja [1:48pm] hernad: za to ne moram gledati ticket [1:49pm] hernad: bjasko ovo o čemu pričam su glavni ciljevi tvog zadatka [1:51pm] bjasko: onda idem da čitam dok to ne skontam [1:51pm] hernad: ovo u temelju pogrešno radiš, očigledno je - F18_0.9.5.tar.gz za ubuntu binary a za windows F18_0.9.5.zip možda ? to se tako ne radi. [1:52pm] hernad: ali svakako sam to napisao tako da nema smisla da to radiš onako ofrlje
ne razumijem. pa ne misle valjda kolege da pišem razonode. radi.
nakon što sam vidio da je google code download sekciija "ni-našta-nalik" bjasko govori kako će sada uzeti i pročitati dok ne razumije ?!
Izmjenjeno od Ernad Husremović prije oko 13 godina
- Status promijenjeno iz Dodijeljeno u Zatvoreno
- % završeno promijenjeno iz 0 u 100
sinoć smo došli do prvih konkretnih rezultata na ovu temu windows F18 install. ovo jeste gruba da grublja verzija ne može biti ali se može skontati "šta je pisac htio reći"
uočio sam da to kolege nisu mogle razumjeti bez mog pushiranja i direktne intervencije: ovo je bitno - ovo trebamo započeti sada a ne nekada.