Vítejte na blog.vyvojar.cz Přihlásit | Registrovat | Pomoc
Titulní Blogy Fotky Soubory

Greenyho pracovní zápisníček

Tento blog vznikl jako vedlejší produkt během mé práce na různých projektech pro společnost Adastra CZ. Blog není koncipován jako pravidelná rubrika. Budu sem zveřejňovat zajímavé věci, na které během svého zápasu se světem .NETu narazím. Doufám, že vám tím váš vlastní zápas učiním o trochu lehčí.

Source Control na malých projektech

K napsání tohoto článku mě inspiroval můj kamarád, taky programátor. Říkal jsem mu něco jako: „Dělal jsem teď jeden projekt s použitím Subversion a hodně mi to při vývoji pomohlo.“ A on na to něco jako: „Jo, taky už jsem o tom slyšel. Je to ale moc složité a stejně mi to k ničemu není.“ Myslím si, že se mýlí. Ano, níže popsaný postup přináší do projektu nějakou režii. Ta ale není zase až tak velká, aby byla na překážku při každodenním používání. A výhody z postupu plynoucí tu režii plně vyváží.


Co je to ten source control?

Source control (známý též jako Revision control nebo Version control) je postup, který umožňuje se vrátit ke kterémukoliv předešlému stavu projektu. Source control systémy pro vývoj software mají kromě této základní funkce ještě další. Z těch nejdůležitějších to jsou funkce, které:

  • umožňují současnou práci více lidem na jednom projektu;
  • udržují centrální úložiště kódu (repository), které slouží hlavně jako zdroj jediné aktuální verze zdrojového kódu.

Způsob použití repository je nakreslen na následujícím obrázku:


Každý člen vývojového týmu se přes internet nebo místní síť připojí na repository, které je umístěno na Source control serveru. Z repository si stáhne na svůj počítač tu část zdrojového kódu, kterou potřebuje ke své práci. Po vykonání svého úkolu, který typicky obnáší nějakou úpravu kódu a její testování, odešle změny zpět do repository. Během společné práce v týmu by měly být dodrženy následující základní pravidla:

  • Každý člen týmu by měl svou kopii zdrojového kódu pravidelně aktualizovat z repository (nejméně jednou denně).
  • Práce členů týmu by se neměla překrývat. Práce více lidí na téže věci vede k nepříjemným konfliktům, které jsou častým zdrojem chyb. V nejlepším případě vedou konflikty k zahození práce některých lidí.

Zatím jsem zde psal pouze o práci v týmu. Vyplatí se použití source control i pokud na projektu pracuje pouze jeden člověk? Na tuto otázku není jednoznačná odpověď, protože v tom případě nemá význam hlavní výhoda source control, a sice možnost práce v týmu. Stále ale zůstávají ve hře další dvě důležité funkce. Zaprvé možnost vrátit se ke kterékoliv historické verzi zdrojového kódu. Zadruhé zdrojový kód je pravidelně zálohován na JINÉM počítači, než na kterém člověk vyvíjí. Zdá se to jako nepodstatný detail, ale kolik jste už za život potkali smutných lidí s crashlým diskem nebo ukradeným noutbukem?


Používané source control

Následující seznam source control systémů není úplný, obsahuje pouze systémy, s nimiž jsem měl možnost pracovat. Když tak mě prosím v diskusi doplňte:

  • MS SourceSafe – Source control systém od společnosti Microsoft. Před lety byl hojně používán, ale trpí některými neduhy, jako je krkolomná obsluha a tragicky dlouhé odezvy při práci přes internet. Vývoj byl před pár lety zastaven.
  • CVS – Open source Source control systém. Před lety taktéž hojně používán, ale vývoj byl také před pár lety zastaven.
  • MS Team Foundation Server – Enterprise řešení od společnosti Microsoft, nástupce SourceSafe. Vhodný pro střední až velmi velké projekty. Výhodou je široké spektrum podporovaných funkcí, zejména s důrazem na řízení projektu. Nevýhodou je cena licence.
  • Subversion – Open source Source control systém, nástupce CVS. Vhodný pro malé až středně velké projekty. Výhodou je podpora více platforem (Unix i Windows) a nulové pořizovací náklady. Nevýhodou jsou chybějící funkce pro řízení projektu, které ale při malých projektech nejsou nutné. Můj níže popsaný projekt je realizován právě s použitím Subversion v kombinaci s TortioseSVN, které je jeho výborným a praktickým grafickým rozšířením.


Organizace repository

Repository lze uspořádat několika způsoby. Konkrétní uspořádání záleží na zejména na složitosti projektu, na způsobu testování kódu a na deploymentu aplikace. Zde se budu zabývat pouze dvěma nejjednoduššími způsoby:

  • Trunk only – Přírůstek kódu je lineární, tedy v průběhu vývoje aplikace nedochází k žádnému větvení verzí. Toto je úplně nejjednodušší uspořádání, které je vhodné pouze tehdy, když si jsou vývojové, testovací a produkční prostředí velmi podobné a je možnost častého update aplikace na produkci.
     

     
  • DEV-PROD – Vlastní vývoj probíhá stejně jako v předchozím případě. Pokud ale má dojít k nasazení na produkčním prostředí, je z hlavní vývojové větve DEV (tedy výše popsaného Trunku) oddělená verze PROD, jejíž obsah je nasazen na vývojové prostředí (na obrázku DEV.3 na PROD.1). Výhoda tohoto uspořádání spočívá v tom, že je možné kód automaticky přizpůsobovat produkčnímu prostředí, které může být trochu jiné než vývojové. Lze také opravovat chyby v nasazené verzi, zatímco již probíhá vývoj nové funkcionality na DEV větvi (na obrázku PROD.1 na PROD.2). Navíc je stále k dispozici kompletní zdrojový kód aplikace nasazené v produkčním prostředí.
     

  • Vývojová prostředí

    Při aplikačním vývoji se osvědčil způsob, kdy aplikace během svého životního cyklu prochází následujícími prostředími:

    • Vývojové prostředí – Zde probíhá vývoj aplikace. Může to být buď lokální počítač programátora nebo virtuální prostředí přístupné přes vzdálené připojení (typicky Remote desktop).
    • Testovací prostředí – Zde se nanečisto zkouší, jak se bude aplikace chovat v praxi. Testovací prostředí by tedy mělo být co nejpodobnější produkčnímu prostředí.
    • Produkční prostředí – Zde aplikace pracuje. Na produkční prostředí by měla být nasazená aplikace pouze tehdy, když se osvědčila při fungování v testovacím prostředí. Píšu měla by, protože se tak často neděje. Většinou se přeskočením testování ušetří čas. Občas se ale stane, že se přeskočení testování vymstí a vzniklé ztráty jsou pak větší než náklady na regulérní testování.


    Použití source control

    Používání source control v praxi budu demonstrovat na konkrétním příkladu, kterým je nedávno releasnutá webová aplikace www.mula.cz (zatím v beta verzi). Při jejím vývoji je používaná konfigurace:

    • Source Control Server – Starý počítač hozený pod stolem, na kterém jsou Windows 2000. Na nich je nainstalován Apache 2.2, který je využíván Subversion source control. Repository využívá uspořádání DEV-PROD. Počítač je připojen do internetu tak, aby měl pevnou IP adresu.
    • Client A – Vývojové prostředí na mém počítači.
    • Client B (není na obrázku) – Vývojové prostředí dalšího programátora.
    • Testovací prostředí – Subdoména v rámci hlavní domény aplikace. Důležité na testovacím prostředí je, aby bylo co nejpodobnější prostředí produkčnímu. Projeví se tak problémy, které se na vývojovém prostředí neprojeví. V mém případě to byly problémy způsobené zvýšenými požadavky na bezpečnost a integrací s ostatními systémy (odesílání emailů). Testovací prostředí má svou vlastní aplikační databázi, aby testy neovlivňovaly aplikaci nasazenou v produkčním prostředí.
    • Produkční prostředí – Hlavní doména na web hostingu.

     


    Běžný vývoj probíhá tak, že vývojáři A, B až X kutají, jak je popsáno v úvodní kapitole. Když dokutají do určitého bodu, vývojář A ho označí v DEV repository tzv. tagem, který jednoznačně identifikuje aktuální verzi zdrojového kódu (třeba „Release 123“). Vývojář A pak svou aktuální verzi kódu zkompiluje, zabalí a vystaví na testovacím prostředí. Tam je nějakou dobu testována, zda vše funguje správně. Vývojáři mezitím dál kutají...

    Pokud se na aplikaci v testovacím prostředí vyskytují chyby, provede se jejich oprava, která je označena novým tagem (třeba „Release 124“), a která je opět nasazena na testovací prostředí.

    Pokud je aplikace v testovacím prostředí v pořádku, provede se merge (spojení verzí). Merge promítne změny aplikace nasazené v testovacím prostředí (označené tagem „Release 124“) do PROD repository. Po zkompilování a nasazení aplikace z PROD repository se by na produkčním serveru měla ocitnout stejná (nebo velmi podobná) verze aplikace jako na testovacím.

    Navíc, jak jsem psal výše, pokud máme rozpracovanou implementaci nějaké nové funkcionality a zjistíme nějaký závažný problém na PROD aplikaci, pak můžeme opravu provést přímo nad PROD repository. Nejsme nuceni dělat release rozpracované DEV aplikace, protože ten by určitě nedopadl dobře.


    Závěrem

    Při vývoji software se vyplatí řídit se určenými procesy. Pod pojmem proces si nemusíte představovat nějaké hroznosti. Pod pojmem proces si představte postup, který si sami definujete, aby jeho výsledkem byl spolehlivý kód. Důležitým bodem je, že proces je jednou daný a už se nemění. Takže nad ním již nemusíme přemýšlet a jeho provádění můžeme svěřit počítači ve formě skriptů, které vyžadují minimální manuální zásahy.

    Pokud se vývoj žádnými procesy neřídí, pak se tomu říká pankárna. A výsledek pankárny je stejně spolehlivý, jako je spolehlivý typický pankáč.

    Výše popsaný proces je samozřejmě jen jednou z možných cest. Tento článek Vám má hlavně posloužit jako vysvětlení některých běžných pojmů a jako inspirace založená na případové studii.

    A na úplný závěr reklama: Pokud chcete něco převézt nebo přestěhovat, jděte na www.mula.cz. Snad vám portál bude sympatický, když teď víte, jak vznikal. Plánuju ještě navazující článek o jeho architektuře, konkrétně o použití Linq2Sql v ASP.NET aplikaci.


    Update (1.7.2010)

    Po diskusi s uživatelem rarous jsem dospěl k závěru, že výše navrhované řešení je zbytečně komplikované a nepraktické. Projekt jsem překopal a buildovací workflow nyní vypadá takto:

     
    Úprava se řídila následujícími pravidly:

    • Dvě repository jsou nesmysl, jedno bohatě stačí.
    • DEV, TEST i PROD aplikace by ideálně měly být stejné a lišit se pouze konfiguračním souborem.
    • Aplikace nasazovaná na PROD vždy musí pocházet ze stejného buildu jako aplikace nasazovaná na TEST, protože TEST slouží k prověření funkčnosti nasazované aplikace.
    • Projekt je tak malý, že mi přijde zbytečné rozbíhat build server a automatické buildy. Tuto funkcionalitu zastává ručně developer na Client A.

     
    Důsledky úprav jsou:

    • Zjednodušení celého buildovacího workflow.
    • Client A může dělat úpravy na TESTu a PRODukci i bez přístupu k source repository.
    • Vždy je nasazovaná otestovaná verze (pokud Client A tento krok záměrně nepřeskočí).
Zveřejněno 22. června 2010 20:10 by daniel.smolka
Vedeno pod: , ,

Komentář

 

vlko napsal:

Odporucam sa pozriet na git. Je to distribuovany system a je vynikajuci najma na spravu branchov a teda sucastny vyvoj test, dev a production vetvy

června 22, 2010 21:13
 

mjurek napsal:

Pekny clanek. Coby zastupce dodavatele se ale musim vyjadrit k hodnoceni TFS. Co pisete platilo ve verzich 2005 a 2008. Verze 2010 je urcena i napr. pro jednomuzne projekty.

Jednak instalace jiz nevyzaduje nezbytne SharePoint a data warehouse, pak ji lze jednim wizardem nainstalovat i na stanici napr. s Windows Vista nebo Windows 7.

Druhak cena byla dramaticky snizena. Pokud mate Visual Studio s MSDN subskripci (staci Professional!!!), mate v MSDN zahrnutou tez jednu licenci na TFS server a jednu klientskou licenci CAL (tedy za ne neplatite nic navic).

Pokud nepouzivate Visual Studio, pak lze zakoupit TFS s 5 klienstkymi licencemi za 500 EUR, coz je myslim vzhledem k funkcnosti TFS mimoradne dobra nabidka.

června 22, 2010 21:52
 

rarous napsal:

Krásná studie nevhodně zvoleného způsobu verzování. ;) Doporučuju prostudovat tento seriál http://zdrojak.root.cz/serialy/pet-duvodu-proc-zvolit-git/

června 22, 2010 22:07
 

daniel.smolka napsal:

re mjurek:

Ano, TFS 2008 jsem pri rozhodovani vyloucil prave z duvodu, ze k provozu vyzaduje serverove Windowsy a MSSQL, coz je oboji celkem draha sranda. TFS 2010 pred pul rokem, kdy vyvoj startoval, jeste nebyl.

Jinak diky za komentar. Ucastnil jsem se par vasich prednasek.

června 23, 2010 11:44
 

daniel.smolka napsal:

re vlko, rarous:

Bez muceni priznavam, Git jsem neznal a diky za odkaz na root.cz.

re rarous: "Krásná studie nevhodně zvoleného způsobu verzování"

Mam v clanku nejake fakticke chyby nebo je chybou to, ze pracuji se SVN?

června 23, 2010 12:40
 

rarous napsal:

Různé repozitory pro produkci a vývoj je doslova antipattern verzování (reakce na posledni schema). Přináší to zbytečnou režii navíc, která nepřináší žádnou výhodu. Pro označení release verze se používají tagy. v Případě potřeby se z nich pak dají vytvořit branche a patchovat, ale vývoj stále v jedné repository. S Gitem je navíc branchování a patchování velice snadné.

června 23, 2010 21:40
 

daniel.smolka napsal:

re rarous:

Takze by to melo byt radeji takto?

http://www.greeny.name/blog-support/SourceControl-Usage2.png

června 24, 2010 12:05
 

daniel.smolka napsal:

re rarous:

Jeste jsem upravil pouziti testovaciho prostredi. To, co jde na produkci by se melo nejdriv otestovat :o)

http://www.greeny.name/blog-support/SourceControl-Usage3.png

června 24, 2010 14:11
 

rarous napsal:

Pořád je problém v tom, že se liší vývojový kód od produkčního. Rozdíl mezi devem a produkcí by měl být maximálně v konfiguraci (testovací prostředí by mělo být stejné jako produkční). graf je mnohem jednodušší. Vývoj probíhá nad jednou repository, nad ní je build server, který provádí sestavení a deployment na dev prostředí (nejlépe po každém commitu), build může mít více konfugurací. Jedna z nich je build na deployment do provozu, který vytvoří v repository tag a připraví balíčky pro deploy. Takže v ClientA nejsou dvě cesty, ale pouze jedna, výstup se rozvětvuje až na konci, dle vybrané konfigurace.

června 24, 2010 22:00
 

daniel.smolka napsal:

Nevím, jestli má smysl rozjíždět build server na projektu o dvou lidech. Dev prostředí mi tedy splývá s počítačem, na kterém probíhá vývoj.

Souhlasím s tím, že co je na vývoji, by mělo jít i na test a do produkce. Takhle to dělám v práci (jen si v Solution ve VS přepnu konfiguraci z Debug na Setup). Na svém privátním projektu jsem chtěl vyzkoušet něco nového a vypadá to, že se asi vrátím ke starým osvědčeným postupům...

Díky za připomínky. Aspoň už teď vím, kudy cesta nevede.

června 25, 2010 10:39
Neregistrovaní uživatele nemužou přidávat komentáře.
Powered by Community Server (Personal Edition), by Telligent Systems
Vyvojar.cz na prodej!