K buildovani a sprave verzi aplikaci se zavede (spis ozivi nikdy nedotazeny) 
CBS modul Build.

Je potreba, aby existoval seznam "znamych" aplikaci. Aplikace muze byt 
v podstate cokoli, pro modul je to pouze zaznam, ale typicky pujde o web. 
Aplikace se tedy muze vztahovat k instanci webu (pripadne vice webu) a pak
pro ni ma modul Build rozsirene featury, viz dale.

V ramci kazde aplikace se definuje:

1.  Jednotlive buildovaci faze a prechody mezi nimi. Pro kazdy "prechod"
    se definuji fyzicke operace, ktere se musi provest. To bude obvykle 
    zahrnovat nejake kopirovani souboru na serveru, kopirovani dat v DB,
    to vse musi probehnout transakcne, aby se v pripade neuspechu dalo
    bez poskozeni rollnout back.

2.  Pro kazdy prechod musi byt definovano, za jakych podminek jej lze provest.
    To znamena - kteri uzivatele ho musi "odfajfknout", kdy se smi build
    fyzicky provest (napr. o pulnoci, ale minimalne tri dny po odsouhlaseni,
    aby byl cas uzivatele informovat apod.) V tu chvili se musi "zdrojovy" 
    stav uzamknout proti zmenam az do okamziku buildu nebo do zruseni
    naplanovaneho buildu.

Build webu:
-----------

Kazdy web ma svou revizi WWW dat (templaty, makra atd.) a bezi na nejake
konkretni verzi CBS (se kterou je otestovan). Defaultni buildovaci
retezec vypada:

          A              B               C                D
   +------------+  +-----------+  +------------+  +--------------+
   |            V  |           V  |            V  |              V
+-----+     +----------+     +------+     +------------+     +--------+
| dev |     | betatest |     | beta |     | publictest |     | public |
+-----+     +----------+     +------+     +------------+     +--------+
                  ^              |               ^                |
                  +--------------+               +----------------+
                         E                                F

Pro kazdou takovouto instanci webu bude existovat instance CBS (napr.
cbs_<id_app>_<phase>, to by nemelo nijak extra bolet, vzhledem k tomu, 
ze jedna instance CBS zabira < 10 MB). Pri prechodech se automaticky
pouzije CBS puvodniho (pred prechodem) webu a nebo se da konkretnimu
prechodu povolit explicitne zmenit revizi CBS, viz dale.

Update instance CBS na konkretni revizi lze provadet pro konkretni fazi webu
(dev, beta atd.) nebo v ramci prechodu mezi fazemi. Kdo konkretne smi
zmenu revize v ktere fazi / prechodu navrhnout a provest je otazka ACL,
resp. nastaveni konkretniho projektu.

Je-li naplanovan build webu, mel by byt pred jeho zacatkem informovan
pripadny uzivatel a hlavne se musi killnout vsechny sessiony daneho (danych) 
webu.

O vsem samozrejme vznikaji zaznamy v logu.

Zamykani webu:
--------------

Kazdou fazi kazdeho webu lze "zamknout". To znamena, ze dotycny web
bude pouze zobrazovat obecnou systemovou stranku "under construction"
nebo tak neco, s vyjimkou vyvojaru, kteri uvidi web tak jak maji.
Vyvojar se pozna:

- podle IP adresy (ale vic lidi muze mit stejnou...)
- podle specialne vygenerovaneho cookie (ale da se pres http odposlechnout...)
- sam si to osefuje ve zdrojaku (ale hrabe do nedotknutelneho verzovaneho kodu...)
- nejakym systemovym odkazem primo z CBS
- nejak jinak...?

Propojeni s Mantisem:
---------------------

V Mantisu je mozne pridat atribut "product build" (pouzivame u Draculy),
ve kterem se da uvest, ke ktere vezri ktereho webu se hlasena chyba
vztahuje. Build modul si pak muze tuto informaci z Mantisu cist a rozvnou
zobrazovat tickety nad konkretni fazi konkretniho webu apod. a napr. 
nepovolit build z verze, ktera nema vsechny tickety vyrizene apod.

Bezny kolobeh vyvoje:
---------------------

Ales vyviji na "dev" webu. Kdyz potrebuje novou featuru v CBS, zada
si do Mantisu ticket, Roman mu upravu udela a Ales si sam updatne "dev"
na novou revizi a jede dal. Az uzna za vhodne, navrhne build "dev"u
na "betatest", coz musi odsouhlasit i betatester. Betatester
si testuje "betatest" a kdyz je spokojen, navrhne posun na "beta".
Pokud se najde v "beta" verzi chyba (Mantis!), presune se "beta"
zpet do "betatest", kde se chyba odladi (pripadne se oprava tez
promitne do "dev", dava-li to smysl) atd. Podobnou cestou
az k "public".