Co je pracovní postup založený na vydávání verzí?
Zde probereme, jak můžete vytvořit pracovní postup založený na vydávání verzí pomocí GitHubu.
Co je pracovní postup založený na vydávání verzí?
Pracovní postup založený na vydaných verzích je sada vzorů a zásad, které se zaměřují na vydávání softwaru. I když se tento pojem může zdát jako jasný cíl vývojového týmu, hodnota tohoto pohledu je nuančí. V této lekci probereme, jak řídí tři různé části cyklu vydávání verzí: správu projektu, výběr strategie větvení a vydání zákazníkům.
Plánování práce pomocí panelů projektu na GitHubu
Když se soustředíte na vydávání verzí, pak to z hlediska plánování znamená, že problémy jsou rozděleny do odlišných iterací, ze kterých vznikne nová verze. Tyto iterace se často označují jako sprinty a jsou časově nastavené v přibližně stejných obdobích, aby se vytvořily přírůstkové změny. Jiné týmy dávají přednost tomu, že všechny verze vydání zahrnou do jedné iterace, která může trvat několik měsíců nebo déle. Na GitHubu mají tyto iterace podobu projektů.
Dominantním rysem projektu je jeho panel. Tento panel je centrálním plánem iterace a obsahuje všechny karty, které se mají vyřešit. Karta může představovat problém, žádost o přijetí změn nebo jen obecnou poznámku.
Každá karta standardně začíná ve sloupci To do (Úkoly) a po zahájení prací se přesune do sloupce In progress (Probíhá), až nakonec skončí ve sloupci Done (Hotovo). Tyto sloupce můžete přizpůsobit, přidat další sloupce nebo použít automatizaci pro přesun těchto karet a jejich vlastnosti tak, aby vyhovovaly procesu vašeho týmu.
Přečtěte si další informace o správě panelů projektu.
Stav projektu dané karty je integrovaný v rámci úložiště. Například přetažením karty z akce To do to Probíhá změníte jeho stav a aktualizuje se vizuální indikátor vedle názvu projektu. Zelený úsek vyjadřuje skupinu karet označených jako Done (Hotovo), zatímco fialová se používá pro karty označené jako In progress (Probíhá). Zbývající místo představuje počet karet, na kterých se teprve začne pracovat. Kromě přetahování karet kolem panelu je můžete aktualizovat z hlavního zobrazení.
Když používáte panel projektů, mají všichni účastníci snadný způsob, jak pochopit stav a rychlost projektu. Můžete také vytvořit panely, které jsou vymezeny na individuální uživatele nebo kolekci úložišť vlastněných organizací.
Přečtěte si další informace o sledování průběhu prací pomocí panelů projektu.
Sledování konkrétních milníků
Pro týmy nebo podmnožiny týmů nabízí GitHub sledování milníků.
Milníky se podobají sledování projektů v tom, že se klade důraz na prioritní dokončení problémů a žádostí o přijetí změn. Pokud se ale projekt může zaměřit na proces týmu, milník se zaměřuje na produkt.
Přečtěte si další informace o sledování průběhu prací pomocí milníků.
Výběr strategie větvení
Úložiště, na kterých souběžně pracuje několik vývojářů, potřebují dobře definovanou strategii větvení. Řešení jednotného přístupu na začátku projektu šetří nejasnosti a frustraci v rámci škálování týmu a základu kódu.
Pracovní postup GitHubu
Kromě platformy pro společný vývoj softwaru nabízí GitHub také předepsaný pracovní postup, který je navržený pro optimální využití všech jeho různých funkcí. I když GitHub může pracovat s prakticky jakýmkoli procesem vývoje softwaru, doporučujeme zvážit tok GitHubu, pokud se váš tým ještě nezarovná na procesu.
Práce s dlouhodobými větvemi
Dlouhodobá větev je větev Gitu, která se nikdy neodstraní. Některé týmy dávají přednost tomu, aby se jim úplně vyhnuly ve prospěch krátkodobých funkcí a větví oprav chyb. Cílem úsilí těchto týmů je vytvoření žádosti o přijetí změn, která jejich práci sloučí zpět do větve main. Tento přístup může být efektivní pro projekty, které nemají potřebu se vracet zpět, jako jsou webové aplikace první strany, které nepodporují předchozí verzi.
V určitých situacích ale dlouhodobá větev slouží nejlepším zájmům týmu. Nejběžnějším případem dlouhodobé větve je situace, kdy má produkt několik verzí, které se musí dlouhodobě podporovat. Když tým potřebuje plánovat s ohledem na tento závazek, mělo by úložiště dodržovat standardní konvenci, například release-v1.0, release-v2.0 atd. Tyto větve by se také měly v GitHubu označit jako chráněné, aby byl přístup k zápisu řízený a nechtěně odstraněny.
Týmy by stále měly udržovat main jako kořenovou větev a slučovat změny ve větvi vydání verze, pokud zapadají do budoucnosti projektu. Když nastane čas, měla by z větve release-v3.0 vzniknout větev main, aby údržbové práce na větvi release-v2.0 nekomplikovaly úložiště.
Údržba dlouhodobých větví
Předpokládejme, že oprava chyby byla sloučena do větve release-v2.0 a potom znovu sloučena do větve main. Později se zjistilo, že tato chyba také existovala ve release-v1.0 větvi a oprava byla potřeba backportovat pro zákazníky, kteří tuto verzi stále používají. Jaký je nejlepší způsob, jak tuto opravu přeportovat?
main Sloučení větve release-v1.0 dolů by nebylo proveditelnou možností, protože by obsahovalo významný počet potvrzení, která nebyla určena k tomu, aby byla součástí této verze. Z stejného důvodu by opětovné sestavení release-v1.0 aktuálního main potvrzení nebylo možností.
Alternativní možností by bylo ručně znovu implementovat opravu ve větvi release-v1.0, tento přístup by ale vyžadoval spoustu předělávek a při existenci několika verzí by nebyl schůdný. Git ale nabízí automatizované řešení tohoto problému ve formě příkazu cherry-pick.
Co je příkaz Gitu cherry-pick?
git cherry-pick je příkaz, který umožňuje aplikovat konkrétní potvrzení z jedné větve do druhé. Jednoduše iteruje vybraná potvrzení a aplikuje je v cílové větvi jako nová potvrzení. Před dokončením zpětné portace mohou vývojáři v případě potřeby sloučit jakékoli konflikty.
Přečtěte si další informace o příkazu Gitu cherry-pick.
Vydání verze pro zákazníky
Když je verze produktu připravena k vydání, zjednodušuje GitHub proces jejího zabalení a informování uživatelů.
Vytvoření verze je stejně jednoduché jako vyplnění formuláře:
- Zadejte značku Gitu, která se má použít a která by měla dodržovat sémantiku správy verzí, například
v1.0.2. GitHub se o vytvoření zadané značky Gitu postará. - Zadejte název vydání verze. Mezi běžné postupy patří:
- Použití popisného názvu
- Použití verze Gitu
- Stručné shrnutí toho, jak se verze změnila od předchozí verze
- Použití názvu kódu nebo náhodné fráze
- Zadejte poznámky k verzi. Tuto úlohu můžete automatizovat pomocí aplikace Release Drafter, která analyzuje změny od předchozí verze a obsahuje přidružené názvy žádostí o přijetí změn.
- Pokud chcete v rámci vydání poskytnout soubory, jako jsou předem připravené instalační programy, můžete je přetáhnout do formuláře. Zdrojový kód nemusíte balit, protože GitHub to udělá automaticky za vás.
- Určete, jestli je verze předběžná, zaškrtnutím příslušného políčka. Tato indikace pomáhá zákazníkům vyhnout se předběžným verzím, pokud chtějí.
Po publikování verze obdrží všichni uživatelé, kteří sledují úložiště, oznámení.
Přečtěte si další informace o vydávání verzí na GitHubu.