[Tool] Visuele Releases maken, welke tool?

[FireDrunk]

Voor een klus bij een integratie afdeling ben ik op zoek naar een tool waarmee ik visueel releases kan samenstellen.

Binnen het bedrijf waar ik zit wordt er gewerkt met XLDeploy, een Deployment tool welke zogenaamde "Composites" ondersteund. Deze tool zorgt er dan voor dat zo'n composite (een set van packages) op een machine terecht komt.

Binnen het bedrijf zijn er ~13 composites welke een volledige release vormen. En elke composite bevat van 1 tot ~15 pakketjes.

Het probleem:
Vanuit hoger management wisselt het nogal eens wat eerst naar productie (of acceptatie) gaat.
Hierdoor wordt mijn werk (het aanmaken van deze composites) nogal lastig gemaakt.

Wat we normaal doen, is de vorige release klonen en de updates er bij in "slepen".
Dit gaat goed als je lineair werkt in tijd (release a, kloon a naar b, kloon b naar c).

Nu is het al vaker gebeurt dat we releases hebben moeten omwisselen. Omdat er niemand blij van wordt om dit uit te spitten ben ik op zoek naar een tooltje waarmee ik dit makkelijker zou kunnen doen.

Heeft iemand een idee met wat voor soort applicatie dit zou kunnen? Of denk ik uberhaupt verkeerd hier over na?

[Gomez12]

Misschien dat ik het helemaal verkeerd begrijp hoor, maar zit dit hele probleem wel in het releasen?

Zit het niet gewoon in hoe jullie omgaan met code / versiebeheer etc?

Of ik begrijp het verkeerd of het betreft gewoon 1 "leeg" main project met 13 afhankelijkheden qua subprojecten.
Elk subproject heeft 1 main branch en meerdere andere branches.

Elke release is een release op het "lege" main project die van alle 13 subprojectjes automatisch de main branch meecompileerd.

Elke nieuwe gewenste feature is dan een branche-merge van een subproject naar main van datzelfde subproject en elke feature die er toch weer uitmoet is een rollback op het main-project van het sub-project.

Dan heb je 1 standaard release manier (alle mains of acceptatie branches) en als je een vcs hebt met cheap branching/merging lijkt mij het gewoon een goed uit te leggen manier (iedereen gebruikt al branches neem ik aan)

Wat je bedoelt met "vorige release klonen" snap ik dan ook niet helemaal, elke release lijkt mij een nieuwe release waar overal op meerdere plekken iets gewijzigd kan zijn, dat uitzoekwerk wil je helemaal niet op totaal niveau hebben, dat wil je op subprojectniveau hebben en als alle subprojecten goed zijn is automatisch het hoofdproject ook goed.

[FireDrunk]

Bijna correct, enige is dat er geen branches gemaakt worden
Er is een trunk per service (per pakketje dus), en er wordt alleen maar in de trunk gewerkt.

Sinds ik het release management doe (en dus goed oplet wat er naar productie gaat) worden er pas sporadisch branches gemaakt omdat ik geen broken code in Productie wilde zetten.

[Tranzity]

Kan je niet via de deployment pipeline regelen? En je packages zo maken dat deze ook van c naar b kunnen? (via de juiste Undo-commands).

XLDeploy is btw echt super!

[FireDrunk]

De packages kunnen wel van C naar B, dat is het probleem niet. Het is meer dat dat niet gewenst is.
Er moet een merge plaatsvinden tussen die releases.

Ik kan niet in XLDeploy zeggen: Merge versie C en B en pak van elk pakket de hoogste versie (want XLDeploy maakt geen onderscheid in versies... Het is gewoon een naam...)

[Gomez12]

FireDrunk schreef op donderdag 20 augustus 2015 @ 20:05:
Bijna correct, enige is dat er geen branches gemaakt worden
Er is een trunk per service (per pakketje dus), en er wordt alleen maar in de trunk gewerkt.

Tja, zorg dat je branches de organisatie inkrijgt.

Alles in de trunk en het dan later maar uitzoeken leidt idd tot elke keer puinruimen.

Als management wil kunnen wisselen tussen features dan heb je duidelijke afscheidingen tussen die features nodig en regulier regel je dat via branches.

Fix the problem en ga er geen doekje omheen proberen te winden met een tooltje.