Automatický deployment webových aplikácií

Pri vývoji webovej aplikácie je táto zvyčajne nasadená na viacerých počítačoch:

  • programátorov PC – developer vyvíja aplikáciu
  • stage server – tu beží najnovšia funkčná verzia aplikácie, ktorá slúži najmä klientovi na kontrolovanie stavu vývoja a zadávanie ďaľších projektových úloh
  • produkčný server – výsledná aplikácia

Použitie stage servra je potrebné na predvádzanie funkčnosti klientovi ako aj kontrolu verzie aplikácie pred nasadením na produkčný server. Na tomto servri by mala byť posledná verzia aplikácie, a preto je potrebné ju nasadzovať čo najčastejšie – a to je dôvod, prečo by toto nasadzovanie malo byť automatizované.

Proces nasadzovania by mal spočívať v nasledovných krokoch:

  1. checkout poslednej verzie aplikácie z repozitára
  2. zbuildovanie aplikácie
  3. spustenie testov
  4. nasadenie na server

Vypísané kroky môžu developerov od takéhoto používania stage servra odradiť, ale našťastie existujú riešenia, ktoré môžu takéto procesy riadiť. Ja som na tento účel použil Continuous Integration server Cruise Control.NET. Continuous Integration je metóda, pri ktorej sa celá aplikácia builduje a testuje “pri každej príležitosti”, teda toto riešenie už zahŕňa problematiku source controlu, buildovania aplikácií a testovania.

Cruise Control .NET sa skladá z dvoch hlavných aplikácií, a to samotného výkonného servicu, ktorý sleduje zmeny a na základe nakonfigurovaného plánu spúšťa integračný proces a webového dashboardu, ktorý slúži pre kontrolu a ovládanie jednotlivých projektov. Webový dashboard môže dokonca kontrolovať viacero inštancií servicov na viacerých fyzických servroch.

Buildovanie

Toto riešenie teda stačí už len nastaviť a kroky 1-3 budú hotové. Zprvu Vás zarazí, že celá konfigurácia všetkých projektov je uložená v jednom XML súbore, program ale používa akýsi “preprocesor”, ktorý umožňuje do XML vkladať obsahy celých XML súborov (tieto musia obsahovať jeden koreňový element) a teda je možné si navrhnúť krajšiu adresárovú štruktúru udržujúcu projektové dáta spolu s ich konfiguráciou (namiesto umiestnenia v inštalačnej lokácii servicu).

Beh integračného procesu sa spúšťa tzv. triggerom. Pre moje využitie najzaujimávejšie sú interval trigger (spúšťa sa v nastaviteľných intervaloch), scheduled trigger (dajú sa nastaviť časy a dni, v ktorých sa má trigger spustiť) a project trigger (je komplikovanejší, spúšťa ho iný trigger a pri každom jeho spustení project trigger zistí stav iného projektu a podľa nastavenia môže integračný proces spustiť). Ja som deployment jednej aplikácie rozdelil na 2 projekty, prvý projekt sa stará o kroky 1-3 a druhý sa stará o samotné nasadenie. Celý tento proces sme naplánovali na noc, preto používam scheduled trigger.

Spustenie triggera ale ešte nemusí znamenať spustenie celého procesu. Projekty majú nastavený aj tzv source control block, v ktorom sú zadefinované údaje o repozitári so zdrojovými kódami. V source control block-u môžete nastaviť napríklad to, aby sa celý proces spustil iba vtedy, ak od posledného spustenia nastala v repozitári nejaká zmena. Túto vlastnosť samozrejme používam, lebo je zbytočné znova buildovať, testovať a nasadzovať úplne rovnakú aplikáciu.

Ďalej sa dajú projektu nastaviť prebuild, buid, a postbuild úlohy, ktoré môžu obsahovať spustenie aplikácie s parametrami. Priamo podporované sú ale aj úlohy poznajúce MSBuild a mnohé ďaľšie.

Tzv publishermi sa potom končí mnou popisované nastavovanie. Za zmienku stojacim publisherom je email publisher, ktorý sa dá nastaviť aj tak, že pošle report o builde všetkým, ktorí od posledného úspešného buildu menili zdrojové kódy, v prípade, že sa nepodaril build alebo aplikácia neprešla testami.

Nasadzovanie na server

Samotné nasadzovanie je záludnejšie, obsahuje niekoľko problémov, hlavne ohľadom konfigurácie servra. Samozrejme, že konfigurácia aplikácie je rôzna na programátorovom PC, na stage servri a na produkčnom servri. Pri nasadzovaní na stage server je teda potrebné zachovať niektoré nastavenia ale zároveň aplikovať zmeny, ktoré implementoval programátor. Ja mnou popisované riešenie používam na deployovanie ASP.NET aplikácií, ktorých konfiguračné súbory sú vo formáte XML. Dôležitou preto pre mňa bola knižnica xmldiff od Microsoftu, ktorá pomáha identifikovať a aplikovať zmeny medzi XML súbormi. Za týmto účelom som vyrobil aplikáciu, ktorá dokáže hlavne merge-núť konfiguračné súbory a prípadné zmeny zasielať mailom.

Ďaľším problémom je, ako dostať zbuildovanú aplikáciu na stage server. Za týmto účelom používam VPN v ktorej je iba deployovací a stage server a utilitu rsync.

Všetky tieto úkony sa spúšťajú z bat súborov pre jednotlivé projekty. Celý CruiseControl.NET projekt sa potom spúšťa pomocou project triggera vždy po úspešnom zbuildovaní prvého projektu (kroky 1-3) .

Leave a Comment