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. V GitHubu se tyto iterace spravují jako projekty.
Dominantním rysem projektu je jeho rada. Deska je centrální plán záznamů pro iteraci a obsahuje všechny karty, které mají být vyřešeny. Karta může představovat problém, žádost o přijetí změn nebo jen obecnou poznámku.
Ve výchozím nastavení se každá karta spustí ve sloupci K vyřízení a po zahájení práce přejde do Probíhající před skončením v Dokončeno. 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ů projektů.
Stav projektu dané karty je integrovaný v rámci úložiště. Například přetažením karty z Ke splnění do Probíhá změníte její stav a aktualizuje se vizuální indikátor vedle názvu projektu. Zelený oddíl označuje část karet označených jako Hotovo, zatímco fialová je použita pro karty 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 práce s panely projektů.
Sledování konkrétních milníků
GitHub nabízí sledování milníků pro týmy nebo možná podmnožinu týmů.
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 práce s milníky.
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í. Ačkoli GitHub může pracovat s prakticky jakýmkoli procesem vývoje softwaru, doporučujeme zvážit GitHub flow, pokud váš tým ještě nezvolil konkrétní proces.
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 cherry-pick v Gitu.
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, kterou chcete použít a která by měla dodržovat sémantické verzování, 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 verzích GitHubu.