Kakav vam je development lifecycle, a metodologije?

Poštovana gospodo,

negde sam pročitao jednu jako pametnu rečenicu, ali je se ne sećam tačno, pa ću da parafraziram: "nije dovoljno da ste dobar programer, potrebno je da umete dobro da izvedete projekat". Drugim rečima, kvalitetno programiranje je samo podskup kvalitetno izvedenog projekta.

Imam zadatak da u JEE timu u kome se nalazim uvedem kompletan i profesionalan razvojni ciklus, infrastrukturu koja će to da podrži, standarde, metodologije i slične stvari.

Kako sam počeo istraživanje na tu temu, vrlo brzo mi se desilo da mi se TODO lista stvari koje treba da proučim znatno povećala, sa konstantnom tendencijom rasta. Naime, jedan TODO mi vuče još 5 TODO-ova. Tranzitivnim zavisnostima nikad kraja :)

U ovoj temi želim da vodimo kvalitetnu diskusiju na gore pomenute teme, da čujem od ljudi koji su ovu materiju već razradili ili se nalaze u timu u kome vlada ovakva profesionalna atmosfera, kakva su njihova iskustva, problemi itd.

Tema je dosta široka, ali mora odnekle da se počne.

Razvojni ciklus

Na sledeće dve slike se nalazi predlog tipičnog razvojnog ciklusa i kako se to odnosi na testiranje:





Development platforma

Ovo je mesto gde se kodiranje odvija. Sastoji se od programerske radne stanice. Komituje se nekoliko puta dnevno na odabrani SCM (ja sam odabrao SVN). Jednom kada se komituje, ostali mogu da koriste to što je komitovano. Međutim, bitno je da se komituje samo ono što radi. Zato je tipična strategija da se ovde odvijaju automatski unit testovi pre komita (Maven automatizacija, IDE...).
Ovde se odvijaju logički unit testovi (testovi koji se mogu obaviti u izolaciji od okruženja). Ovi testovi se izvršavaju veoma brzo kako bi se proverilo da izmenjeni kod ništa nije poremetio.

Integration platforma

Cilj ove platforme je da bilduje aplikaciju od njenih različitih delova (koju mogu biti razvijeni u različitim timovima) i da osigura da se svi oni uklapaju kako treba. Ovaj korak je od ektremnog značaja, jer se problemi jako često otkrivaju ovde. Takođe je jako bitno da ovaj proces hoćemo da automatizujemo. Ovaj princip se često naziva continuous integration (http://www.martinfowler.com/articles/continuousIntegration.html) i može se postići automatskim bildovanjem aplikacije kao dela bild procesa.
Na ovom mestu, posle automatskog bild procesa i deploy-a aplikacije, vrši se unit i funkcionalni testovi. Najčešće, samo podskup svih funkcionalnih testova se ovde izvršava, jer upoređujući sa ciljanom produkcionom platformom, ovo je prosta platforma gde fale elementi (na primer, fali konekcija ka eksternom sistemu kome se pristupa). Vreme ovde nije bitno, ceo proces može da traje i nekoliko sati, bez uticaja na development!

Acceptance/Stress test platforma

U zavisnosti od toga koliko je bogat projekat ovo može biti jedna ili dve platforme. Stress test platforma testira aplikaciju pod load-om i proverava da li ona skalira dobro (veličina, vreme odziva). Acceptance platforma je ona gde mušterija prihvata (sign off on) sistem. Veoma je preporučljivo da sistem bude deploy-ovan na acceptance platformu što je češće moguće, kako bi se dobio user feedback.
Na ovoj platformi je moguće izvršiti i dodatne funkcionalne testove, jer ova platforma jako liči na produkcionu.

(Pre-)production platforma

Poslednji stage pre produkcije. Opcioni je, mali projekti ga ne trebaju.
Dobra je navika da se na ovoj platformi izvršavaju i svi testovi kao i na acceptance platformi. Ovo je sanity check, kako bi smo proverili da je sve setup-ovano korektno.

Gore navedene slike i opis je nešto što se može naći u knjigama. Pre nego što krenemo dalje, ja bih voleo da čujem da li ima komentara na ovo do sada, da li ima neslaganja sa ovim gore, da li nešto fali, da li ima viška?

Ukoliko pretpostavimo da je ovo gore polazna tačka, treba definisati infrastrukturu koja će to da podrži. Kada ovo kažem, mislim i na HW i na SW. Nadalje sledi slika do koje sam došao i koja je u 0.0.1-alpha-SNAPSHOT fazi i vrlo je verovatno da krajnje rešenje neće biti blizu ovoga, ali kao što rekoh, od nečeg mora da se krene:



REPO platforma predstavlja repozitorijum koda (SVN) i repozitorijum artifakta (MAVEN). Predstavlja centralno mesto na kome se sliva intelektualna svojina – sors i gotovi artifakti. Pored ove glavne namene, na ovoj mašini se nalazi i Apache Httpd server sa WebDav ekstenzijom, radi publish-ovanja web sajtova i reporting-a artifakata, issue tracking softver (Bugzilla) i Jabber IM server (Continuum podržava takođe) itd.

Siva kockica predstavlja jednu mašinu.

Generalno, vidi se da se još precizno ne zna mnogo stvari. Ono što je fiksno i što znam da želim je: Maven kao build okruženje, SVN kao SCM, Continuum kao kontinualna integracija. I otprilike to je sve što znam za sada da je fiksno.

Da li slika ima smisla? Jel možemo da prokomentarišemo sve detalje sa ove slike, kao i sve nedostatke i viškove? Kockice i interakciju na slici. Budite kreativni :)

Na kraju, kakvu literaturu biste preporučili na ovu temu?

Metodologije

Kakve metodologije koristite? Favorit su agilne. Šta praktikujete, zašto? Šta mislite o Test Driven Development tehnici?

Mislim da je i previše za sada :)

V

_{[Ovu poruku je menjao Vanja Petreski dana 04.09.2007. u 00:02 GMT+1]}

Moj development lifecycle obuhvata dve velike udarnicke sezone, koje dele jedno letovanje i zimovanje. :)

Salu na stranu, evo kako je to organizovano u mojoj firmici. Mi radimo na ogromnoj aplikaciji za veliku firmu, pa nemamo tu privilegiju da radimo po agilnoj metodologiji - sta god da to bilo. Pretpostavljam da bi se agilno radilo na manjim projektima, ili bar u manjim timovma.
Obzirom da sam samo developer, nisam bas precizno upucena u sve formalne detalje celog procesa, ali mislim da mi razvijamo prvenstveno po nekom iterativno inkrementalnom modelu.
To znaci da imamo unapred zacrtane osnovne ciljeve i strategije razvoja za duzi vremenski period, ali bez detaljnih planova. Ovi ciljevi su onda podeljeni u "manje" celine ili projekte (sa sifrovanim imenima). To su "major" releases. Za svaki major se pravi dokumentacija sa osnovnim projektnim zahtevima koji se moraju zadovoljiti i deploymentom. Major release se distribuira krajnjim klijentima. Nakon prve verzije pravi se naravno i odredjen broj minor releasova, koji imaju dodatak manje bitnih poboljsanja, i mnogo bug fixinga, mada vrlo cesto upadnu i neke stvari koje nisu pristigle za major. Verovatno nije bas duhovito, ali moglo bi se reci da se bug fixing i manja poboljsanja rade agilno. :) Ali sve to u odredjenom zacrtanom roku, posle kojeg se popravljaju samo vrlo gadni bagovi.
Major verzije izlaze na godinu ili vise dana, a minor na svakih par meseci.
Svaki zvanicni release, major ili minor, se opet implementira u nekoliko internih inkrementalnih faza od po par nedelja , kada se pravi interni release. (Takozvani dedlajn :)) Tada se odvaja poseban branch na source repozitorijumu, i dalji razvoj se nastalja u osnovoj grrani. Code freeze se predaje na testiranje test timu, koji onda intenzivno radi na njemu. U taj branch posle idu samo gadni bagovi zbog kojih testeri ne mogu da rade, kako im ne bi izmakli oni sitniji.
Mislim da samo poslednji interni release pred sam zvanicni release prolazi i acceptance i stress testove.

I da stvari budu jos komplikovanije, postoji nesto i sto se zove promotion process. Promocija je labelovanje koda sa unapred definisanom labelom. Tek kada se interno zaista zavrsi i istestira neka manja celina kod se promovise, odnosno labeluje tom labelicom. Nas continuous integration ne bilduje poslednju najnoviju verziju koda, nego onu koja je labelovana kao promoted.
Obzirom da se development radi na kontinuirano integrisanom sistemu, na ovaj nacin se nece desiti da jedan developer ne moze da radi zbog toga sto je neki tim zapoceo a nije zavrsio neku vecu izmenu, pa aplikacija ne moze ni da se startuje, sto je ranije bio problem. Ili da bild konstantno pada. Ili da ne sme da se komituje kod na kome radi vise ljudi dok svi ne zavrse da bild ne bi pao.
Deo tog procesa je i compliance build - provera da li se ceo sistem kompajlira sa izmenom koju treba promovisati.

Sto se tice junit testova, nekada davno smo imali viziju da ce sve biti lepo junit istestirano. To nikad nije zazivelo, prvenstveno zbog toga sto svaki modul zavisi od drugih modula koje je prilicno tesko mockovati, tj nemoguce je izvrsiti izolaciju. Desava se da je nekada zaista neophodno mockovati neki drugi modul, jer je inace nemoguce utvrditi da li kod uopste radi to sto treba da radi i to zna da bude ceo mali projekat, koji bi i sam mogao da se testira, i tako ukrug.
I dalje pravimo unit testove koliko god je moguce, i svako dodatno vreme iskoristimo da ih poboljsavamo. Ali se ne pokrecu prilikom bildovanja.
Jos jedna nevolja sa unit testovima je i da cak i male ispravke koda zahtevaju ispravke gomile unit testova.
Tipa, izbacis property iz neke klase, i u celom kodu samo jedan metod koristi taj property, ali zato 10 unit testova. Uzas. Test driven? Nop.

Ono sto si zaboravio da napomenes su code reviews i staticka analiza.
I oni su obavezan deo procesa, i kod nas ih se zaista pridrzavamo. Kada se izdizajnira neki projekat ili resenje, prvo se radi design review, od po pola sata sat, koji je zaista koristan. Analogno tome, kada se implementira organizuje se malo duzi code review, gde se propisno pregleda kod. Posle toga ide i refactoring - poboljsavanje i ciscenje koda. Bez refactoringa se nagomilava svasta po kodu, tako da bih ga ja planski organizovala jos cesce.

Sve ove procedure su jos rigidnije i formalnije, ali se u praxi prilicno fleksibilno primenjuju - npr rokovi se stalno pomeraju :).
Proces nije savrsen i postoji dosta overheada da bi se ispostovale neke procedure, ali ipak funkcionise, sto zna da bude zadivljujuce kada se uzme u obzir koliki sistem je u pitanju i koliko razlicitih modula se uklapa u jedinstvenu aplikaciju.

Eto..

---