OTAP / DTAP met subversion

[Cavalera125]

Hoe wordt in het algemeen omgegegaan met subversion (of ander versiebeheer) in combinatie met een OTAP straat? Stel je hebt module A, maak je dan voor iedere omgeving uit de OTAP straat een aparte branch?

Hoe gaat men om met verschillende features die tegelijk ontwikkeld worden? Feature 1 en 2 worden tegelijk ontwikkeld. Feature 2 is inmiddels al getest en staat op de T(est) omgeving. Waar staat de bijbehorende code van Feature 2 op dat moment in het versiesysteem?

Het kan zoals ik aangeef, dus een branch per OTAP omgeving waarbij P(roduction) de trunk is, maar ik vraag me af of dit een goed bruikbare methode is en of er wellicht andere / betere methodes zijn die zich al hebben bewezen.

[Kalentum]

Ik heb voor elke feature een aparte branche. Ik kan dan meerdere testomgevingen hebben, voor elke feature 1. Als een feature naar productie mag wordt eerst de trunk in de branche gemerged om te kijken of er conflicten zijn. Dan gaat de hele branche terug naar de trunk.

[Cavalera125]

rutgerw schreef op maandag 05 oktober 2009 @ 17:39:
Ik heb voor elke feature een aparte branche. Ik kan dan meerdere testomgevingen hebben, voor elke feature 1. Als een feature naar productie mag wordt eerst de trunk in de branche gemerged om te kijken of er conflicten zijn. Dan gaat de hele branche terug naar de trunk.

Bij mij is ook iedere feature een aparte branch. Maar hoe beheer je dan je OTAP omgevingen? Hoe zorg je ervoor dat die features op test, acceptatie en productie komen?

Meer concreet, het gaat bij mij om desktop applicatie ontwikkeling. Feature 2 kan naar de acceptatie omgeving (draait bij de klant) en Feature 1 staat nog op de test omgeving. En om het nog iets lastiger te maken staat Feature 3 nog op de ontwikkelomgeving. Hoe beheers je nu de verschillende versies? Hoe verhoudt zich dit tot de structuur in je versiebeheer?

[Kalentum]

Je releast gewoon een testversie vanuit de branche toch? En die stuur je naar de klant. Die versie noem je dan acceptatie_featureA en dan weet je wat de klant aan het testen is. Je versiebeheer hoeft daar niets vanaf te weten. Bij mij zie je niet terug in het versiebeheersysteem wat voor test, ontwikkel, acceptatie en productieomgevingen er zijn

Je zou natuurlijk naast een /trunk en een /branche ook nog een /test en een /acceptance met daarin de versie die op dat moment bij de klant ligt maar dat is misschien wat overkill.

[Appesteijn]

Cavalera125 schreef op maandag 05 oktober 2009 @ 18:37:
[...]

Bij mij is ook iedere feature een aparte branch. Maar hoe beheer je dan je OTAP omgevingen? Hoe zorg je ervoor dat die features op test, acceptatie en productie komen?

Meer concreet, het gaat bij mij om desktop applicatie ontwikkeling. Feature 2 kan naar de acceptatie omgeving (draait bij de klant) en Feature 1 staat nog op de test omgeving. En om het nog iets lastiger te maken staat Feature 3 nog op de ontwikkelomgeving. Hoe beheers je nu de verschillende versies? Hoe verhoudt zich dit tot de structuur in je versiebeheer?

Maar als je dan aan Feature 3 aan het ontwikkelen bent, dan kan je toch gewoon de laatste build gebruiken waarin feature 1 en 2 ook zitten?

[Cavalera125]

rutgerw schreef op dinsdag 06 oktober 2009 @ 08:17:
Je releast gewoon een testversie vanuit de branche toch? En die stuur je naar de klant.

Vanuit de Feature 1 branch bedoel je? Tegelijkertijd wordt er ook aan Feature 2 gewerkt. Die wil je ook naar de klant releasen (ter test), doe je dit dan vanuit de Feature 2 branch? Hoe zorg je er dan voor dat bij de release van Feature 2 ook Feature 1 nog beschikbaar is? Merge je dan eerst van Feature 1 branch naar Feature 2 branch?

Kortom, het moet dus mogelijk zijn om beide Features tegelijk te testen, deze zullen dus als 1 versie naar de acceptatie server gereleased worden. Vervolgens moet het ook mogelijk zijn om slechts een van de Features te releasen naar de productie omgeving.

Misschien ben ik te moeilijk aan het denken...

edit:
Google zoektoch...

Net deze aanpak tegengekomen. Dit zou wel eens kunnen werken voor ons.

[ Voor 9% gewijzigd door Cavalera125 op 06-10-2009 19:20 ]

[Gwaihir]

Cavalera125 schreef op dinsdag 06 oktober 2009 @ 13:00:
[...]

Vervolgens moet het ook mogelijk zijn om slechts een van de Features te releasen naar de productie omgeving.

Misschien ben ik te moeilijk aan het denken...

Daar maak je het inderdaad wel moeilijk, als je dat allemaal tegelijk klaar wilt hebben staan. Je moet immers al die versies naast elkaar actueel houden. Mocht het nodig zijn om feature 1 toch weer (tijdelijk) uit de trunk te schrappen, dan zou ik dat doen door de trunk terug te zetten naar net voor de merge met feature 1 en dan alleen feature 2 (en eventuele andere tussentijdse wijzigingen) opnieuw erin te mergen. Kortom: stel zo'n versie alleen samen als je 'm daadwerkelijk nodig hebt.

[Cavalera125]

Het topic is alweer bijna 2 maanden oud, maar ik ben er toch nog mee bezig. Heb nu de volgende opzet getest:

code:

project/branches
project/branches/feature1
project/branches/feature2

project/trunk

project/tags/ALPHA
project/tags/BETA
project/tags/RC
project/tags/RELEASE

De werkwijze is dan als volgt om te beginnen aan feature1

1. Maak een private development branch van de trunk en noem deze branches/feature1
2. Wanneer feature1 klaar is om naar de ALPHA omgeving te gaan wordt een tijdelijke branch van tags/ALPHA gemaakt -> branches/tmp_alpha
3. In deze tijdelijke branch wordt feature1 gemerged vanuit branches/feature1
4. Nu wordt vanuit branches/tmp_alpha een tag gemaakt tags/ALPHA/1.0.1
5. Op de alpha omgeving kan deze aanpassing nu getest worden, als hij goedgekeurd is kan hij naar de BETA omgeving.
6. Hetzelfde trucje wordt gedaan, namelijk, een tijdelijke branch van tags/BETA wordt aangemaakt.
7. Hierin wordt feature1 gemerged vanuit branches/feature1.
8. Vervolgens wordt weer een tag gemaakt die naar de BETA omgeving geplaatst kan worden.

Onze Alpha / Beta omgevingen zijn server side. Hierop kunnen vervolgens de testers aan de slag om de kwaliteit te controleren. Ik zie in deze methode een voordeel, dat is namelijk dat we direct weten wat naar welke omgeving is vrijgegeven. Nadeel is dat er wat overhead in zit. Ik twijfel ook over de tijdelijke branches. Wellicht beter om naast de aparte tags voor iedere omgeving ook een aparte branch te maken, dan zou je dus krijgen:

code:

project/branches/ALPHA
project/branches/BETA
project/branches/RC
project/branches/RELEASE
project/branches/feature1
project/branches/feature2

project/trunk

project/tags/ALPHA
project/tags/BETA
project/tags/RC
project/tags/RELEASE

Voordeel is dat je dan niet iedere keer een nieuwe branch hoeft te maken vanuit de tags. Er mag echter niet rechtstreeks ontwikkeld worden in deze branches, vandaar dat het misschien tegen het principe van een 'branch' indruist.

Wat is jullie mening over deze layout?