2010 september Ivo Mägi ivo ät webmedia dot ee

Transcription

1 2010 september Ivo Mägi ivo ät webmedia dot ee

2 Miks see loeng? Te olete ju kõik tarkvara tootnud. Minu fiktsioon kuidas see käis: Saame õhtul enne tähtaega kokku Võtame kaasa hunniku pitsat ja kokat... ja programmeerime öö läbi Probleemid Koodi kokku panek Stabiliseerimine Töö kvaliteet Vastavus eesmärkidele Tehniliste probleemide tekkides ülesande üle jõu käimine...

3 Miks nii juhtus? Sest te olete tegelenud peamiselt häkkimisega Kindlasti tegin ma mõnele auditooriumis liiga, palun vabandust Teen siiski eelduse et enamik teist ei ole kokku puutunud professionaalse tarkvara tootmisega suurtes meeskondades Vaatamegi täna kuidas selles* meeskonnas ellu jääda *=5-20 inimest, suuremate osas on mu jutt paraku teoreetiline...

4 Kuidas üldse saada arendajaks? Kuidas saadakse suusahüppajaks? Treenitakse Ja keegi ei hüppa alguses 120m mäelt Kuidas tisleriks? Harjutatakse Ja mis te arvate mis on tislerite põhiline tööriist? Kuidas arendajaks? Harjutatakse! Ja kas kohe peab kõiki mustreid ning raamistikke teadma?

5 Kuidas saada paremaks arendajaks? Tunne hästi oma töövahendite võimalusi Loe ja kasuta: Teiste koodi Raamatuid Artikleid Foorumeid Uusi tehnoloogiaid/keeli Suhtle

6 Mis on mu töövahendid Tänases loengus räägime vahenditest Editor/IDE Ehitusskriptid Versioonihaldustarkvara Veahaldustarkvara Testid Aga vähemalt sama tähtis on ka oskus kasutada Informatsiooni (APId, foorumid, google...) Kaastöötajaid

7 Editor vs IDE Kirjutamine Lugemine Kursori liigutamine Teksti selekteerimine Kopeerimine - kleepimine Ekraani kerimine Teksti otsing... Navigeerimine Koodi genereerimine Kompileerimine Valideerimine Refaktoreerimine Testimine Debugging Visualiseerimine Versioonihaldus...

8 Editor vs IDE: demo Vaatame praktikas järgi kuidas see siis välja näeb API kasutus Kompileerimine Debugging Refactoring Kiirus Loetavus

9 Tes>mine Aga selleks on ju testijad? Vale suhtumine, esmase valideerimise ja verifitseerimise teostab arendaja Milliseid teste kirjutab arendaja Ühiktestid Koormustestid Migratsioonitestid Installatsioonitestid...

10 Ühiktes>d Kasutatakse ühe isoleeritud koodiühiku testimiseks Milleks kasulikud? Automatiseeritavus Korratavus Kiirus Võivad näidata et kirjutatud kood töötab ebakorrektselt Ei suuda näidata et kirjutatud kood töötab korrektselt Väga head abilised refaktoreerimisel

11 Ühiktes>d: millega tes>takse? Sõltub platvormist, oskan ise näiteid tuua Java- maailma keskselt Java koodi testimiseks: Junit, TestNG Kasutajaliidese testimiseks: Selenium

12 Ehitamine Milleks ehitatakse? Mugavus/kiirus Automatiseeritavus Korratavus Vigade vältimine Millega ehitatakse? Shelli skriptid Make Ant Maven IDEs... Mida ehitamise käigus tehakse? Kompileerimine Käivitamine Koodi genereerimine Andmebaasiskriptid Automaatne testimine Nightly builds JSP precompile Sõltuvuste majandamine

13 Ehitamine - näide

14 Versioonihaldus Milleks versioonihaldus? Meeskonnatöö võimaldamine Ajaloo säilitamine Versioonide haldus

15 Versioonihaldus - näide

16 Tööülesannete haldus Mis üldse on tööülesanne? Milleks neid hallata? Inimfaktor Iga inimene suudab meeles hoida korraga kolm asja Suurtes projektide raames täidab arendaja aasta jooksul tuhandeid erinevaid ülesandeid Väljalasete haldus Mis vead selles versioonis parandatud said? Mis tööd peavad mul veel tehtud olema et see versioon oleks toodangukõlbulik? Mis uut funktsionaalsust saab klient versiooniuuendusega kasutada?

17 Tööülesannete haldus Millega tööülesandeid hallata? Trac Mantis Bugzilla Changelogic Näide

18 Konfiguratsioonihalduse definitsioon The process of identifying and defining the Configuration Items in a system, recording and reporting the status of Configuration Items and Requests For Change, and verifying the completeness and correctness of Configuration Items.

19 Aga see definitsioon ajab ala> inimesed peast segi...

20 Seega - millest selles teemas juhu tuleb? Klassikaline tarkvaratehnika kursus käsitleb tarkvara tootmist hetkeni kui toode valmis saab Reaalses elus jätkub aga tõsine töö: Lõppkasutajad soovivad süsteemi muudatusi ja täiendusi mida arenduse faasis ette ei nähtud Muudatused ümbritsevas maailmas tingivad muudatusi süsteemi Muidugi kahel juhul õnnestub teil hoolduse faasist pääseda. Millistel juhtudel? Ja valdav enamik edasisest on relevantne ka enne rakenduse valmimist.

21 Et siis millest ikkagi juhu tuleb? Millest koosneb väljalaskeprotssess (i.k. releasing) Kes on release engineer ja mida ta teeb?

22 Millest reliisimine koosneb? Otsustamine mis reliisi kuulub Pigem projektijuhtimise distsipliinist? Lähtekoodist kindla versiooni kasutus Mäletate versioonihaldust? Rakenduse konfigureerimine Misasja? Rakenduse ehitamine Mäletate ehitusskripte? Rakenduse paigaldamine Kas see ei ole pigem mitte halduse pärusmaa? Muudatuste logi koostamine Mäletate tööülesannete haldust?

23 Mis sellesse reliisi kuulub?

24 Mille põhjal otsustada? Tööde nimekiri Kliendi tagasiside Automaatne vigade raporteerimine Hääletusmehhanism Feature creep?

25 Mis vormis otsustada Reliisime siis kui featuurid X. Y ja Z on implementeeritud ja stabiliseeritud versus Reliisime iga kuu esimesel reedel

26 Kuidas tagada et me reliisime just selle koodi mis on stabiliseeritud?

27 Versiooneerimine: vahendid Tsentraalsed mudelid Vabad vahendid CVS vana kuid väga levinud SVN uus ja parem CVS Kommertsvahendid: Microsoft TFS, IBM ClearCase, Perforce,... Hajusad Git Mercurial Darcs

28 Versioneerimine: operatsioonid Checkout Commit Update Merge Conflict Add

29 Keskne / jaotatud mudel Keskse repositooriumi kasutus: enamlevinud kommertsmaailmas Hajutatud repositoorium: plussid ja miinused? Hajusate repositooriumite näited Git Darcs Bitkeeper

30 Märgendamine (i.k. tagging) Tag- i abil märgitakse üks konkreetne versioon failide komplektist Näited: Release mingi konkreetse väljalaske märgendamine et seda saaks hiljem reprodutseerida Before refactoring X suuremahulise refaktoreerimiseelse seisu fikseerimiseks Branchpoint X mingi kindla haru eraldamisele eelnenud seis Soovitav on märgendada alati kogu repositoorium

31 Harundus (i.k branching) Branch luuakse repositooriumist mingi haru eraldamiseks. Näiteks: Arendajate isoleerimiseks üksteisest Toodangus oleva versiooni toetamiseks (paralleelselt uue arendusega) Eksperimenteerimiseks Staging mudeli kasutamiseks: kood propageeritakse stabiilsest harust vähem stabiilse(te)sse Mis on harumudeli kasutamise negatiivseks aspektiks?

32 Branching: väljalasete juh>misel Erinevad võimalused Harumudelit ei kasutada, koodibaas külmutatakse stabiliseerimiseks Eraldatakse haru väljalaske tekkimisel Integreeritakse pidevalt

33 Branching: koodi külmutamine

34 Branching: haru eraldamine

35 Branching: pidev integreerimine

36

37 Miks konfigureerida? Erinevused keskkondade vahel Arendus vs test vs toodang ärirakenduste puhul Toodangukeskkondade erinevus desktop rakendustel Erinevad litsentsitingimused (basic vs enterprise)...

38 Rakenduse konfigureerimine Millal konfigureerida? Koodi tasemel (branching)? Ehitamise ajal? Paigalduse ajal? Rakenduse töö ajal?

39 Konfigureerimine koodi tasemel Millal kasutada? Erinev riistvara/os Erinevad paketid (basic / standard / enterprise) Mida silmas pidada: Vähene läbipaistvus Maksimeeri ühisosa vastasel juhul on lihtsam teha eraldi projektid

40 Konfigureerimine ehitamise ajal Millal kasutada Erinevad platvormid Erinevad keskkonnad (arendus / test / toodang) Mida silmas pidada Läbipaistvus on parem kui koodi tasemel branchides Võib saastada koodi või ehitusprotsessi (#IFDEF konstruktsioonid C koodis?)

41 Konfig. paigalduse ja töö ajal Mida konfigureerida? Andmeallikad Rakenduse keelsus / lokaalsus Väliste liideste spetsiifika Mida silmas pidada? Paigaldusprotsessi konfigureerimine ei ole tihti kaasatud versioonihaldusesse minimaalselt peab olema kaasatud protsessi tasemel Konfiguratsiooniga liialdamine

42

43 Ehitamine väljalaskeprotsessis Konfiguratsioon ehitamise ajal Sõltuvuste haldus Integreeritus paigaldusprotsessi

44 Sõltuvuste haldus Sõltuvused erinevatest välistest teekidest (DLL, ZIP, JAR, RPM,...) Kuidas hallata? lib/- kataloog rakenduse lähtekoodi repositooriumis? Kasutada vahendeid Maven, Ivy Millal millist lähenemist kasutada?

45 Nightly builds Regulaarsus Ei tohi koosneda ainult rakenduse kokku ehitamisest Paigalduse testimine Funktsionaalsete testide käivitamine Jõudlustestide käivitamine Koodianalüsaatorite käivitamine Meetrika kogumine Mida kasutada? Hudson CruiseControl Atlassian Bamboo... Näide

46

47 Probleemid mis tuleb lahendada Kuidas käitutakse versioonivahetuse ajal Rakenduse töö seiskamine? Kasutajate migreerimine uuele platvormile Koheselt? Vanad kasutajad aeguvad vanal versioonil? Kuidas uuendatakse väliseid ressursse? Andmebaas LDAP Failisüsteem...

48

49 Mis rakenduses uue versiooniga muutunud on? Läbipaistvus lõppkasutajale / tellijale Automaatselt genereeritav tööülesannete halduse ja versioonihalduse integratsioonist Automaatne = integreeritud rakenduse ehitusskriptidesse või paigaldusse Eraldatud sisemised tööülesanded ning lõppkasutajale mõistetav funktsionaalsus

50 Aitäh!

51 Viited One book to rule them all: Andrew Hunt, David Thomas The Pragmatic Programmer: From Journeyman to Master, 1999, Addison- Wesley