[ anon315 @ 31.08.2007. 19:39 ] @
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] |