Wat is een werkstroom die gebaseerd is op een release?
Hier wordt beschreven hoe u een werkstroom met behulp van GitHub kunt maken die is gebaseerd op een release.
Wat is een werkstroom die gebaseerd is op een release?
Een werkstroom op basis van een release is een set patronen en beleidsregels die zich richten op het vrijgeven van software. Hoewel dit idee misschien een duidelijk doel voor een ontwikkelingsteam lijkt, is de waarde van dit perspectief genuanceerder. In deze les bespreken we hoe het drie verschillende onderdelen van de releasecyclus aanstuurt: het beheren van het project, het selecteren van een vertakkingsstrategie en het vrijgeven aan klanten.
Werkzaamheden plannen met GitHub-projectborden
Met betrekking tot de planning betekent een releasegerichte aanpak dat problemen worden opgesplitst in verschillende iteraties die een nieuwe versie produceren. Deze iteraties worden vaak sprints genoemd en worden in ongeveer gelijke perioden in een time-box geplaatst om incrementele wijzigingen te produceren. Andere teams geven er de voorkeur aan om een hele releaseversie te verpakken in één iteratie die een paar maanden of langer kan duren. In GitHub worden deze iteraties beheerd als projecten.
De dominante functie van een project is het bijbehorende bord. Het bord is het centrale plan van aanpak voor de iteratie en bevat alle kaarten die moeten worden opgelost. Een kaart kan een probleem, een pull-aanvraag of zelfs een algemene opmerking vertegenwoordigen.
Elke kaart start standaard in de kolom Te doen en verplaatst naar In uitvoering zodra de werkzaamheden starten, voordat deze eindigt in de kolom Voltooid. U kunt deze kolommen aanpassen, meer kolommen toevoegen of automatisering toepassen op het verplaatsen van deze kaarten en hun eigenschappen, zodat deze passen bij het proces van uw team.
Meer informatie over het beheren van projectborden.
De projectstatus van de kaart is geïntegreerd in de opslagplaats. Als u bijvoorbeeld een kaart sleept van Taken naar Wordt uitgevoerd , wordt de status ervan gewijzigd en wordt de visuele indicator naast de titel van het project bijgewerkt. Het groene gedeelte geeft aan welk deel van de kaarten is gemarkeerd als Gereed. Paars wordt gebruikt voor kaarten met de status Wordt uitgevoerd. De resterende ruimte staat voor het aantal kaarten dat nog moeten beginnen. Naast het slepen van kaarten rond het bord, kunt u ze bijwerken vanuit hun hoofdweergave.
Wanneer u een projectbord gebruikt, hebben alle belanghebbenden een eenvoudige manier om de status en snelheid van een project te begrijpen. U kunt ook kaarten maken die zijn afgestemd op individuele gebruikers of op een verzameling opslagplaatsen die eigendom zijn van een organisatie.
Meer informatie over het gebruik van projectborden om de voortgang van uw werk bij te houden.
Specifieke mijlpalen bijhouden
Voor teams, of mogelijk subsets van teams, biedt GitHub de mogelijkheid om mijlpalen bij te houden.
Mijlpalen zijn vergelijkbaar met het bijhouden van projecten, omdat er nadruk ligt op de prioriteitsvoltooiing van problemen en pull-aanvragen. Wanneer een project echter mogelijk gericht is op het proces van het team, is er een mijlpaal gericht op het product.
Meer informatie over het gebruik van mijlpalen om de voortgang van uw werk bij te houden.
Een vertakkingsstrategie selecteren
Opslagplaatsen waarin tegelijkertijd meerdere ontwikkelaars werken, vereisen een goed gedefinieerde vertakkingsstrategie. Het vaststellen van een uniforme aanpak aan het begin van het project bespaart verwarring en frustratie naarmate het team en de codebase groter worden.
De GitHub-flow
Naast een platform voor gezamenlijke softwareontwikkeling biedt GitHub ook een voorgeschreven werkstroom die ervoor zorgt dat u optimaal gebruik kunt maken van de verschillende functies. Hoewel GitHub met vrijwel elk softwareontwikkelingsproces kan werken, raden we u aan de GitHub-stroom te overwegen als uw team nog niet is geregeld voor een proces.
Werken met langlopende vertakkingen
Een langlopende vertakking een Git-vertakking die nooit wordt verwijderd. Sommige teams vermijden ze liever helemaal en kiezen voor kortdurende feature- en bugfix-branches. Voor die teams ligt het doel van elke inspanning erin om een pull-verzoek te maken waarmee hun werk wordt samengevoegd in main. Deze aanpak kan effectief zijn voor projecten die nooit hoeven terug te kijken, zoals webtoepassingen van derden die geen ondersteuning bieden voor een eerdere versie.
Er zijn echter bepaalde scenario's waarbij een vertakking met een lange levensduur de belangen van een team het beste dient. Een langlopende vertakking wordt meestal gebruikt wanneer een product meerdere versies heeft die voor een langere periode moeten worden ondersteund. Wanneer een team een dergelijke commitment moet plannen, moet de opslagplaats een standaardconventie volgen, zoals release-v1.0, release-v2.0 enzovoort. Deze vertakkingen moeten ook worden gemarkeerd als beveiligd in GitHub, zodat schrijftoegang wordt beheerd en ze niet per ongeluk kunnen worden verwijderd.
Teams moeten main als hoofdvertakking bewaren en de wijzigingen in hun releasevertakking upstream invoegen, zolang ze in de toekomst van het project passen. Te zijner tijd moet release-v3.0 worden gebaseerd op main, zodat het onderhoudswerk voor release-v2.0 geen complicaties veroorzaakt in de repository.
Langlopende branches onderhouden
Stel dat er een bugfix is toegevoegd aan de release-v2.0-branch en vervolgens upstream opnieuw is ingevoegd in main. Het werd later ontdekt dat deze fout ook bestond in de release-v1.0 vertakking en dat de oplossing moest worden teruggevoerd voor klanten die deze versie nog steeds gebruiken. Wat is de beste manier om deze oplossing te backporteren?
Het samenvoegen van de main vertakking naar release-v1.0 zou geen haalbare optie zijn, omdat deze een aanzienlijk aantal doorvoeringen zou bevatten die niet bedoeld waren om deel uit te maken van die versie. Vanwege dezelfde reden zou rebasen van release-v1.0 naar de huidige main commit geen optie zijn.
Een andere mogelijkheid is om de oplossing handmatig opnieuw te implementeren voor de vertakking release-v1.0, maar die benadering vergt een hoop extra werk en kan niet goed worden geschaald voor meerdere versies. Git biedt echter een geautomatiseerde oplossing voor dit probleem in de vorm van de opdracht cherry-pick.
Wat is de Git-opdracht "cherry-pick"?
git cherry-pick is een opdracht waarmee u specifieke commits van de ene vertakking naar de andere kunt toepassen. De geselecteerde wijzigingen worden eenvoudigweg herhaald en als nieuwe doorvoer toegepast op de doelvertakking. Indien nodig kunnen ontwikkelaars eventuele conflicten samenvoegen voordat de backport wordt voltooid.
Meer informatie over Git's cherry-pick.
Vrijgeven voor consumenten
Zodra een versie van een product kan worden vrijgegeven, vereenvoudigt GitHub het proces waarbij de release wordt verpakt en consumenten worden geïnformeerd.
Het maken van een versie is net zo eenvoudig als het invullen van het formulier:
- Voer de Git-tag in die u wilt toepassen. Deze moet de semantische versietoewijzing volgen, zoals
v1.0.2. GitHub beheert het proces voor het maken van Git-tag die u hebt opgegeven. - Voer een naam in voor uw release. Enkele veelvoorkomende procedures zijn:
- Een beschrijvende naam gebruiken
- De Git-versie gebruiken
- Gebruik een beknopt overzicht van hoe de release is gewijzigd sinds de vorige versie
- Een codenaam of willekeurige woordgroep gebruiken
- Voeg releaseopmerkingen toe. U kunt deze taak automatiseren met de Release Drafter-app, die de wijzigingen analyseert sinds de vorige versie en de bijbehorende pull-aanvraagtitels bevat.
- Als u bestanden wilt opgeven als onderdeel van de release, zoals vooraf gemaakte installatieprogramma's, kunt u ze naar het formulier slepen en neerzetten. U hoeft de bron niet te verpakken, aangezien GitHub dit automatisch voor u doet.
- Geef aan of de versie vooraf beschikbaar is door dat selectievakje in te schakelen. Deze indicatie helpt klanten om voorlopige versies te voorkomen, als ze dat willen.
Zodra een release is gepubliceerd, ontvangt iedereen die de opslagplaats bekijkt een melding.
Meer informatie over GitHub-releases.