Mi az a kiadáson alapuló munkafolyamat?
Ebben a cikkben ismertetjük, hogyan hozhat létre kiadáson alapuló munkafolyamatot a GitHub segítségével.
Mi az a kiadáson alapuló munkafolyamat?
A kiadásalapú munkafolyamatok olyan minták és szabályzatok, amelyek a szoftverek kiadására összpontosítanak. Bár ez az elképzelés nyilvánvaló célnak tűnhet egy fejlesztői csapat számára, ennek a perspektívának az értéke árnyaltabb. Ebben a leckében a kiadási ciklus három különböző részét irányítja: a projekt kezelését, az elágaztatási stratégia kiválasztását és az ügyfelek számára történő kiadást.
A munka megtervezése a GitHub projekttábláival
A tervezői szempontból nézve a kiadásközpontúság azt jelenti, hogy a feladatokat különálló iterációkra bontjuk fel, amelyek mindegyike egy új verziót hoz létre. Ezeket az iterációkat gyakran futamoknak nevezik, és nagyjából egyenlő időszakokban vannak időkeretben, hogy növekményes változásokat eredményezhessenek. Más csapatok a teljes kiadási verziók egyetlen iterációba való becsomagolását részesítik előnyben, amely néhány hónapig, vagy akár tovább is tarthat. A GitHubon ezeket az iterációkat projektekként kezelik.
A projekt domináns jellemzője a testülete. A tábla az iteráció központi rekordterve, és tartalmazza a feloldandó kártyákat . A kártyák jelenthetnek problémát, lekéréses kérelmet vagy csupán egy általános megjegyzést is.
Alapértelmezés szerint minden kártya a Teendő oszlopban kezdődik, majd a munka megkezdése után átkerül a Folyamatban oszlopba, mielőtt a Kész oszlopba kerülne. Ezeket az oszlopokat testre szabhatja, további oszlopokat adhat hozzá, vagy automatizálást alkalmazhat a kártyák mozgására és azok tulajdonságaira a csapat folyamatának megfelelően.
További információ a projekttáblák kezeléséről.
A kártya projektállapota integrálva van az adattárba. Ha például áthúz egy kártyát a Teendő helyről a Folyamatban állapotba , az állapota megváltozik, és frissíti a projekt címe melletti vizualizációjelzőt. A zöld szakasz a készként megjelölt kártyák részét jelöli, míg a folyamatban lévő kártyákhoz lila színt. A fennmaradó terület a még el nem kezdett kártyák mennyiségét jelöli. A kártyák a tábla körüli húzása mellett a fő nézetükből is frissíthetők.
Ha projekttáblát használ, minden érintett könnyen megértheti a projekt állapotát és sebességét. Létrehozhat az egyéni felhasználókra szabott projekttáblákat, illetve létrehozhatja egy szervezet tulajdonát képező adattárak gyűjteményét is.
További információ a projekttáblákkal végzett munka előrehaladásának nyomon követéséről.
Adott mérföldkövek nyomon követése
A csapatok vagy a csapatok esetleges részhalmazai esetében a GitHub mérföldkövető követéseket kínál.
A mérföldkövek hasonlóak a projektkövetéshez, mivel a problémák és lekéréses kérelmek rangsorolása a fontossági sorrendbe van helyezve. Ha azonban egy projekt a csapat folyamatára összpontosít, egy mérföldkő a termékre összpontosít.
További információ a mérföldkövekkel végzett munka előrehaladásának nyomon követéséről.
Elágaztatási stratégia kiválasztása
Azon adattárak esetében, amelyeken több fejlesztő dolgozik egyszerre, pontosan meghatározott elágaztatási stratégiára van szükség. A projekt korai szakaszában egységes megközelítéssel történő megoldás a csapat és a kódbázis skálázása során zavart és frusztrációt takarít meg.
A GitHub-folyamat
Amellett, hogy platformot biztosít az együttműködésen alapuló szoftverfejlesztéshez, a GitHub egy előírt munkafolyamatot is kínál, amely a különböző funkciók használatának optimalizálására szolgál. Bár a GitHub gyakorlatilag bármilyen szoftverfejlesztési folyamattal képes dolgozni, javasoljuk, hogy fontolja meg a GitHub-folyamatot , ha csapata még nem rendeződött el egy folyamaton.
Hosszú élettartamú ágak használata
A hosszú élettartamú ág olyan Git-ág , amely soha nem törlődik. Egyes csapatok inkább a rövid élettartamú funkciók és a hibajavítási ágak mellett részesítik előnyben őket. E csapatok erőfeszítéseinek célja egy olyan lekéréses kérelem létrehozása, amely egyesíti a munkájukat a main ágban. Ez a megközelítés olyan projektek esetében lehet hatékony, amelyeknek soha nem kell visszatekintenie, például olyan belső webalkalmazások esetében, amelyek nem támogatják az előző verziót.
Vannak azonban olyan helyzetek, amelyekben a hosszú élettartamú ág a csapat érdekeit szolgálja. A hosszú élettartamú ágak abban az esetben a leggyakoribbak, amikor egy termék több olyan verzióval rendelkezik, amelyeket hosszabb ideig támogatni kell. Ha a csapatnak egy ilyen kötelezettségvállalás szem előtt tartásával kell terveket készítenie, az adattárnak egy szabványos konvenciót kell követnie, például: release-v1.0, release-v2.0 és így tovább. Ezeket az ágakat a GitHubon is védettként kell megjelölni, hogy az írási hozzáférés szabályozva legyen, és ne lehessen véletlenül törölni őket.
A csapatoknak továbbra is fenn kell tartaniuk a main ágat fő ágként, és a kiadási ág változásait a felsőbb rétegekkel kell egyesíteniük egészen addig, amíg a változások beleillenek a projekt jövőjébe. Ha eljön az ideje, a release-v3.0 alapulhat a main ágon, így a release-v2.0 karbantartása nem bonyolítja az adattárat.
Hosszú élettartamú ágak karbantartása
Tegyük fel, hogy egy hibajavítás lett egyesítve a release-v2.0 ággal, majd előrehaladva ismét egyesítve lett a main ággal. Később kiderült, hogy ez a hiba az release-v1.0 ágban is létezik, és a javítást vissza kellett adni azoknak az ügyfeleknek, akik még mindig használják ezt a verziót. Mi a legjobb módja a javítás visszajelentésének?
Az ág összevonása mainrelease-v1.0 nem lenne megvalósítható megoldás, mivel jelentős számú véglegesítést tartalmazna, amelyek nem tartoznak ebbe a verzióba. Ugyanebből az okból az aktuális release-v1.0 véglegesítésre való újrabehozás main nem lenne lehetőség.
Egy másik lehetőség a javítás manuális újbóli implementálása a release-v1.0 ágra, de ez sok átdolgozással járna, és nem lenne jól skálázható a különböző verziók között. A Git azonban automatizált megoldást kínál erre a problémára a cherry-pick parancs formájában.
Mire szolgál a Git cherry-pick parancsa?
A git cherry-pick egy parancs, amely lehetővé teszi adott véglegesítések alkalmazását az egyik ágról a másikra. Egyszerűen megismétli a kijelölt véglegesítéseket, és új véglegesítésként alkalmazza őket a célágra. Ha szükséges, a fejlesztők egyesíthetik az ütközéseket, mielőtt elérhetővé tennék egy korábbi verzióhoz is.
További információ a Git cherry-pick parancsáról.
Közzététel a fogyasztók számára
Ha a termék verziója készen áll a kiadásra, a GitHub leegyszerűsíti a becsomagolás és a felhasználók értesítésének folyamatát.
Egy verzió létrehozása olyan egyszerű, mint az űrlap kitöltése:
- Adjon meg egy Git-címkét az alkalmazáshoz, amelynek szemantikai verziókövetést kell követnie, például
v1.0.2. A megadott Git-címke létrehozásának folyamatát a GitHub kezeli. - Adja meg a kiadás nevét. Néhány gyakori eljárás:
- Leíró név használata
- A Git-verzió használata
- Röviden összefoglalja, hogyan változott a kiadás az előző verzió óta
- Kódnév vagy véletlenszerű kifejezés használata
- Adja meg a kibocsátási megjegyzéseket. Ezt a feladatot automatizálhatja a Release Drafter alkalmazással, amely elemzi az előző verzió óta történt változásokat, és tartalmazza a kapcsolódó lekéréses kérelmek címét.
- Ha a kiadás részeként szeretné megadni a fájlokat, például az előre összeállított telepítőket, húzhatja őket az űrlapra. Nem kell becsomagolnia a forrást, a GitHub ezt automatikusan elvégzi.
- A jelölőnégyzet bejelölésével jelezheti, hogy a verzió előzetes verziójú-e. Ez a jelzés segít az ügyfeleknek elkerülni az előzetes verziókat, ha szeretnének.
A kiadás közzététele után az adattárat figyelő összes felhasználó értesítést kap.
További információ a GitHub-kiadásokról.