Na navigaci | Klávesové zkratky

Translate to English… Ins Deutsche übersetzen…

Alpha-beta-RC is so 20th century

Přestanu používat při vývoji označení testovacích fází alpha/beta/RC a nahradím ho jedním slovem.

Existuje řada způsobů, jak software verzovat. U knihoven se často hovoří o sémantickém verzování, kdy verzi reprezentuje trojice čísel major.minor.patch, a hlavní číslo major musí být zvýšeno pokaždé, když se v kódu objeví zpětně nekompatibilní změna. Což zní na první pohled rozumně, ale z mnoha důvodů to takřka nikdo 100% nedodržuje.

Taktéž existují různé způsoby, jak označovat jednotlivé fáze vývoje, z nichž nejznámější je asi slovní označení alpha/beta/RC. V beta fázi by měl být produkt kompletní co se vlastností týče a dále by se měly opravovat chyby, ladit kompatibilita atd. K čemuž se opět přistupuje různě, asi největším extrémem jsou věčné bety, které zpopularizoval Google. Opačným případem je prohlížeč Chrome, který přišel se zrychleným vydáváním verzí a přelévá mezi kanály dev/beta/stable.

Jak vidno, přístupy se u jednotlivých projektů značně liší. Záleží na mnoha faktorech, velikostí týmu počínaje, marketingem konče. Pro mě je prioritou, aby systém vedl k:

  • vydávání odladěných major & minor verzí
  • při maximální snaze zachovat zpětnou kompatibilitu
  • a pokud možno v pravidelných intervalech, včetně přísunu novinek

Což se lehko řekne, mnohem těžší je se k tomu dobrat, navíc aby to bylo v lidských silách.

Flow, které mi celkem vyhovuje a uvedené priority vesměs plní, vypadá následovně:

  1. vývoj probíhá neprve ve větvích (buď veřejně v podobě pull requestů nebo lokálně)
  2. mergnutím do masteru (což je vlastně permanentní alpha-verze) začíná testování. Přičemž žádný commit nesmí rozbít testy, ale může narušit zpětnou kompatibilitu (viz dále)
  3. jednou za půl roku až rok bych rád vydal větší verzi:
    • vytvořím release-větev s názvem jako v3.2
    • musím rozhodnout, které věci vynechat (revert) a které přidat (merge pull requestů a lokálních větví)
    • především však udělat co nejvíc pro zachování kompatibility rozbité v bodě 2)
    • v krátkých intervalech vydávat testovací verze reagující na chyby a připomínky (což bývá zápřah)
  4. a pak po dlouhou dobu udržovat verzi čerstvou
    • cherry-pickováním oprav z masteru (nebo naopak, ale výjimečně někdo připraví pull request oproti release-větvi)
    • vyhýbat se BC breakům (byť je někdy značně ošidné rozlišit, co BC break je)
    • vydávat patch verze (tj. setinkové) v krátkých intervalech

Někomu to připadá jako úplně normální postup, jiní zase brblají, takže musím zmínit, na jaká v reálu narážím úskalí.

S každými novinkami přichází (byť třeba jen hypotetické) BC breaky. To je prostě realita. Přičemž zachovávání kompatibility beru jako velmi důležitou věc a stojí mě tak 70 % času investovaného do vývoje. Je taky nejčastějším důvodem, proč otálím s přidáním nových věcí. V případě Texy to vedlo v podstatě až k ukončení vývoje.

Existuje dost frameworků, které přežily tlustou čáru mezi dvěma major verzemi. Já ji ale dělat nechci. Nechci ani utopit vývoj. Kloním se proto k postupným zdokumentovaným BC breakům u větších verzí. Navádím uživatele co změnit pomocí E_USER_DEPRECATED hlášek. Nejvýhodnější situaci tak mají ti, kteří průběžně updatují.

Nicméně dle sémantického verzování bych proto měl každého půl roku až rok vydat novou major verzi, což se mi nejeví z řady důvodu praktické. Zejména to vyvolává dojem, že přechod bude velmi náročný a uživatelé začnou setrvávat u starých verzí. Což nechci. Proto raději zvedám jen minor verzi (tj. desetinkovou).

Podle sémantického verzování se novinky mohou objevovat jen v major & minor verzích. Vydávání těchto verzí v intervalech kratších než půl roku vytváří dojem, že vývoj uhání příliš rychle, a uživatelé opět přestávají aktualizovat. Ovšem přijít s užitečnou novinkou a odkládat její vydání i půl roku a více, než bude čas na další větší verzi, nepřináší užitek nikomu, a uživatele toužícího po novince tlačí k používání masteru. Což opět nechci. Takže občas zařadím novinky i do bodu 4). Nepříjemné je, že si kvůli tomu vyslechnete dost kritiky, ještě nepříjemnější je, že po letech jejího permanentního poslouchání už nemáte jakoukoliv schopnost rozlišovat kritiku oprávněnou od kritiky české.

Pokud vydám alpha verzi a poprosím o testování, zhostí se toho naprosté minimum lidí. O moc lépe na tom nejsou ani první beta-verze. Teprve až začnu vydávat RC, na fóru to ožije. Což je mnohokrát ověřený fakt. Nepříjemné je, že i když následně vydáte sebestabilnější verzi, bude vám neustále někdo kazit náladu vysvětlováním, jak to babráte a nerozumíte dělení na alpha/beta/RC. Z jeho pohledu jakoby oprávněně, tudíž jsem se rozhodl, že nebudu nadále rozlišovat tyto fáze, protože to nikomu nic nepřináší, cíli udělat co nejlepší stable podřizuji vše nehledě na fázi, a bude stačit vydávat jen číslované -testing verze (v podstatě beta-verze).

Dává smysl mi ukončit tuto testovací fázi a vydat stable ve chvíli, kdy sám jsem spokojený a reportování chyb poklesne na minimum. Samozřejmě mohl bych pár měsíců čekat, ale realita je taková, že aktivita se nastartuje teprve až vydáním stable.

Ještě jednou to shrnu:

  • master je alpha-verze, do které se dostanou jen nadějné novinky + bugfixy, a bez záruky zpětné kompatibility se tu testují
  • jednou za čas vytvořím release-větev, která po sérii -testing verzí řešících mj. kompatibilitu bude završena rychlým vydáním stable
  • mezi masterem a release-větví cherry-pickuji opravy, občas menší novinky, a vydávám setinkové verze, ideálně s jedním RC

Docela jsem zvědavý, co v případě Nette udělá s uvedeným flow rozdělení na malé projekty. Teoreticky bych mohl najet na rychlé verzování u částí, které se budou vyvíjet, a uživatel by si pomocí Composeru poskládal takové Nette, jaké by chtěl. Zatím ale spíš narážím na nejrůznější překážky a vydávání nových verzí je teď mnohem větší dřina.

Komentáře

  1. Josef Chlachula #1

    avatar

    Možná by bylo užitečné uvést příklad, co by měl uživatel v ideálním případě dělat.

    1. php composer.phar create-project nette/sandbox
    2. přejmenovat adresář sandbox třeba na mujprojekt a zahájit vývoj projektu
    3. co by měl uživatel udělat pro aktualizaci nette?

    V případě, že používá composer, nebo jiné možnosti?
    Děkuji.

  2. David Grudl http://davidgrudl.com #2

    avatar

    #1 Josefe Chlachulo, v adresáři mujprojekt zavoláš composer update

    před 2 lety | odpovědět
  3. Václav Makeš http://www.makes.cz #3

    avatar

    #1 Josefe Chlachulo, Jak psal David, zavolat composer update. Spravovat knihovny jinak než composerem mi dnes nepříjde vhodné.

    před 2 lety | odpovědět

Zanechat komentář

Text komentáře
Kontakt

(kvůli gravataru)



*kurzíva* **tučné** "odkaz":http://example.com /--php phpkod(); \--