[Git] Onderhouden verschillende versies voor branches

[CurlyMo]

Op dit moment ontwikkel ik software waarbij de broncode op git staat. Daarbij volg ik het model met daarbij in de kern 2 branches: master en development.

In de master branch staan de stabiele versies, en in het verleden hernoemde ik bij een nieuwe versie development naar master begon een nieuwe development branch. Er werd tevens een tag aangemaakt voor de nieuwe versie.

Oftewel, development lag altijd voor op master.

Van de development branch wordt tot nu toe automatisch een nightly versie gepackaged, gebaseerd op het versienummer van master. Bijv: 7.0-35-gdik3nd7e. Dit betekent dan de 35ste commit in development met SHA dik3nd7e na versie 7.0 in master.

Een van de problemen waar ik tegenaan loop is dat ik te lang wacht met een nieuwe release. Dat komt omdat ik op allerlei verschillende plekken verbeteringen aan het aanbrengen ben in mijn software, maar niet alle verbeteringen zijn daarbij even release waardig.

Mijn idee was vervolgens om de commits uit development te cherry-picken naar master en daarmee een nieuwe release te maken. Zo kan ik nieuwe code die stabiel is gevonden vanuit de nightly gebruikers sneller vrijgeven in een nieuwe master versie. Het probleem is dan alleen dat master en development asynchroon gaan lopen. Niet alle commits uit development zijn dan te vinden in specifieke master versie.

Huidige situatie

Development

code:

123456 commit 1 <-- versie 1.0
234567 commit 2 <-- versie 1.0-2-234567 
345678 commit 3 <-- versie 1.0-3-345678 
456789 commit 4 <-- versie 2.0
567890 commit 5 <-- versie 2.0-1-567890

Master

code:

123456 commit 1 <-- versie 1.0
234567 commit 2
345678 commit 3
456789 commit 4 <-- versie 2.0

Nieuwe idee

Master

code:

123456 commit 1 <-- versie 1.0
345678 commit 3
456789 commit 4 <-- versie 2.0
234567 commit 2
567890 commit 5 <-- versie 3.0

Development

code:

123456 commit 1 <-- versie 1.0
234567 commit 2 <-- versie 1.0-1-234567
345678 commit 3 <-- versie 1.0-2-345678
456789 commit 4 <-- versie 2.0
567890 commit 5 <-- versie 3.0

In de nieuwe logica met cherry-picking weet ik dus niet hoe ik het beste met de versie nummers van development om moet gaan. Commit 2 is geautomatiseerd gepackaged in een nightly versie leidende tot versie 2.0, terwijl die commit pas in 3.0 wordt opgenomen. De versie nummering van development loopt dan helemaal niet meer in lijn met die van master.

Is er dus een slimme manier om een development branch te hebben waarin ik door ontwikkel en die in CI (inclusief nightly packaging en release) staat en waar ik asynchroon uit cherry-pick voor nieuwe stabiele releases?

Mogelijke zelfbedachte oplossingen:

Een van de oplossingen is het automatisch packagen van mijn development branch uit te zetten en i.p.v. daarvan veel vaker een nieuwe master versie uit te brengen. De nightlies hebben echter het voordeel van de collectieve tests door alle gebruikers die geabonneerd zijn op deze nightlies, waardoor bugs sneller naar boven komen.

Een ander oplossing is te zorgen dat development altijd één versie voor loopt op de master. Als de laatste master dus versie 7.0 (incl. tag) is, dan wordt development automatisch versie 8.0-nightly (incl. tag), en dan volgens dezelfde versienummering als hierboven beschreven. Op het moment dat er een nieuwe master komt, dan wordt de oude 8.0-nightly tag verwijderd en een nieuwe 8.0 versie + tag aangemaakt voor master. Ook start er een nieuwe 9.0-nightly + tag. Je houdt wel het probleem dat niet alles wat ik een 8.0-nightly aanwezig was ook daadwerkelijk in een 8.0 master wordt overgenomen en dus de nightly versies asynchroon blijven aan master.

[orf]

Heb je hier wel eens naar gekeken? En dan met name feature branches.

The core idea behind the Feature Branch Workflow is that all feature development should take place in a dedicated branch instead of the master branch. This encapsulation makes it easy for multiple developers to work on a particular feature without disturbing the main codebase. It also means the master branch will never contain broken code, which is a huge advantage for continuous integration environments.

The Feature Branch Workflow still uses a central repository, and master still represents the official project history. But, instead of committing directly on their local master branch, developers create a new branch every time they start work on a new feature. Feature branches should have descriptive names, like animated-menu-items or issue-#1061. The idea is to give a clear, highly-focused purpose to each branch.

[Tk55]

Hoeveel waarde hecht je aan hele versienummers? Je kan natuurlijk altijd .1 (7.1, 7.2, 8.0, 8.1, etc) releases maken met kleine aanpassingen.

En feature branches werken natuurlijk ook.

[Ramon]

CurlyMo schreef op zondag 15 oktober 2017 @ 16:49:
Een van de problemen waar ik tegenaan loop is dat ik te lang wacht met een nieuwe release. Dat komt omdat ik op allerlei verschillende plekken verbeteringen aan het aanbrengen ben in mijn software, maar niet alle verbeteringen zijn daarbij even release waardig.

Is de oplossing dan niet gewoon om vaker nieuwe releases te maken? In plaats van je hele workflow aan te passen?

Cherry picken zou ik overigens niet doen, dat is veel te werk-intensief voor een release en als je net een commit vergeet dan is je master branch ineens stuk ofzo. Ik zie cherry picken meer voor incidenteel gebruik.

[CurlyMo]

orf schreef op zondag 15 oktober 2017 @ 16:59:
Heb je hier wel eens naar gekeken? En dan met name feature branches.

Het grote verschil met wat ik nu is dus dat ik alle development in één aparte branch doe i.p.v. per development feature een aparte branch, oftewel de gitflow workflow. Lastige van de feature branch is dan weer dat dat (volgens mij) breekt met mijn huidige nightly packages of snapshots.

Tk55 schreef op zondag 15 oktober 2017 @ 16:59:
Hoeveel waarde hecht je aan hele versienummers? Je kan natuurlijk altijd .1 (7.1, 7.2, 8.0, 8.1, etc) releases maken met kleine aanpassingen.

Niet veel, maar ook subnummers lossen mijn probleem niet op.

Ramon schreef op zondag 15 oktober 2017 @ 17:23:
[...]

Is de oplossing dan niet gewoon om vaker nieuwe releases te maken? In plaats van je hele workflow aan te passen?

Vanzelfsprekend, maar een release vind ik arbeidsintensief Lekker ontwikkelen en pushen naar de development branch is lekker makkelijk (in mijn huidige setup).

Cherry picken zou ik overigens niet doen, dat is veel te werk-intensief voor een release en als je net een commit vergeet dan is je master branch ineens stuk ofzo. Ik zie cherry picken meer voor incidenteel gebruik.

Mijn idee was dus om te blijven ontwikkelen in development, maar vaker onderdelen naar master te brengen via cherry-picking. Ik zit nu dus op zo'n moment dat ik eigenlijk een stable wil releasen, maar niet met alle features die in development zitten.

[Ramon]

CurlyMo schreef op zondag 15 oktober 2017 @ 17:44:
[...]

Het grote verschil met wat ik nu is dus dat ik alle development in één aparte branch doe i.p.v. per development feature een aparte branch, oftewel de gitflow workflow. Lastige van de feature branch is dan weer dat dat (volgens mij) breekt met mijn huidige nightly packages of snapshots.


[...]

Niet veel, maar ook subnummers lossen mijn probleem niet op.


[...]

Vanzelfsprekend, maar een release vind ik arbeidsintensief Lekker ontwikkelen en pushen naar de development branch is lekker makkelijk (in mijn huidige setup).


[...]

Mijn idee was dus om te blijven ontwikkelen in development, maar vaker onderdelen naar master te brengen via cherry-picking. Ik zit nu dus op zo'n moment dat ik eigenlijk een stable wil releasen, maar niet met alle features die in development zitten.

Als je feature branches gebruikt kan je nog steeds een nightly releasen. Maar je merged je feature branches gewoon wat later, als je zekerder bent dat ze in orde zijn. Zo voorkom je dat je development branch dingen bevat die je niet in een nightly wil hebben. En door je development branch schoon te houden kan je veel makkelijker mergen met master voor een release.

[CurlyMo]

Ramon schreef op zondag 15 oktober 2017 @ 18:59:
[...]

Als je feature branches gebruikt kan je nog steeds een nightly releasen. Maar je merged je feature branches gewoon wat later, als je zekerder bent dat ze in orde zijn. Zo voorkom je dat je development branch dingen bevat die je niet in een nightly wil hebben. En door je development branch schoon te houden kan je veel makkelijker mergen met master voor een release.

Ik snap het. Het is dan sowieso goed om nog een aparte branch te hebben waarin je het echt ruwe werk neerzet en die niet in een CI of nightly straat zit. Een beetje een alpha, beta en stable opstellen, waarbij alleen beta en stable in een volledige CI straat zitten met automatische packages.

[P_Tingen]

CurlyMo schreef op zondag 15 oktober 2017 @ 19:03:
[...]
Ik snap het. Het is dan sowieso goed om nog een aparte branch te hebben waarin je het echt ruwe werk neerzet en die niet in een CI of nightly straat zit. Een beetje een alpha, beta en stable opstellen, waarbij alleen beta en stable in een volledige CI straat zitten met automatische packages.

Nee, dat hoeft dus niet. Dat ruwe werk doe je dan in de feature branches. Elk wild idee dat je hebt en wilt implementeren doe je in een aparte feature branch, elke fout die je op wil lossen ook. Deze branches splits je af van je develop branch en als ze klaar zijn merge je ze weer terug. Je develop branch is dus altijd een werkende versie die voorloopt op productie. Enige kanttekening is dat develop mogelijk nog bugs bevat die jij niet hebt gevonden. Het idee is dat je je werk aan verschillende ideeën gescheiden houdt. Mocht je op een zeker moment bedenken dat een bepaalde feature niet gaat vliegen, dan delete je de branch en hoef je verder niets te herstellen.

Een alpha branch voegt in jouw geval (denk ik) niet zoveel toe. Je hebt je aparte features en als die klaar zijn merge je ze terug naar develop. In principe is develop dan je beta en je zou er een tag op kunnen plaatsen. Zo doe ik dat met mijn hobbyproject wel in ieder geval.

[ Voor 11% gewijzigd door P_Tingen op 16-10-2017 08:48 ]

[ThomasG]

P_Tingen schreef op maandag 16 oktober 2017 @ 08:46:
[...]

Een alpha branch voegt in jouw geval (denk ik) niet zoveel toe. Je hebt je aparte features en als die klaar zijn merge je ze terug naar develop. In principe is develop dan je beta en je zou er een tag op kunnen plaatsen. Zo doe ik dat met mijn hobbyproject wel in ieder geval.

Alpha/beta branches zijn bij CI ook eigenlijk obsolete. Ze hebben enkel nut als je bepaalde builds door een groep testen (bijvoorbeeld het testen van bepaalde features). Anders heb je aan een werkende develop branch (i.e. het compiled, en unit/integration tests slagen; door te werken op aparte branches) voldoende. Die kun je dan bijvoorbeeld automatisch laten builden en packagen.

[CurlyMo]

ThomasG schreef op maandag 16 oktober 2017 @ 09:44:
[...]
Ze hebben enkel nut als je bepaalde builds door een groep testen (bijvoorbeeld het testen van bepaalde features).

Dit nut heeft zich bij mijn project toch al best vaak bewezen.

[ThomasG]

CurlyMo schreef op maandag 16 oktober 2017 @ 09:47:
[...]

Dit nut heeft zich bij mijn project toch al best vaak bewezen.

In zulke gevallen wil je er (mijn inziens) toch enige controle over hebben (niet tijdens het testproces de builds veranderen, e.d.). Je wilt de alpha en/of beta builds dan zelf maken. Je kunt dan naast develop een extra branch hebben, waarbij je bijvoorbeeld een keer in de week een stabiele develop build in merged.

[ Voor 6% gewijzigd door ThomasG op 16-10-2017 09:53 ]

[Kontsnorretje]

Ik zou zelf zoals hierboven een branche-per-feature gaan gebruiken. Maar is het in jou geval niet een optie om 2 feature branches in het leven te roepen.
feature/wel-releasewaardig
feature/niet-releasewaardig

Op wel-releasewaardig commit je alle wijzigingen die je wilt releasen, en merge je naar master en niet-releasewaardig. Dit kan per 'feature', of na een verzameling hiervan.

Op niet-releasewaardig verzamel je niet releasewaardige fixes. Op het moment dat je deze toch een keer wil releasen, merge je naar wel-releasewaardig, en die merge je weer naar en master.

Hiermee vervang je je develop branche door deze 2 branches.


Daarnaast levert cherry picking dubbele commits op die je eventueel weer moet rebasen. Dat is over het algemeen niet gewenst.

[ Voor 9% gewijzigd door Kontsnorretje op 16-10-2017 19:08 ]