středa 5. září 2012

CZ Podcast 66 - WebExpo

Další díl našeho dílka je tu. Zvuk špička, náš výkon odpovída tomu, že jsme po prázdninách, ale zase kupa zajímavých informací o konfeře WebExpo. Doufam, že se vám bude líbit. Jo a tajná informace, je tam slevový kód na vstupenky.

neděle 2. září 2012

Cesta ke Continuous Delivery I. - Mainline vývoj

Rád bych se u jedné z našich komponent posunul z módu Feature branch (větev per funkcionalita) do módu Mainline (hlavní větev) vývoje. Při Feature branch má vývojář vlastní větev, ve které si kutí změny, jednou za čas si přimerguje změny z hlavní větve, a když si myslí, že je vše připravené a má zelenou od oddělení kvality, kód zamerguje do hlavní větve. Oproti tomu vývoj v Mainline znamená, že až na pár výjimek neexistují větve a vývojáři všechny změny provádějí rovnou do hlavní větve a to alespoň jednou denně. Oba dva přístupy mají své pro a proti.

Feature branch

Tento přístup má hlavní výhodu v tom, že se kód může mnohokrát změnit, než je vývojář s jeho podobu spokojený. Skvěle to podporuje i režim, ve kterém se provádí code review, a do hlavní větve se nedostane něco, s čím by nebyl seznámen alespoň jeden další pár očí. Nevýhodou Feature branch je fakt, že k integraci s hlavní vývojovou větví dochází velmi sporadicky. Úplnou jistotu, že nedošlo k integračním problémům, máte jenom ve chvíli kdy proběhnou všechny integrační testy se zbytkem systému.

Mainline

Tento přístup má hlavní výhodu v tom, že případné problémy se objeví, tak rychle, jak jen to je možné. Nedochází k tomu, že si vývojáři něco suší u sebe ve větvi a k integračním problémům dojde ve chvíli code drop, kdy všichni zamergují své změny do hlavní vývojové větve. Nevýhoda tohoto přístupu je v tom, že klade daleko větší nároky vývojáře. Změny se musí promyslet a dělat po menších krocích, vývojář komituje změny minimálně jednou denně. Dělat code review je velmi obtížné, protože nemáte k dispozici celý obrázek o tom, jak bude vypadat výsledný celek.

Protože na komponentě, o které se bavíme, pracují maximálně tři vývojáři na ráz (současný stav, do budoucna jich může být více), nedochází k problémům při mergování změn do hlavní vývojové větve. To je jistě jeden z hlavních argumentů pro to dále využívat Feature branch. Naopak proti hovoří fakt, že komponenta plní zásadní roli v celé platformě a případné chyby mohou mít vážné následky. Navíc jakákoliv změna se efektivně projeví až po code drop zbytku komponent, které na ní závisejí. To sebou přináší minimálně týden stabilizace a řešení problémů vzniklých integrací.Přechod na Mainline by nám přinesl právě odstranění problémů s odloženou integrací. Zároveň díky infrastruktuře kolem Java platformy budeme velice rychle schopni implementovat požadavky, které sebou vývoj v Mainline přináší.

Mainline vývoj předpokládá, že z cesty odvalíme několik technických a řekněme sociologických překážek. Začneme s těmi sociologickými, protože ty implikují technické. Vývojáři mají obavy z následujících dopadů Mainline vývoje.

  • Vývoj ve Feature branch mi umožňuje vývoj, kdy na začátku nemám úplně přesnou představu o tom, jak bude vypadat konečný výsledek. Znám přibližně kam bych se chtěl dostat, ale ještě nevím, jak to bude nejlepší. Dělám velkou spoustu změn v kódu než jsem spokojen. Nechtěl bych, aby tyhle změny byly v hlavní vývojové větvi.
  • Nejsem zvyklý plánovat změny, tak abych je mohl začlenit do hlavní vývojové větve.
  • Není mi jasné jakým způsobem mi bude někdo dělat code review. Budeme se vzájemně neustále vyrušovat. Navíc změny nebude možné posoudit v kontextu celé funkcionality.

Na první pohled se zdá, že to je sám o sobě docela slušný seznam důvodů k tomu, abychom odpískali Mainline vývoj. Ano skutečně je, ovšem za předpokladu, že nepřehodnotíme naše vnímání hlavní vývojové větve. Mainline totiž vyžaduje úplně jiný přístup. Zkusím tento přístup popsat změnou charakteristikou hlavní vývojové větve.

Před
Hlavní vývojová větev obsahuje kód, který prošel code review a nemělo by se na něm nic zásadního měnit pokud nedojde k požadavků na změnu chování a nebo k opravě chyby. Provedené změny odrážejí koncový stav dané funkcionality.
Po
Hlavní vývojová větev obsahuje kód, o kterém víme, že je kompilovatelný, a prošel přes automatické kontroly kvality - testy, měření pokrytí testy, analýza závislosti. Změny v hlavní vývojové větvi mohou být většího rozsahu. Rozhraní mez jednotlivými částmi zůstává pokud možno stabilní, mění se implementace a to často.

Velký otazník visí nad tím, jak dělat code review. Můj původní názor byl nechat code review jako dobrovolnou položku. Další možností bylo používat systém pull requests. Tedy uděláte změnu, vygenerujete pull request, ten někdo zkontroluje a zamerguje. Dále se nabízí různé hybridy např. opravy chyb mergovat automaticky nové vlastnosti přes pull request. Ani jedna z těch možností se mi moc nezamlouvá, protože se tím opět prodlužuje doba začlenění do hlavní vývojové větve a tím pádem doba kdy dojde k integraci se zbytkem systému.

Řešení spatřuji v odložení code review až na okamžik, kdy bude v hlavní vývojové větvi celá funkcionalita. Požadavky z code review lze provádět inkrementálně v hlavní vývojové větvi. Funkcionalita zůstává zakryta dokud nejsme všichni spokojeni s výslednou kvalitou. U opravy chyb bychom měli být schopni udělat jednoduše odstranění změny (revert commit) pokud se nám něco nebude zdát (postupujeme podle changelogu).

Když nad tím přemýšlím, pak při Mainline se kvalita zajišťuje zpětně, až po provedení změny dochází k procesu, který by měl zaručit její kvalitu. U Feature branch se naopak kvalitu snažíme zajistit dopředně, tedy změny nejdříve projdou procesem, který by měl zaručit jejich kvalitu. Ve výsledku nám oba přístupy umožňují velice snadné odstranění změny.

Technické předpoklady pro Mainline vývoj

Vývoj do hlavní vývojové větve předpokládá rychlou a kvalitní zpětnou vazbu o výsledku změn, které jsme provedli. Na řadu přichází něco, čemu se říká commit stage. Commit stage je v podstatě část buildu, kterou musí úspěšné projít každá změna a výsledkem by měly být binární artefakty, které se použijí v dalších fázích (integrační testy, manuální testy). Pokud neprojde, mělo by dojít k její opravě a nebo odstranění (revertu) v co nejkratším možném času. V Commit stage by měla být minimálně kompilace, unit testy a produkování binárních artefaktů. K tomu můžeme přidat například analýzu závislostí u Maven modulů a nebo měření pokrytí testy.

Závěr

V tomto článku jsem se pokusil nastínit problematiku Mainline vývoje, který malým krůčkem je Continuous Delivery. Zároveň bych se s vámi v sérii dalších článků rád podělil o dalším směřování tohoto úsilí.