Subversion en release management

[Standeman]

Ik werk nu sinds kort bij een klein bedrijfje waar subversion wordt gebruikt. Echter heb ik erg het gevoel dat hier (incl ik, het zijn namelijk mijn eerste ervaringen met subversion) we wel de klok horen luiden maar geen flauw idee waar de klepel hangt.

Het release proces gaat op het moment alsvolgt:
Er worden een berg wijzigingen in de code aangebracht, alles wordt ge-update, gebouwd en op de productieserver gezet (waar nog wel net een een kopietje van de oude, gecompileerde classes wordt gemaakt.)
Met andere woorden, we kunnen never nooit een oude versie opnieuw bouwen en om branches en tags heeft nog nooit iemand zich druk gemaakt. Release management is iets "wat we ook zouden moeten doen". Lekker handig als je een bugfix wilt maken in productie code of een bepaalde module nog niet wilt overzetten.

Nu wil ik daar verbetering in gaan brengen, maar daar heb ik minimaal twee dingen voor nodig:
- Een gedegen kennis van Subversion zelf (ik snap de svn client qua commit en update wel en ik weet zelfs hoe tortoise moet installeren , maar daarmee red ik het natuurlijk niet)
- Kennis van het proces wat er om heen speelt.

Nu heb ik al een aantal artikelen gelezen via internet e.d. maar ik heb niet het idee dat ik daar veel wijzer van wordt. Of ik snap ze niet of ze gaan amper op de onderwerpen in. In iedergeval vroeg ik me af of hier tweakers rond lopen die succesvol met subversion werken. Ik zoek naar voor tips / pointers naar artikelen of eigen ervaringen wat betreft hoe ik dit kan aanpakken en een proces kan inrichten om version control naar hoger niveau kan tillen..

Ik heb al een boek gevonden, Version Control with Subversion, dat ik denk ik ga aanschaffen. Tenzij iemand een betere weet natuurlijk

[Muscrerior]

Je kunt het boek (een licht verouderde versie) ook gratis online lezen.

Daarnaast denk ik dat je je heel erg moet afvragen wat de cultuur binnen het bedrijf is op dit gebied. Is je baas of zijn je mede-ontwikkelaars bereid om jouw aanbevelingen over te nemen/op te leggen? Steek geen bergen energie in een verbetering die om een politieke reden terzijde wordt geschoven.

[ Voor 0% gewijzigd door Muscrerior op 25-04-2009 16:49 . Reden: typo's O-) ]

[Janoz]

Om te beginnen zal ik je alvast aanraden om te zorgen dat je een subversion client krijgt die netjes met je ontwikkelomgeving integreert. Dat scheelt alvast een hoop.

Vervolgens zul je een keuze moeten maken tussen twee hoofdstromen:

- Developen in een branch met stable head.
- Developen in de head met een stable branch.

Gezien de huidige methode lijkt het me het handigst wanneer jullie de tweede pakken . Dat is immers wat er nu ook gebeurt.

De enige toevoeging die jullie moeten doen op je huidige proces is om, zodra je iets naar productie brengt, je project te taggen met een identificatie voor die release. Deze is dan altijd terug te halen (ipv die kopie op de server).
Wanneer je dit doet heb je alvast de eerste stap gezet naar het verder profesionaliseren van je proces, maar eigenlijk ben je er nog lang niet. Je werkelijke probleem ligt niet echt bij enkel het versiebeheer. Versiebeheer is eigenlijk maar een klein tooltje binnen het hele development, bugtracking en release managment verhaal. Hebben jullie nu ook al een bugtracker? Hebben jullie enkel een development omgeving en een productie omgeving? Doen jullie ook aan (acceptatie) tests?

[urk_forever]

Interessant topic, wij werken op dit moment op dezelfde manier als de TS en ik heb ook het gevoel dat het beter kan. Ik ga dit topic in de gaten houden.

[Standeman]

Muscrerior schreef op woensdag 22 april 2009 @ 15:01:
Je kunt het boek (een licht verouderde versie) ook gratis online lezen.

Daarnaast denk ik dat je je heel erg moet afvragen wat de cultuur binnne het bedrijf is op dit gebied. Is je baas of zijn je mede-ontwikkelaars bereid om jouw aanbevelingen over te nemen/op te leggen? Steek geen bergen energie in een verbetering die om een politieke reden terzijde wordt geschoven.

De cultuur is: functionaliteit uitpoepen Maar er wordt hier zeker goed gereageerd op proffessionalisering. Mijn baas (in hoeverre je het een baas kan noemen in een bedrijf van totaal 5 mensen) snapt en ziet ook wel dat het anders moet. Voor een gedeelte weet hij ook nog wel hoe het zou moeten, alleen hij heeft de tijd niet om er aan te werken. Ik ook eigenlijk niet, maar ik maak die tijd gewoon.

Bedankt voor de gratis versie

[djc]

Janoz schreef op woensdag 22 april 2009 @ 15:05:
- Developen in een branch met stable head.
- Developen in de head met een stable branch.

Je terminologie is hier nogal brak. HEAD is in principe altijd de laatste revisie. Wat jij bedoelt is:

- Developen in een branch met stable trunk.
- Developen in trunk met een stable branch.

Janoz schreef op woensdag 22 april 2009 @ 15:05:
De enige toevoeging die jullie moeten doen op je huidige proces is om, zodra je iets naar productie brengt, je project te taggen met een identificatie voor die release. Deze is dan altijd terug te halen (ipv die kopie op de server).

Ik zou het zelf nog ietsje uitgebreider doen (dit is ook wat volgens mij best practice is bij de meeste open source projecten). Als je een soort van concept van een release hebt, dan is dat het moment om een nieuwe branch te maken (bijvoorbeeld genaamd 2.5.x-stable). Als je dan een bugfixje wil maken tegen die versie (om snel weer te kunnen deployen) doe je dat daar. Daarnaast is het inderdaad zinnig om elke keer als je deployt een tag te maken. Je kan zowel trunk als een branch taggen, afhankelijk van wat zinnig is.

Janoz schreef op woensdag 22 april 2009 @ 15:05:
Wanneer je dit doet heb je alvast de eerste stap gezet naar het verder profesionaliseren van je proces, maar eigenlijk ben je er nog lang niet. Je werkelijke probleem ligt niet echt bij enkel het versiebeheer. Versiebeheer is eigenlijk maar een klein tooltje binnen het hele development, bugtracking en release managment verhaal. Hebben jullie nu ook al een bugtracker? Hebben jullie enkel een development omgeving en een productie omgeving? Doen jullie ook aan (acceptatie) tests?

Hmm, hoewel een bug tracker, aparte omgevingen en een uitgebreide test suite zeker aanraders zijn zou ik rustig beginnen met goed versiebeheer doen. Daarna een bug tracker toevoegen en zorgen dat iedereen die gebruikt. Gebruik ook zeker referenties tussen versiebeheer en bugtracker -- dus in de changeset comment van r12334 vermelden "fixt #1314" en in een comment bij #1314 zeggen "gefixed in r12334"; dat maakt het later veel gemakkelijker om een probleem te traceren. Testing en aparte omgevingen zijn ook zinnig, maar ik zou zeker eerst VCS, BTS en integratie van beide op orde brengen.

[ Voor 72% gewijzigd door djc op 22-04-2009 16:37 ]

[Standeman]

Janoz schreef op woensdag 22 april 2009 @ 15:05:
Om te beginnen zal ik je alvast aanraden om te zorgen dat je een subversion client krijgt die netjes met je ontwikkelomgeving integreert. Dat scheelt alvast een hoop.

Vervolgens zul je een keuze moeten maken tussen twee hoofdstromen:

- Developen in een branch met stable head.
- Developen in de head met een stable branch.

Gezien de huidige methode lijkt het me het handigst wanneer jullie de tweede pakken . Dat is immers wat er nu ook gebeurt.

De enige toevoeging die jullie moeten doen op je huidige proces is om, zodra je iets naar productie brengt, je project te taggen met een identificatie voor die release. Deze is dan altijd terug te halen (ipv die kopie op de server).
Wanneer je dit doet heb je alvast de eerste stap gezet naar het verder profesionaliseren van je proces, maar eigenlijk ben je er nog lang niet. Je werkelijke probleem ligt niet echt bij enkel het versiebeheer. Versiebeheer is eigenlijk maar een klein tooltje binnen het hele development, bugtracking en release managment verhaal. Hebben jullie nu ook al een bugtracker? Hebben jullie enkel een development omgeving en een productie omgeving? Doen jullie ook aan (acceptatie) tests?

Developen in de head met een stable branch klinkt als een goed idee. Hoewel ik me nog een beetje moet wennen aan de termen begin ik het nu wel te begrijpen. Het komt behoorlijk overeen met wat we nu aan het doen zijn. We werken met netbeans en de standaard svn plugin. Dus svn zit behoorlijk goed in onze ontwikkelomgeving geintegreerd (hoewel ik het niet helemaal fantastisch vind).

Voor bugtracking hebben we al een CRM pakket (vtiger) waar je ook issues in kan aanmaken, maar ik weet nog niet of het echt werkbaar is of dat het ons gaat helpen. Het is in iedergeval iets.

@Janoz & djc
Hoe zijn jullie aan die kennis gekomen? Zelf geleerd, collega's, cursus?

[Standeman]

djc schreef op woensdag 22 april 2009 @ 16:30:
[...]
Interessant verhaal

Wat is dan het verschil tussen een stable trunk, trunk en een head?

[Verwijderd]

Standeman schreef op woensdag 22 april 2009 @ 22:34:
[...]

Wat is dan het verschil tussen een stable trunk, trunk en een head?

trunk = hoofd branch, de 'aorta' in domino-termen
head = het nummer van de laatste revisie, dit kan zowel in de trunk als in een branch zijn.

Stable trunk wil over het algemeen zeggen dat de laatste versie in de trunk (de HEAD van de trunk) de laatste stabiele versie is. Meestal betekent dat ook dat de versie die 'live' staat gelijk is aan deze revisie.

Als er een nieuwe versie live gaat wordt er een branch (kopie) gemaakt van die revisie in de trunk. Development van nieuwe features en non-critical bugfixes vinden over het algemeen plaats op die branch. Als er nu een blocking issue op de live versie wordt ontdekt wordt deze gefixt in de trunk zodat eventueel half-afgemaakte features niet met de bugfix (vaak hotfix genoemd) live wordt gezet.

Je kunt er daarna voor kiezen om deze bugfix wel of niet te mergen met de development branch voordat je de branch weer terug merget naar de trunk. Mijn ervaring is dat wel mergen meestal beter is op de lange termijn.

Een stable branch aanpak draait de rollen om. De trunk is de laatste development versie en van elke versie die live gaat wordt een branch gemaakt. Hotfixes vinden plaats in deze branch die dan weer met de trunk gemerged kunnen worden. Features die je apart wil ontwikkelen (omdat ze bijvoorbeeld heel lang gaan duren en anders de release-cycle door de war gooien) doe je ook in een aparte branch.

[CubicQ]

Even inhakend op de opmerking van djc om een branch te maken nadat je een stabiele release hebt opgeleverd: dit hoeft natuurlijk niet per definitie op dat moment. Een branch kan je ook maken op het moment dat je de eerste productie-bugfix moet doen. Op het moment dat je een release hebt opgeleverd waarop je nooit een bugfix op hoeft te doen hoef je dus ook niet een branch te maken. (Maar dit is helemaal afhankelijk van de hoeveelheid stabiele releases, de hoeveelheid productie-bugfixes, en de hoeveelheid wijzigingen in de trunk)

Wij gebruiken ook het developen in trunk met een stable branch-model, en afhankelijk van het project maken we enige tijd voor een release een branch en leveren we een version van een branch op (op de grotere projecten waarbij we al door-ontwikkelen op de trunk voordat we een release stabiel genoeg hebben om op te leveren), of maken we alleen een version op de trunk bij een release en leveren we dus een version van de trunk op (op de kleinere projecten waarbij we alle features in 1x opleveren).

Overigens lekker luchtig leesvoer met de basics:
http://www.ericsink.com/scm/source_control.html

[BCC]

Heel erg kort de meest gebruikte develop structuur bij veel (opensource) projecten.

In basis heb je 3 folders in je subversion:

code:

 /tags
 /branches
 /trunk

Ontwikkelen doe je in de trunk. Als je code stabiel is / je wilt het uitleveren, maak je een kopie naar een branch.

code:

svn copy /trunk /branches/killerapp-1.1

Wil je vervolgens een versie releasen, dan maak je daarvan een tag

code:

svn copy /branches/killerapp-1.1 /tags/killerapp-1.1.1

Alleen tags worden gereleased naar de client.
Bug fixes worden in de branch gefixt, getagged en geforward-port naar de trunk.
Nieuwe functionaliteit wordt zoals gezegd ontwikkeld in de trunk en kunnen eventueel gebackport worden naar een branch met behulp van svn merge.

Wanneer iemand een grote refactor gaat doen, waar andere mensen last van zullen hebben, krijgt hij een eigen kopie van de trunk. Wijzigingen worden na de refactor weer in de trunk getrokken (svn merge).

code:

svn copy /trunk /branches/killerapp-framework-update

Dit is de meeste gebruikelijke manier om dingen te doen. Subversion biedt voldoende flexibiliteit om eenvoudig alternatieve werkprocessen te ondersteunen. Zorg bij SVN in ieder geval voor een handige repository browser, bijvoorbeeld een Trac. Dat helpt heel erg om het overzicht te bewaren. Integratie met je ontwikkelomgeving is leuk, maar kunnen vooral voor beginners dingen erg ingewikkeld maken.

Qua leesvoer: http://svnbook.red-bean.com/

[ Voor 13% gewijzigd door BCC op 22-04-2009 23:29 ]

[Cavalera125]

Interessant topic,

Janoz schreef op woensdag 22 april 2009 @ 15:05:
- Developen in een branch met stable head.
- Developen in de head met een stable branch.

Gezien de huidige methode lijkt het me het handigst wanneer jullie de tweede pakken . Dat is immers wat er nu ook gebeurt.

Ik moet zeggen dat ik het toch wel erg prettig vind om te werken met een stable trunk en te developen in een branch. Bij ons moet in principe al het development werk gekoppeld zijn aan een bug of request for change (RfC). Het is dan erg fijn om je branch naam te koppelen aan het nummer van de bug / RfC uit de bugtracker (wij gebruiken Mantis). Je weet dan precies wat in welke branch ontwikkeld wordt.

De methode die ik hierboven beschrijf is natuurlijk niet altijd bruikbaar. Eigenlijk pas vanaf het moment dat je software stabiel bij de klant draait. Daarvoor wordt er zoveel ontwikkeld dat het veel handiger is om in de trunk te ontwikkelen.

Het allerbelangrijkste wat betreft release management is in mijn ogen duidelijke procedures. Ook bij ons staat het releasemanagement nog in de kinderschoenen. Hier is nooit voldoende aandacht aan besteed zoals ook de TS beschrijft. Vroeg of laat ga je hierdoor altijd hard op je bek doordat je een wijziging met een bug erin live zet die je vervolgens haast niet meer kunt terugdraaien omdat hier onvoldoende rekenening mee wordt gehouden.

Sinds kort zijn we ook bezig met het implementeren van een OTAP straat per project.

Een paar punten die bij ons nog steeds spelen wat dit onderwerp betreft:

• Database versioning.
• Zorgen voor stricte naleving.

Hoe regelen jullie dit?

Enkele tips zoals wij subversion gebruiken:

1. Als software naar de productieomgeving van de klant gaat maken wij een read-only release tag. Deze tags hebben een standaard naam 'release-1.0.0' met oplopend volgnummer.
2. Als software naar de accepatieomgeving van de klant gaat maken we een read-only release tag. Dit is een release candidate en wordt iets als 'rc-1.0.0' genoemd.
3. Wij gebruiken lazy branching wat wil zeggen dat je pas een branch maakt als je hem daadwerkelijk gaat gebruiken. Zoals CubicQ zegt 'op het moment dat je de eerste productie-bugfix moet doen'. Dit voorkomt vervuiling.

Volgens mij is er niet 'DE' methode, elke situatie is anders. Zo heb je software waarvoor iedere dag een nieuwe release gemaakt wordt en softwaar waarvoor slechts eens per half jaar een bugfix gedaan hoeft te worden.

[BCC]

Cavalera125 schreef op woensdag 22 april 2009 @ 23:58:
Interessant topic,
Een paar punten die bij ons nog steeds spelen wat dit onderwerp betreft:

• Database versioning.
• Zorgen voor stricte naleving.

Hoe regelen jullie dit?

Db versioning doet Ruby On Rails heerlijk voor ons. Voor Java hebben we zelf een soort gelijke tool ontwikkeld.

Qua strikte naleving: Goede mensen aannemen. Natuurlijk heb je een release plan, maar als je klant echt een probleem heeft, wil je mischien toch een monkey-patch in de productieomgeving doen. Die afweging gaat geen enkele procedure voor je maken, je hebt iemand nodig die nadenkt. En hoe meer je daarvan vastlegt, hoe minder flexibel je kan reageren op problemen.

[Cavalera125]

BCC schreef op donderdag 23 april 2009 @ 00:18:
[...]
Natuurlijk heb je een release plan, maar als je klant echt een probleem heeft, wil je mischien toch een monkey-patch in de productieomgeving doen. Die afweging gaat geen enkele procedure voor je maken, je hebt iemand nodig die nadenkt. En hoe meer je daarvan vastlegt, hoe minder flexibel je kan reageren op problemen.

Ja met dat soort patches hebben wij ook regelmatig te maken, het is inderdaad een kwestie van zelf nadenken in deze gevallen zodat de patches ook weer terug gesynced worden. Het gaat er om een balans te zoeken tussen veiligheid en werkbaarheid...

[Standeman]

Als ik bij ons ga kijken zie ik dat 1 applicatie bestaat uit verschillende (java) projecten waar elk project zijn eigen repository heeft Ik zit me nu af te vragen of dat nu wel zo'n goed idee is qua beheer? We hebben bijv. een web project die gebruik maakt van een DB library project die beide in hun eigen repository zitten. Een stable release bestaat dus uit branches.

Ik zit me nu af te vragen of het principe "elk project zijn eigen repo" wel werkbaar gaat zijn? Hierboven schetste ik namelijk het meest simpele geval. Een applicatie bestaat bij ons makkelijk uit 4-5 verschillende repositories. Hoe gaan jullie daarmee om?

[NetForce1]

Standeman schreef op donderdag 23 april 2009 @ 09:09:
Als ik bij ons ga kijken zie ik dat 1 applicatie bestaat uit verschillende (java) projecten waar elk project zijn eigen repository heeft Ik zit me nu af te vragen of dat nu wel zo'n goed idee is qua beheer? We hebben bijv. een web project die gebruik maakt van een DB library project die beide in hun eigen repository zitten. Een stable release bestaat dus uit branches.

Ik zit me nu af te vragen of het principe "elk project zijn eigen repo" wel werkbaar gaat zijn? Hierboven schetste ik namelijk het meest simpele geval. Een applicatie bestaat bij ons makkelijk uit 4-5 verschillende repositories. Hoe gaan jullie daarmee om?

Het lijkt mij handiger om per applicatie een repository aan te maken (afgezien van utility libraries), je kunt dan veel makkelijker een tag / branch maken voor een hele applicatie.

[YopY]

quote: Cavalera125

Database versioning.

Martin Fowler heeft hier een stukje over geschreven, is misschien meer gericht op de echt grote enterprise apps (waar ze een echte database administrator hebben, ), maar d'r staan sowieso wel nozele dingen in.

De samenvatting is om voor elke databasemutatie een conversie / upgrade script / code te schrijven, die je een voor een uit kunt voeren om de 'huidige' databasestructuur te krijgen.

[Standeman]

NetForce1 schreef op donderdag 23 april 2009 @ 09:14:
[...]

Het lijkt mij handiger om per applicatie een repository aan te maken (afgezien van utility libraries), je kunt dan veel makkelijker een tag / branch maken voor een hele applicatie.

Dat vermoeden begin ik nu ook te krijgen. Alvast maar even uitzoeken hoe ik verschillende repositories bij elkaar kan krijgen.

[Kalentum]

NetForce1 schreef op donderdag 23 april 2009 @ 09:14:
[...]

Het lijkt mij handiger om per applicatie een repository aan te maken (afgezien van utility libraries), je kunt dan veel makkelijker een tag / branch maken voor een hele applicatie.

Een database library kan best als een apart project worden beschouwd, met een eigen release procedure. Zeker als het door meerdere projecten gebruikt wordt lijkt het me onhandig om verschillende versies bij te moeten houden van zo'n library.

[momania]

Wij hebben gewoon alles in 1 repository.

Elke applicatie/module heeft een eigen subfolder met daarin weer de trunk/branches/tags verdeling. Werkt prima

En voor sommige modules, zoals onze eigen 'commons' modules hebben we dan weer een extra hoofd folder, zodat die netjes bij elkaar zitten.

[NetForce1]

rutgerw schreef op donderdag 23 april 2009 @ 09:27:
[...]


Een database library kan best als een apart project worden beschouwd, met een eigen release procedure. Zeker als het door meerdere projecten gebruikt wordt lijkt het me onhandig om verschillende versies bij te moeten houden van zo'n library.

Daarop doelde ik met 'utility libraries', maar als database project slaat op de db-/dao-layer hoort dat wel in de applicatie-repo thuis dunkt me. Tenzij idd deze layer in meerdere applicaties gebruikt wordt, maar dat lijkt me niet echt veel-voorkomend.

[djc]

Het maakt feitelijk niet uit of je je apps in een fysiek apart repository hebt of dat je gewoon in de root-dir van je repo directories voor je apps maakt. Als je maar zorgt dat je een aparte tags/branches/trunk hebt voor elke applicatie of library. Dat is namelijk ook weer handig als je ooit een keer wil migreren naar een ander VCS (bijvoorbeeld Mercurial of git).

[Remus]

djc schreef op donderdag 23 april 2009 @ 12:55:
Het maakt feitelijk niet uit of je je apps in een fysiek apart repository hebt of dat je gewoon in de root-dir van je repo directories voor je apps maakt. Als je maar zorgt dat je een aparte tags/branches/trunk hebt voor elke applicatie of library. Dat is namelijk ook weer handig als je ooit een keer wil migreren naar een ander VCS (bijvoorbeeld Mercurial of git).

Maar als je alles in één repository hebt kun je - afhankelijk van de structuur - in één keer taggen in plaats van over meerdere repositories.

[Nick_S]

Wij gebruiken voor release management Maven icm. een subversion repository. Maven regelt het branchen, taggen en versienummers. De trunk is bij ons de huidige dev omgeving, de branches of release candidate branches of feature branches (bij grote wijzigingen).

De trunk en branches zullen altijd een SNAPSHOT versie hebben, bv. 1.0.5-SNAPSHOT, wat zoveel wil zeggen als, dit is work in progress. Deze SNAPSHOT versies mogen ook alleen lokaal of op de ontwikkelserver gebruiken. Beheer heeft nadrukkelijk de opdracht gekregen om elke SNAPSHOT versie zo snel mogelijk weer terug te schoppen. Alleen de tags hebben een niet SNAPSHOT versie, oftewel een gereleasede versie.

Een release maken van een branch of trunk is zo simpel als: mvn release:prepare uitvoeren en alle versienummers staan goed, zowel op de branch als op de tag. Bijvoorbeeld branch is 1.0.5-SNAPSHOT en na een release is er een 1.0.5 tag en is de branch 1.0.6-SNAPSHOT.

[djc]

Remus schreef op donderdag 23 april 2009 @ 15:29:
Maar als je alles in één repository hebt kun je - afhankelijk van de structuur - in één keer taggen in plaats van over meerdere repositories.

Die structuur wil je alleen liever niet hebben als je ooit nog de optie wil hebben te migreren naar iets anders dan Subversion.

Geloof me: het tags/branches model van Subversion is *veel* te flexibel. Doe het gewoon met een tags en een branches dir per functioneel repository. Iets anders gaat je over een paar maanden/jaar pijn doen.

[JKVA]

djc schreef op vrijdag 24 april 2009 @ 12:14:
[...]
Die structuur wil je alleen liever niet hebben als je ooit nog de optie wil hebben te migreren naar iets anders dan Subversion.

Geloof me: het tags/branches model van Subversion is *veel* te flexibel. Doe het gewoon met een tags en een branches dir per functioneel repository. Iets anders gaat je over een paar maanden/jaar pijn doen.

Die structuur (van Remus) wil je sowieso niet hebben. Iedere applicatie heeft een andere lifecycle en dus andere releasemomenten. Je wilt zaken met dezelfde lifecycle bij elkaar groeperen. Dit betekent in veel gevallen een tags+branches+trunk per applicatie (ik ga ervan uit dat je altijd een complete applicatie released?). @djc ik neem aan dat jij dit bedoelt met een functionele repository?

Dit is wat ik meestal bij bedrijven zie. Bij Apache is het ook ongeveer zo ingeregeld. We hebben de asf repository, dat is een publieke svn die alle top level projecten bevat. Elk project mag dan zelf zijn eigen "folder" inrichten. Bij MyFaces hebben we het onderverdeeld in alle subprojecten (aangezien tomahawk los van core released wordt) plus een aantal utilities (build-tools, shared, master-pom...). Elk van deze subfolders bevat een branches+tags+trunk.

Een voordeel is dat je alle projecten gemakkelijk los kunt releasen en toch overzicht behoudt. Anders krijg je namelijk iedere versie van ieder project in je tags/branches en moet je gaan prefixen om geen naming collisions te krijgen. Dat is niet wenselijk als je allemaal losse, autonome projecten hebt. Bovendien zit je elkaar niet in de weg. Ik zit zelf de laatste tijd vooral in de 2_0_0 branch van core en heb geen behoefte aan alle updates van andere projecten/branches, want dan blijf ik aan het syncen. Op deze manier blijft het werkbaar.

Zie: http://svn.apache.org/repos/asf/

Verder zou ik aanraden om met Maven2 te werken. Ondanks de negatieve beeldvorming is Maven2 tegenwoordig (ik heb er een aantal jaren terug regelmatig op gevloekt) een prima tool waarmee builden/releasen simpel en voorspelbaar wordt. Als je iets meer met testen, of met continuous integration wilt gaan doen, is het gemakkelijk als je al met Maven2 werkt, want je plugt alles zo in. Zorg wel voor een goede scholing, want Maven2 is voor veel mensen lastig te doorgronden.

Over database versionering, daar is niet alleen een blog entry van Fowler van, maar ook een boek. Zie: http://databaserefactoring.com/. Daarnaast zijn er een hoop leuke tools beschikbaar, zoals Liquibase. Een collega van mij heeft hier een jaar geleden een praatje over gehouden op de JSpring. Zie: http://www.nljug.org/page...ring_2008/sessions/00003/

Verder sluit ik me aan bij het punt over lazy-branching. Een branch aanmaken en niet gebruiken is alleen maar vervuiling.

[Remus]

JKVA schreef op zaterdag 25 april 2009 @ 17:24:
[...]
Die structuur (van Remus) wil je sowieso niet hebben. Iedere applicatie heeft een andere lifecycle en dus andere releasemomenten. Je wilt zaken met dezelfde lifecycle bij elkaar groeperen. Dit betekent in veel gevallen een tags+branches+trunk per applicatie (ik ga ervan uit dat je altijd een complete applicatie released?). @djc ik neem aan dat jij dit bedoelt met een functionele repository?

'Mijn' structuur is gebaseerd op of één applicatie (+ libraries) die in meerdere ontwikkelprojecten is opgedeeld, of één verzameling applicaties die altijd als één release wordt uitgebracht. In dat geval is het echt wel veel handiger om alles in één repository met een enkelvoudige branchstructuur te hebben.

Als het om losse applicaties gaat of om libraries die door veel verschillende applicaties wordt gebruikt dan is het anders, maar mijn reactie was gericht op de situatie van standeman waarbij het om één applicatie gaat.

[Standeman]

*schop*

Inmiddels zijn we lekker onze code aan het branchen, taggen, mergen, etc. Ik moet eerlijk zeggen dat ik Subversion echt heerlijk (simpel) vind werken t.o.v. Sourcesafe en CM Synergy.

Ik zit nu even te kijken of ik het hele release proces van onze software nog wat verder kan verbeteren. We hebben voor elke library die we zelf gebruiken een aparte repository en het ziet er ongeveer zo uit:

• lib_a
• lib_b
• lib_c
• project_x

Als ik dus een nieuwe versie wil releasen van project_x doe ik op het moment:

• lib_a
  
  branches/project_x-2.1
• lib_b
  
  branches/project_x-2.1
• lib_c
  
  branches/project_x-2.1
• project_x
  
  branches/project_x-2.1

Het wordt een beetje vervelden om elke keer weer de libraries te branchen wanneer er een nieuwe versie gemaakt wordt voor project_x.

Heeft iemand enig idee hoe ik dit kan automatiseren?

[YopY]

De libraries zou je gewoon onder het project kunnen doen, denk ik - of evt aan het project koppelen mbv svn externals (heb ik geen ervaring mee overigens). Het lijkt een beetje overbodig om voor elk project een branch te maken in de library - waarom doe je dat? Een library zou onafhankelijk van een project ontwikkeld moeten worden. Functionaliteit die slechts voor één project gemaakt hoeft te worden, moet in een andere lib. De rest zou ook voor andere programma's gebruikt kunnen worden.

Of je zegt gewoon 'project X gebruikt nu versie Y van library Z', en zet dat vast - met een verwijzing naar de tag / release van versie Y van library Z.

* YopY snapt zichzelf ook niet meer.

[Standeman]

YopY schreef op vrijdag 20 november 2009 @ 11:37:
De libraries zou je gewoon onder het project kunnen doen, denk ik - of evt aan het project koppelen mbv svn externals (heb ik geen ervaring mee overigens). Het lijkt een beetje overbodig om voor elk project een branch te maken in de library - waarom doe je dat? Een library zou onafhankelijk van een project ontwikkeld moeten worden. Functionaliteit die slechts voor één project gemaakt hoeft te worden, moet in een andere lib. De rest zou ook voor andere programma's gebruikt kunnen worden.

Project_x-2.1 werkt bijv. met lib_a revision 161 Dat betekend niet dat het ook werkt met rev. 162 omdat daar misschien wel method signatures zijn aangepast of er andere dingen ge-refactored zijn en dus niet backwards-compatible is.

Of je zegt gewoon 'project X gebruikt nu versie Y van library Z', en zet dat vast - met een verwijzing naar de tag / release van versie Y van library Z.

* YopY snapt zichzelf ook niet meer.

Dat doen we ook. Alleen branchen / taggen we de library pas wanneer er een nieuwe release wordt uitgebracht van een (web) project dat gebruik maakt van die library.
Het taggen/branchen van alle libraries begint een beetje een vervelende handmatige klus te worden. Vandaar mijn vraag.

[ Voor 35% gewijzigd door Standeman op 20-11-2009 11:55 ]

[__fred__]

Ok dan, voor de liefhebbers. Hoe wij het hier op kantoor hebben ingericht:

Elk project heeft een svn repository en een trac site. Verder is er een svn repository voor shared code.
We hebben een CruiseControl continuous integration server staan die versies bouwt voor onze software. Elke nacht wordt er een release build gedaan voor alle applicaties, er wordt een debug build gemaakt bij elke commit. Unit tests runnen op de continuous integration server na elke commit. Voor release builds wordt automatisch ook een WIX wxs file aangemaakt en een WIX installer gemaakt op basis van templates. Hierbij worden voor verschillende klanten middels een combinatie van XSLT transformaties en XML replaces ook gelijk de getargete app.config bestanden in de MSI's gestopt. De uiteindelijke MSI's worden met een publish gepublisht op de wiki van trac. Klanten hebben toegang tot de tickets van trac en de wiki (wordt ook gebruikt voor documentatie).

Elke build wordt via updateversion op de buildserver voorzien van het laatste commit nummer, dit is ook gelijk de tag voor subversion. Commits op subversion moeten altijd voorzien zijn van een referentie naar het ticketnummer waaraan is gewerkt / die is opgelost. Zo zorgen we ervoor dat elke software wijziging kan worden gerelateerd aan een ticket.

Branchen van stable branches gebeurt als we na grondig testen (en de klanten na grondig testen) ervan overtuigd zijn dat deze het waard is om uit te leveren. Deze branch onderhouden we dan totdat de nieuwe stable branch weer afgesplitst wordt van trunk.

SQL versioning vindt plaats doordat elke werkplek voorzien is van een lokale SQL development database en server en red gate SQL compare. Deze synchroniseert deze lokale databases tegen een set SQL bestanden die onderdeel zijn van de source tree.

Ter indicatie: Het branchen of opzetten van een nieuw project kost ongeveer een halve dag. Daarna is bovenstaand een continue proces. De uren zoals ingevuld in trac kunnen we overhalen naar de urenadministratie. Scheelt tikwerk.

[ Voor 9% gewijzigd door __fred__ op 20-11-2009 14:36 ]

[Gwaihir]

Standeman schreef op vrijdag 20 november 2009 @ 10:14:Als ik dus een nieuwe versie wil releasen van project_x doe ik op het moment:

• lib_a
  
  branches/project_x-2.1
• lib_b
  
  branches/project_x-2.1
• lib_c
  
  branches/project_x-2.1
• project_x
  
  branches/project_x-2.1

Het wordt een beetje vervelden om elke keer weer de libraries te branchen wanneer er een nieuwe versie gemaakt wordt voor project_x.

Heeft iemand enig idee hoe ik dit kan automatiseren?

Doe je doorgaans nog wat met elk van die branches, of zijn het verkapte tags? Wij maken bij elke release (standaard, d.w.z. vanaf trunk), alleen een tag aan. Slechts indien op zo'n stable versie onafhankelijk van de trunk nog gewerkt moet worden (bug fix), maken we er op het moment dat dat blijkt een branch voor. (Zie ook de eerdere opmerkingen over lazy branching.)

Deel je de releases van de libs niet tussen projecten? Bij ons heeft elke lib zijn eigen versienummering, los van de versienummers van de projecten die 'm gebruiken. Maak ik voor project X een lib_A release 1.1.0 aan, dan kan project Y die desgewenst ook gebruiken. Heeft vervolgens Y weer iets nieuws in de lib nodig, dan leidt dat tot een lib_A 1.2.0, die desgewenst ook door de volgende versie van X gebruikt kan worden.

[Verwijderd]

Welke taal gaat het om? Onder Java kun je hier heel goed Maven voor gebruiken. Hierdoor koppel je je dependencies en projecten uit elkaar en laat je projecten dependen op een versie van een library.

[Verwijderd]

Ik wil aanvangen met het schrijven van mijn scriptie. Ik gebruik hiervoor de opmaaktaal LaTeX in plaats van MS Word. Dit werkt naar mijn beter. Omdat dit werkt met losse text files is het geschikt om dit in een Subversion repo te plaatsen. Ik wil hiermee starten maar ben alleen bekend met de basisbegrippen.

Ik wil een situatie creeeren waarmee ik alleen stabiele versies uitlever. Met stabiel bedoel ik versies met complete hoofdstukken. Ik zal namelijk tussentijdse versie moeten opleveren maar die moeten wel leesbaar zijn. Hierbij komen branches om de hoek kijken. Ik dacht zelf aan een branch per hoofdstuk.

Maar hoe start ik? Ik heb een repo aangemaakt om vervolgens een check-out uit te voeren. Daarna heb ik een standaard directory structuur opgezet in mijn lokale kopie met de directories trunk, branches en tags. Binnen de trunk heb ik voor ieder hoofdstuk een directory aangemaakt. Deze strucuur heb ik vervolgens ge-commit. Maar hoe nu verder? Moet ik nu meteen een branch maken van de trunk en daarop gaan ontwikkelen?

[Verwijderd]

Nee je werkt altijd op de trunk (of evt in een tag, maar dat is nu niet van toepassing). Zodra je een versie uitlevert dan kopieer je de huidige staat van de trunk naar een folder onder branch. Deze laat je hier gewoon staan. Vervolgens werk je gewoon verder aan de trunk. Het is niet de bedoeling dat je aan een branch werkt (deze is immers final). Uiteindelijk komt je branch folder dus vol te staan met folders als v0.1, v0.2, v1.0 etc. Dit zijn dus gereleasde versies.

[Nick_S]

Uhh, haal je nu niet de definities van branch en tag door elkaar? Een tag wijzigt niet meer, een branch is om te ontwikkelen.

Een branch per hoofdstuk kan, maar misschien is dat overkill. Is het niet voldoende om 1 branch en 1 (stable) trunk te hebben. Schrijf op de branch, commit naar de branch en merge het hoofdstuk naar de trunk voor een evt. release.

Meerdere branches zijn imho alleen handig als je:
- Met meerdere personen aan iets werkt.
- Met meerdere features bezig ben, die elkaar ook kunnen raken.

[ Voor 61% gewijzigd door Nick_S op 05-01-2010 21:00 ]

[BCC]

Nick heeft gelijk. Als je in je eentje ontwikkeld: Developen in de trunk, taggen als je x hoofdstukken compleet hebt.

Als je netter wil uitleveren: Branchen op een bepaald punt, de latex in die branch netjes maken, die taggen en uitleveren.

[ Voor 86% gewijzigd door BCC op 05-01-2010 21:13 ]

[Nick_S]

BCC schreef op dinsdag 05 januari 2010 @ 21:12:
Nick heeft gelijk. Als je in je eentje ontwikkeld: Developen in de trunk, taggen als je x hoofdstukken compleet hebt.

Als je netter wil uitleveren: Branchen op een bepaald punt, de latex in die branch netjes maken, die taggen en uitleveren.

Dat kun je dus ook andersom doen. Werken met een stable trunk en alleen die dingen mergen van een branch die productierijp zijn.

Er zijn twee mainstream methodes:

- Stable trunk, alleen features die compleet af zijn mogen van een branch naar de trunk gemerged worden. Trunk wordt gebruikt om tags te maken.
- Unstable trunk, iedereen ontwikkelt op trunk (Uitzonderingen voor erg grote refactorings, ed.). Er wordt een release branch gemaakt, die geperfectioneerd wordt voor een release (tag)

Allebei hebben ze voor- en nadelen. Vaak zie ik ontwikkelteams gebruik maken van unstable trunks, terwijl beheerteams de stable trunk methode gebruiken. Dit is ook logisch, tijdens ontwikkeling hoef je niet a la minuut een release te kunnen maken. Tijdens beheer wil je elk moment een issue voorrang op alle andere kunnen verlenen. Dan is een stable trunk erg makkelijk. Je branched hem, fixed je issue en merged weer en klaar voor release.

[Standeman]

Nick_S schreef op dinsdag 05 januari 2010 @ 21:19:
[...]

Dat kun je dus ook andersom doen. Werken met een stable trunk en alleen die dingen mergen van een branch die productierijp zijn.

Er zijn twee mainstream methodes:

- Stable trunk, alleen features die compleet af zijn mogen van een branch naar de trunk gemerged worden. Trunk wordt gebruikt om tags te maken.
- Unstable trunk, iedereen ontwikkelt op trunk (Uitzonderingen voor erg grote refactorings, ed.). Er wordt een release branch gemaakt, die geperfectioneerd wordt voor een release (tag)

Allebei hebben ze voor- en nadelen. Vaak zie ik ontwikkelteams gebruik maken van unstable trunks, terwijl beheerteams de stable trunk methode gebruiken. Dit is ook logisch, tijdens ontwikkeling hoef je niet a la minuut een release te kunnen maken. Tijdens beheer wil je elk moment een issue voorrang op alle andere kunnen verlenen. Dan is een stable trunk erg makkelijk. Je branched hem, fixed je issue en merged weer en klaar voor release.

Over dat laatste, wij ontwikkelen nu met een unstable trunk. Maar in principe is een patch ook zo gemaakt. De meeste releases staan ook gewoon op mijn machine. Als er een issue opgelost wordt, pak ik de release versie, branch deze en merge de change terug in de trunk zodra deze gereleased wordt.

Dat vind ik eigenlijk wel het schitterende van subversion, het is zo verdomde flexibel en toch heerlijk simpel.

[Verwijderd]

Grapje ik was even in de war.

[BCC]

Standeman schreef op dinsdag 05 januari 2010 @ 22:00:
[...]
Dat vind ik eigenlijk wel het schitterende van subversion, het is zo verdomde flexibel en toch heerlijk simpel.

Dan moet je eens naar Git gaan kijken. Subversion on steroids

[djc]

BCC schreef op dinsdag 05 januari 2010 @ 23:20:
Dan moet je eens naar Git gaan kijken. Subversion on steroids

Of Mercurial, bijna zo snel als git maar een stuk begrijpelijker (en werkt op Windows).