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čí).