Klávesové zkratky na tomto webu - rozšířené Na obsah stránky

Vývojová infrastruktura

09.40 - 14. září 2008 | Moje práce

Na začátku vývoje každého produktu bychom si měli připravit vhodnou infrastrukturu. Základem je verzovací systém – pokud pracujete sám, je značnou výhodou, v teamu nezbytností. Další důležitou součásti je systém pro vedení úkolů a bugů. Dále je vhodná wiki a taky nějaký buildserver.

Proč je to tak důležité?

Verzovací systém je vhodný na jakýkoli projekt, nemusí to nutně být ani projekt softwarový – my ho třeba s Borkem používáme na přípravu přednášky. Je to ochrana před ztrátou dat, občas pomůže se podívat do historie, dnešní systémy umějí mergovat změny z více zdrojů a jsou snadno zařaditelné do automatizovaného procesu.

Úkolník je dobrý z mnoha důvodů, vidíte, co máte dělat, jakou to má prioritu, kolik už máte hotovo. Slouží i jako váš výkaz, že se jen neflákáte. ;)

Build server je už jen třešničkou na dortu, která za vás dělá rutinu – špinavou a nudnou práci.

Jak to bylo v Atlase

Když jsem nastupoval do vývoje Atlas.cz, fungoval tam jen Visual SourceSafe, stagovalo se přes FTP. Vše bylo dost závislé na správném připravení verze do produkčního prostředí, to připravoval člověk a snadno mohlo dojít k chybě. :) Za nějaký čas jsme se rozhodovali jak to celé zautomatizovat a usnadnit. Nakonec jsme přešli na PureCM, Atlas.Build a Atlas.Autowebsite.

PureCM je verzovací systém s integrovaným úkolníkem a s možností skriptování v pythonu a dotnetím API. Má systém repository, které mají streamy a ty lze vzájemně mergovat v rámci hierarchie. Také k nim lze dopsat tzv. Custom action. Ta u nás nebyla nic jiného než spoušť události. Služba Atlas.Build tuto událost zachytila, provedla checkout, pročistila projekt a podle jednoduchého build skriptu (zjednodušený NAnt) připravila verzi buďto na dev servery nebo na staging, kterou pak nahrála na příslušný server pod danou verzí (názvem streamu).

Vývojář pak zadal do prohlížeče adresu, třeba http://katalog.3.6.0.dev2.atlas.cz, kde na něj čekal Autowebsite, který se zeptal jakou verzi frameworku použít a pak v IIS metabázi založil nový web.

Bylo za tím spousta magie a bylo celkem jednoduché a efektní a taky ušité na míru našim potřebám.

Jak to máme v Twaregu

Když jsme přišli do Twaregu, bylo opět potřeba připravit infrastrukturu. Po týdnu zkoušení a rozhodování jsme nakonec zvolili kombinaci Subversion (SVN), Trac, TeamCity.

SVN je celkem osvědčený verzovací sytém, je zdarma a multiplatformní, existuje pro něj dostatek nástrojů, včetně integrace do Visual Studia a je podporován všemi testovanými buildservery.

Trac je wiki a systém pro vedení úkolů s pěkným webovým prohlížečem repository. S SVN je spjat pupeční šňůrou a dá se dobře automatizovat tvorba nových projektů. Navíc je to OpenSource a je zdarma.

TeamCity je skvělý buildserver podporující Javu i dotnet (nejen tyto), umí se připojit do SVN a zvládá i vzdálené předtestované commity, což je killer feature. Pokud se dokážete smířit s omezením na 3 build agenty, 20 uživatelů a 20 konfigurací, pak je zdarma. Má pěknou integraci do Visual Studia a má API pro rozšiřování.

První měsíc v Twaregu jsem (nejen) připravoval infrastrukturu. Napsal jsem službu, která zakládá nové repository, připraví do nich základní adresářovou strukturu a založí projekt v tracku. Automatizované zakládání pro TeamCity zatím není a ještě nevím, jestli je potřeba. Jednotlivé konfigurace je lepší projít ručně a nastavit dle požadavků daného projektu. Na projektu většinou máme dvě konfigurace, jednu, která je pro vzdálený předtestovaný commit do vývojového branche a druhou, která se spouští při commitu do trunku. Provede se kompletní build, spustí se testy, pokud je vše ok, vytvoří se dokumentace a nahraje na intranet, provede se deploy knihoven do společného úložiště a vytvoří se weby, pokud nějaké v projektu jsou.

Co se všechno má udělat je řízeno MSBuild skriptem, pro který jsem připravil několik tasků. Upravil jsem xUnit.net task, aby se posílaly zprávy do TeamCity a přibalily výsledky testů do sumáře o buildu.

Je fakt, že tady máme build skripty mnohem ukecanější něž v Atlasu, ale jsou mnohem flexibilnější – vzhledem k heterogennímu prostředí je to potřeba.

Závěr

Investujete-li na začátku nějaký čas na vybudování infrastruktury, jistě se vám to vrátí později v podobě nevytrhaných vlasů a neokousaných nehtů, když někdo někomu omylem přemázne celodenní práci nebo vydeployuje nefunkční verzi. Nemít verzovací systém je vyložený hazard, nemít úkolník je přinejmenším nepohodlné a bez build serveru se dá žít…

A jakou infrastrukturu/sys­tém používáte vy?

Autor: Aleš Roubíček | Web feed s komentáři | Přidej komentář | del.icio.us | Linkuj!

Komentáře

  1.  

    Michal

    12.30 - 14. září 2008 | #

    My pouzivame na vsechny vlastni i zakaznicke projekty klasiku SVN, CruiseControl, Gemini a Wiki.

    Nejslabsi cast je CruiseControl, uz me hodne stve a moc se mi to prepisovat nechce. Uz drive jsem chtel kouknout na TeamCity, ale asi jsi to urychlil :-)

    Nechapu jen ty „vzdálené předtestované commity“. O co jde?

     
  2.  

    Michal

    12.35 - 14. září 2008 | #

    jeste otazky k „vzdálenym předtestovanym commitum“ po lehkem seznameni na jetbrains

    1. odkud bere kod, ktery „zkousi“ z buildovat?
    2. podporuje/umi codereview (lidmy, nikoliv FxCop), resp. slo by to k tomu nalepit?
    3. pokud jde kod zbuildovat, pod jakym uctem ulozi zmeny do SVN?
     
  3.  

    Aleš Roubíček

    12.54 - 14. září 2008 | #

    Pěkné otázky :)

    1. Kód vezme z aktuální revize, plus pošle změny, které jsi provedl.

    2. nevím přesně jak tohle myslíš, je to spíš otázka procesů než build servru, ale podpora pro automatizovaná review tam je :)

    3. Teď přesně nevím, nejspíš pod účtem pod kterým jseš přihlášený do TeamCity – a ten mám stejný jako v SVN…

     
  4.  

    Michal

    13.07 - 14. září 2008 | #

    ad 1) nerozumis mi. technicky si je vezme z kompu toho, kdo zkousi buildovat? anebo se nekam temporarne ulozi a z toho se builduje?

    1. Bere si jen zmeny nebo cely kod?

    Ptam se hlavne kvuli rychlosti pri vzdalenem pristupu

    ad 2) ano, pokud umi „znemoznit“ commit do SVN pri nevalidnim buildu, pak by mohl snadno umet precommit code review.

     
  5.  

    Radek

    13.15 - 14. září 2008 | #

    Nejsem ten pravý, kdo by měl na otázku naší infrastruktury odpovědět, ale seznam nástrojů dát můžu: SVN, CruiseControl, CCTray MSBuild, FxCop, MoinMoinWiki, Bugzilla.

    Bez verzovacího systému ani ránu. Všechno, co mě stojí víc jak den práce, v něm musí být.

     
  6.  

    Borek

    16.06 - 14. září 2008 | #

    Trac+SVN je dobrá volba, za zvážení před začátkem projektu ještě stojí nějaký distribuovaný VCS typu git nebo Mercurial, ale v principu je hlavně důležité, aby vůbec nějaký VCS byl :)

     
  7.  

    Aleš Roubíček

    17.14 - 14. září 2008 | #

    [4] Michal: Build agent má svůj pracovní adresář, kde má poslední checkout repository. Předtestovaný commit funguje tak, že se vezmou změněné soubory (možná jen změny) a pošlou se na TeamCity. Ten hodí změny do pracovního adresáře a provede build dle konfigurace.

    Pokud jsou v konfiguraci i testy, provedou se a v případě, že vše proběhlo ok, tak se pracovní adresář commitne do SVN. Nebo aspoň tak nějak si to představuju, že to funguje. :)

    To vše iniciueš pomocí pluginu ve VS. Pokud provádíš commit klasicky, TeamCity nijak nezabrání tomu, abys commitnul nefunkční kód. Je to jen o procesech v teamu a vůli je dodržovat…

     
  8.  

    Aleš Roubíček

    17.21 - 14. září 2008 | #

    [6] Borek: Distribuovaný verzovací systém jedině ve spojení s centralizovaným. Zaprvý nemaj takovou podporu nástrojů. Zadruhý líp se to zálohuje. Ale ani tak nevidim příliš mnoho výhod… :)

     
  9.  

    lopata

    18.37 - 14. září 2008 | #

    [8] Aleš Roubíček: – Mercurial je super věc, u nás jsme na něj přecházeli z CVS a je to lahoda.

     
  10.  

    Aleš Roubíček

    18.52 - 14. září 2008 | #

    [9] lopata: No vida podpora pro Mercurial bude ve čtvrté verzi TeamCity… :)

    Ale integrace do VS zatím mizerná.

     
  11.  

    Aleš Roubíček

    19.20 - 14. září 2008 | #

    Tak jo, prosím, zkuste mě přesvědčit o výhodách distribuovaného VCS, :)

     
  12.  

    Aleš Hroch

    08.23 - 15. září 2008 | #

    Aktuálně používáme v teamu SourceForge Enterprise. Je to taková šikovná virtuální mašina, kterou jen pustíte a máte kompletní infrastrukturu pro vývoj (snad až na ten build server). Podobnost s klasickou SOURCEFORGE.NET nulová (díky bohu).

     
  13.  

    Borek

    10.47 - 15. září 2008 | #

    [11] Aleš Roubíček: To bych doporučil nechat na jindy :)

     
  14.  

    Michal

    12.54 - 15. září 2008 | #

    [13] Borek: Priznam se, ze bych si to take rad poslechnul ;-)

     
  15.  

    mirek

    17.15 - 15. září 2008 | #

    Zvláštní, že tu nikdo nepoužívá MS klasiku. TFS 2008 a Team Foundation Server Build 2008. Integrace s Visual Studiem je skvělá a nemám nějak pocit, že by mě něco chybělo. Jenom si říkám, že jsem asi dělal složitě instalaci na testovací prostředí pomocí .bat souboru.

     
  16.  

    Aleš Roubíček

    07.38 - 16. září 2008 | #

    [15] mirek: TFS je celkem dost drahý. ;)

     
  17.  

    Lemrouch

    09.50 - 16. září 2008 | #

    TFS by mělo být v rámci partnerství MS Gold Partner zadáčo. Co se týče TeamCity, tak pro Solution z VS2008 neumí spouštět přímo MSTesty (pouze NUnit testy), asi to půjde obejít přes MSBuild agenta nebo určitě přes CommandLine. A co do podpory ve VS, tak ta je tuším jen pro TeamCity + SVN. Je to tak správně? Nekecám blbosti? :-)

     
  18.  

    Aleš Roubíček

    12.51 - 16. září 2008 | #

    [17] Lemrouch: MSTest nepoužíváme, jak jsem psal dopsal jsem podporu pro xUnit.net. V konfiguraci nepoužíváme solution ale MSBuild. S tou integrací jsem to hloubš nezkoumal, ale asi podporuje i TFS a VSS.

    V tom Gold Partnerovi to zas tak zadáčo není, jsou tam (nebo byla) nepříjemná omezení na počet uživatelů (tuším, že to bylo 5) na jednu instalaci serveru nebo tak nějak. A být Gold Partnerem, je pro startup třeba nemožné. ;) A později měnit něco, co je zaběhnuté a funguje jak potřebuješ, je hloupost.

     
  19.  

    mirek

    13.43 - 17. září 2008 | #

    [16] Aleš Roubíček:Vím, že to není levná záležitost, ale jak jsem psal překvapilo mě, že se o tom nikdo ani nezmínil. Spíš jsem si říkal, jestli v tom TFS nechybí nějaká skvělá funkčnost oproti ostatním a proto by se nemělo používat.

     
  20.  

    Lemrouch

    11.44 - 18. září 2008 | #

    [19] mirek: Nevím, o ničem, co by v TFS chybělo oproti „ostatním“. Ale asi zásadní problém je v tom, že TFS by se mělo používat napříč celým týmem, takže i analytici, obchodníci a projekťáci. Tam bude problém, protože né každej to umí a né každej je ochotnej se to učit :-)

     
  21.  

    dkl

    09.18 - 20. října 2008 | #

    Používáme MSBuild + CruiseControl.Net. Celý build process (včetně instalace, testů, FxCop atd.) je v msbuild skriptu tak, aby to fungovalo i bez integračního serveru. CC.Net je tak pouze spouštěč procesu a „publikovač“ výsledků. Díky tomu lze spouštět cokoliv i na vývojářově PC, a vyměnit integrační server např. za TeamCity by nebyl problém (pokud by k tomu byl důvod).

    Nedávno jsem o tom dělal interní přednášku

     

Místo pro tvůj názor

Povinné je jméno a komentář, z e-mailu se rozpoznají Gravatary.
Komentář je formátován pomocí Texy! syntaxu.
Například: **tučný text**, *kurzíva*, "text odkazu":adresa.
Internetové adresy jsou převáděny na odkazy.
Na komentáře se můžete odkazovat pomocí [číslo komentáře].

Nový komentář



O autorovi

foto autora Jmenuji se Aleš Roubíček a jsem vývojář webových aplikací na platformě ASP.NET. Zajímám se o webové technologie všeho druhu v poslední době především o mikroformáty, ASP.NET MVC a Silverlight. Pokud na mne máte nějaký dotaz nebo tak, neváhejte mne kontaktovat.

Rubriky

Tiráž

Kopírovat texy článků je bez výslovného svolení autora zapovězeno. Uveřejněné zdrojové kódy lze užívat dle licence cc by-sa 3.0.

Tipy: Šachový obchod Chesslady | Navážka písku a betonu, odvoz suti a stavebních odpadů | Informace pro motoristy | Menstruační kalendář | Užívejte si internet!

© 2004 – 2008 .