nav line

Zavedení systému kontinuální integrace (CI) do praxe 2/2

Systémů pro zaznamenávání úkolů, tvorbu dokumentace, komunikaci v týmu a deployment existuje celá řada. V druhém dílu článku se podíváme, jak z nich udělat tým spolupracujících pomocníků. Využitím vzájemného propojení nástrojů, které jinak fungují zcela samostatně, můžete získat opravdu hodně.

Systém pro řízení projektů a sledování požadavků

Ať se již jedná o zbrusu nový projekt na zelené louce, nebo aplikaci ve fázi servisu, vždy je nutné mít systém pro sběr požadavků a práci s nimi. Než začnou vývojáři tvořit reálný kód, je třeba mít jasně určené úkoly, na které lze alokovat konkrétní pracovníky a u nichž můžeme sledovat průběh práce či průběh čerpání zdrojů oproti očekáváním.

V minulosti jsme v Lundegaardu využívali Mantis Bug Tracker, který ovšem nevyhovuje dnešním požadavkům na řízení vývoje. Systém pro zadávání požadavků to je dobrý, i když poněkud těžkopádný a navíc neobsahuje některé stěžejní funkce, které dnes nutně potřebujeme. Moderní vývoj aplikací vyžaduje pružný systém pro správu požadavků, který aktivně podporuje aplikaci agilních metodik řízení vývoje. V současnosti využíváme issue tracking system JIRA, který má oproti výše zmíněnému Mantisu následující přínosy:

  • různá workflow projektů,
  • spojuje funkce issue trackeru a time trackeru,
  • počítá s prací v týmech (spravovatelný systém přístupových práv a rolí),
  • lze snadno nastavit integraci s dalšími nástroji (Bitbucket.org, HipChat IM, Confluence),
  • má pohodlné ovládání.

JIRA stejně jako další produkty od společnosti Atlassian stojí nezanedbatelné peníze, ovšem v současnosti nám nahrazuje hned dva systémy pro issue tracking a vykazování práce. Mimo jiné je práce s JIRA pohodlnější a rychlejší, v tomto ohledu nám šetří čas přímo. Navíc jeden ze systému jsme si na míru vyvinuli sami, takže nám do budoucna odpadají nemalé náklady na vývoj, servis a bugfixing vlastní aplikace. Systém JIRA doporučujeme napojit na jednotné úložiště zdrojových kódů (viz níže), u každého úkolu pak lze zobrazit podrobné informace o rozsahu odvedených prací a jejich autorech. Ke slovním komentářům, které píší členové týmu, tak dostáváme i související technické detaily implementace.

Workflow

Velice důležité je správná volba a používání workflow. JIRA nabízí v rámci instalace workflow out-of-the-box, to ovšem přesně nepokrývá procesy ve vývoji.

JIRA dává naprostou volnost v nastavení workflow, což je ve výsledku ale dvousečné. Volnost je určitou výhodou, nicméně je nutné podchytit opakující se situace a procesy společné pro většinu projektů. Z nich se poté vytvoří "kompromis" používaný pro více projektů. Čím více se ponoříte do možností konfigurace, tím spíše sklouznete k tomu, že na každém projektu vyhovíte nějakému specifickému požadavku a nastavíte zvláštní workflow. A to má více nevýhod než přínosů. V menším množství workflows se lidé lépe orientují, stavy (To do, Done, Accepted, ...) i další vlastnosti by měly být jednotné napříč projekty, aby v komunikaci a procesech nedocházelo k nejasnostem. Pro manažery i pro vývojáře je jednodušší zorientovat se v několika univerzálních workflows než v desítkách specifických. K tomu slouží definice workflow schémat, které lze pro společnost uvážlivě předpřipravit a následně z nich při vytváření nových projektů pouze vybírat.

Pohodlné ovládání není možná na první pohled stěžejní, ale šetří čas a motivuje pracovníky k používání systému, když už ne s radostí, tak alespoň s respektem. Řekněme si upřímně, práce s "on-site" stylem editace, vyhledávání, našeptávače a klávesové zkratky jsou zkrátka super!

Vykazování odpracovaného času

Dříve jsme měli systém vykazování práce oddělený od issue tracking systému. Byl to systém, který jsme si vytvořili na míru. Ve vývoji nelze pokračovat do nekonečna a předělání na požadavky dnešní doby by v podstatě znamenalo vytvoření nové aplikace.

Co přináší sloučení systémů do jednoho:

  • přímo související informace o zadání a průběhu realizace úkolu se udržují v jediném systému,
  • méně času investovaného do zadávání práce, výkaznictví, předávání úkolů uvnitř řešitelského týmu,
  • informace o osobách, způsobech a náročnosti řešení sloučené na jednom místě,
  • vyhodnocení průběhu/úspěšnosti projektu je mnohem jednodušší a přesnější v návaznosti na předchozí body.

Pro sofistikovanější práci využíváme spojení JIRA s Tempo Timesheets Pluginem. JIRA už v základu podporuje zaznamenávání práce (worklog), pro menší tým tedy může stačit vestavěná funkcionalita, kterou pravděpodobně budete chtít ve větším týmu rozšířit o možnost členění dle týmů, projektů, apod. Rozpočet je závislý na velikosti týmu, jak je v ekosystému Atlassianu již zvykem.

Verzovací systém

Úkoly jsou určené, rozdělené mezi pracovníky týmu a práce se rozbíhají. Postup je ale třeba zaznamenávat, spojovat změny více lidí do jednoho celku. K tomu již řadu let využíváme verzovací systém Git. Pokud v minulosti někdo sáhl po verzovacím systému, neměl na výběr tak jako dnes. Mnoho z vás jistě zná Subversion. V dnešní době musíme ovšem propagovat distribuovaný verzovací systém (DVCS). Nejpopulárnější systémy jsou celosvětově Git a Mercurial, konkrétní výběr je otázkou osobních sympatií, které si můžete udělat na základě zkušeností nebo můžete využít stručné srovnání v dalším článku o verzovacích systémech. V něm je i podrobně rozebráno, proč je DVCS výhodnější než klient-server model.

Programátoři budou denně v přímém kontaktu s verzovacím systémem, takže pokud nemáte jasného favorita, můžete vyhlásit mezi vývojáři "referendum".

Co se týká finanční stránky věci, verzovací systémy samy o sobě jsou zdarma. Na rozdíl od úložiště dat...

Jednotné úložiště zdrojových kódů

Složitější téma, které navazuje na výběr verzovacího systému, je Jednotné úložiště zdrojových kódů. Webový integrátor jako producent řady řešení pro klienty má ve své produkci nepoměrně větší množství repositářů oproti relativně malému počtu vývojářů. Tento (ne)poměr ovlivňuje zásadním způsobem finanční náklady u různých provozovatelů.

Správu repositářů je možné řešit na vlastním serveru nebo využít hostovanou službu. Na vlastním serveru máte na výběr open-source řešení, které vyžaduje specifické know-how a čas, nebo komerční řešení s placenou podporou. Nakonec zde máme systém měsíčního pronájmu hostingu – využití cloudové služby.

Řešení on-premise – „to, co je v domě“

V počátcích kontinuální integrace jsme využívali vlastní git server. Co se týká aplikací, nabízí se možnost využití open-source technologií zdarma, které je ovšem nutné konfigurovat a čas také stojí určité peníze. Musíme také počítat s režií v podobě správy IT zdrojů.

Vedle open-source řešení stojí placená řešení. Ta představují relativně velkou (ale jednorázovou) investici. Výhodou je, že taková řešení fungují doslova out-of-the-box. Můžeme doporučit Atlassian Stash, který poskytuje především pohodlnou a přehlednou správu a také široké možnosti řízení uživatelských účtů, skupin a napojení na Active Directory. Alternativou může být např. GitLab, který existuje v komunitní verzi i enterprise edici, příp. řešení GitHub Enteprise. Kromě ceny se ohlížejte na pohodlnost ovládání, dostupnou dokumentaci a aktivitu komunity. Nepoužívejte nástroje, ke kterým máte výhrady, ale naopak ty s intuitivním ovládáním.

Pronájem – pružnost oblaku na požádání

Cloud se může nafukovat a smršťovat doslova jako mrak, typickými zástupci jsou např. Bitbucket, GitHub nebo GitLab. Nastíníme vám výhody:

  • dostupnost 24/7 odkudkoliv nezávisle na interní infrastruktuře,
  • nemusíte se starat o provoz hardware ani infrastruktury,
  • zálohy, diskový prostor a bezpečnost řeší tým specialistů,
  • automatické aktualizace systému a doplňků,
  • jednoduchý přesun k jinému provozovateli.

GitHub je z finančního hlediska vhodnější pro větší týmy pracující na malém množství projektů – produktů. Takovému týmu by vyhovovala cenová politika postavená na počtu privátních repositářů. Takový model se nám prodražuje. Bitbucket má opačný model postavený na počtu uživatelů v týmu nezávisle na množství repositářů. Například při vývoji e-shopu na e-commerce platformě Magento potřebujeme desítky repositářů pro různé extensions. Výsledkem u nás tedy bylo logické opuštění GitHubu a přechod na Bitbucket.

Cloudová služba je pružnější a pohodlnější na provoz, v případě potřeby je vcelku snadné odejít k jinému provozovateli obdobné služby, i když v dlouhodobém horizontu může vyjít jako ta dražší varianta.

Deployment – nasazování změn do různých prostředí

Vývojář odevzdal svou práci, tedy kód zaverzovaný v jednotném úložišti. Nyní přichází chvíle, kdy by mělo dojít k jeho nasazení do běhového prostředí. Nasazování vyvinuté aplikace by neměl provádět vývojář sám manuálně, tato část procesu by měla být úkolem specialisty na continuous delivery a proces by měl být vyřešen automatickým deploymentem. Ve chvíli, kdy vývojář odevzdá svůj kód, zavoláme spuštění deploymentu nástrojem, který provede nasazení do odpovídajícího prostředí. Více o deploymentu v článku Výhody kontinuální integrace a automatizovaného deploymentu.

Dokumentace projektů

Každý, byť sebemenší, projekt potřebuje dokumentaci. Vývojáři stojící za vytvořením řešení často předávají projekt jinému týmu k maintenance a jistě se shodneme, že bez dokumentace se s cizím kódem pracuje nevalně. Dokumentace kódu by měla být vždy automaticky jeho součástí, ta však sama o sobě obvykle pro rychlé zapojení nových vývojářů nestačí. Je proto vhodné vytvářet a udržovat kompaktní dokumentaci popisující architekturu a implementaci specifických funkčních částí každého řešení, ideálně za využití nějakého online systému, umožňujícího okamžitý přístup ke čtení i editaci zájmových skupin uživatelů. V minulosti jsme experimentovali s MediaWiki, později jsme přešli k používání systému Confluence. Jedním z důvodů je opět integrace s dalšími Atlassian systémy, přívětivé uživatelské rozhraní a flexibilní bezpečnostní model umožňující selektivní nastavení oprávnění. MediaWiki oproti Confluence nevyžaduje náklady na licenci, ale v základu máte velice jednoduché otevřené rozhraní s minimální možností formátování a z podstaty věci Wiki neřeší strukturované formy zabezpečení přístupu. Její použití tak vyžaduje řádově desítky hodin práce s nastavení, přidáváním doplňků, apod., a tento čas stojí ve výsledku nezanedbatelné peníze.

Jaké funkce jsou stěžejní a co nám usnadňuje práci:

  • import z MS Word dokumentů,
  • export do MS Word/PDF formátů,
  • formátování,
  • vkládání odkazů a obrázků,
  • dokumentaci programového kódu,
  • práci s makry.

Poslední zmíněná makra představují bohatou funkcionalitu pro vkládání specifického obsahu (např. programového kódu) nebo také dynamicky tvořeného obsahu, jakým jsou přehledy specifických podstránek aj. Hojně využívané a doporučení hodné je využití integrace se systémem JIRA, využití filtrů pro zobrazení přehledu úkolů, které jsou dynamické a nejsou pak závislé na pečlivosti autora. Nakonec informace o aktivitě v Confluence odesíláme v podobě notifikací do HipChatu  do tematických místností (více o chatu v další kapitole). 

Komunikace v reálném čase - chat

Odešlete e-mail skupině lidí a druhý den zjistíte, že na toho nejdůležitějšího jste zapomněli. Anebo naopak v situaci, kdy si klient není jistý, komu konkrétně má poslat e-mail, zašle požadavek deseti lidem. Zpráva se sice dostane k správnému adresátovi, ale několik dalších lidí dostalo zprávu zbytečně. Nejen, že to může někoho otravovat, ale čistě prakticky je náročné udržovat si přehled nad aktuálním děním, když mi padají do mailboxu stovky zpráv denně.

Představte si oproti tomu chatovací místnost, do které jednou pozvete skupinu lidí, a všichni už mohou diskutovat bez obav, že by na někoho bylo zapomenuto. Když se naopak někoho právě probíhající konverzace netýká, může se dočasně odpojit. V případě potřeby může být jmenovitě přizván později.

Mailboxy nemáme zahlcené přemírou interních zpráv a e-mail se ve výsledku stává nástrojem spíše pro komunikaci mimo organizaci než uvnitř. I část komunikace s klienty řešíme prostřednictvím chatu. Toto je obzvlášť výhodné, když potřebujeme probrat určité nejasnosti, nejlépe v reálném čase a ve více lidech najednou.

Kromě komunikace reálných uživatelů nasáváme informace z ostatních využívaných systémů, tzn. JIRA, Bitbucket, Jenkins a Confluence. Na rozdíl od agregace informací v JIRA, kde se informace vážou na konkrétní úkol, agregujeme v HipChatu informace do chatovacích místností podle týmů nebo podle projektů. Pro doplnění ještě finanční aspekt: náklady lze spočítat vcelku snadno, v cloudovém provozu s neomezenou historií a vyhledáváním zpráv stojí organizaci každý uživatel 2 dolary měsíčně.

Integrace a standardizace

Všechny systémy Atlassianu jsou navzájem propojitelné. To patrně není taková výjimka pod sluncem a umožňují to na určité úrovni i jiné systémy včetně open-source nástrojů, ovšem propojení produktů z jedné rodiny je jednodušší a většinou je otázkou několika minut, maximálně jednotek hodin.

Integrace je klíčovým prvkem a na ní stojí celý efektivní systém práce. Pokud nemáte takovou integraci vyřešenou v rámci společnosti, doporučujeme posun tímto směrem za cenu určitých nákladů okamžitých i budoucích. Ušetříte si nervy i peníze a naopak se zvýší kvalita. Předávání a agregace informací šetří e-mailovou i osobní komunikaci včetně potřeby týmových porad. Navíc máme dobře sledovatelnou historii, která doplňuje tradiční dokumentaci.

Pokud jste se již do zavádění nových systémů pustili nebo se na to teprve chystáte, vyhledávejte pomoc někoho zkušeného – podobně profilované firmy v oboru nebo specializovaného konzultanta. Ušetříte nejen své nervy při učení a zavádění nových systémů, ale i své peníze a v neposlední řadě příklady táhnou – pracovníci v organizaci budou přijímat změny ochotněji, protože uvidí někoho, kdo už má nepříjemnosti za sebou a profituje z výhod.

Ohodnoťte článek

Zavedení systému kontinuální integrace (CI) do praxe 2/2

Diskuse

dd

Související články

Vyhledávání na blogu

Webová integrace

Webová integrace jako nová oblast pro business „velkých" webových agentur.

o webové integraci

Profily blogujících