[ALG]Documenteren software updates

[pkouwer]

sinds enige tijd heb ik SVN in gebruik voor version control. Voor hetgeen ik er mee doe/wil doen werkt dit fantastisch. Daarnaast gebruik ik OnTime voor bug-tracking wat ook naar behoren werkt. In de toekomst wil ik deze twee koppelen....

Wat ik (nog) niet in beeld heb is het documenteren van updates/revisies. Wat ik hiermee bedoel is dat er in versie 1.x.y nieuwe features zijn, t.w. "vul zelf maar in" en een aantal bugs zijn opgelost, namelijk "vul ook maar in".

Ik kan dit in Excel/Word doen en dat werkt, tuurlijk. maar ik kan me niet voorstellen dat er geen programma is wat dit opslaat. Ik wil per project/klant omschrijvingen van updates e.d. invoeren en zoeken.

Hoe doen de mede-tweakers dit ? Zie ik iets over het hoofd ?

[Voutloos]

Door gewoon de target version number feature van de issue tracker te gebruiken?

[Tubby]

Atlassian Jira is volgens mij een redelijk standaard tool, maar wat je eigenlijk mist is je releasebeleid. Het introduceren van een version control systeem betekend nog niet dat je een releasebeleid hebt.

Wat je wil is versies releasen, en bij zo'n release releasenotes kunnen produceren. Releasenotes destileer je uit je revisies en uit je "opgeloste meldingen". Als het goed is vormen deze twee de basis voor je releasenotes.

Maar vaak zijn je releasenotes nog iets meer; namelijk de "functioneel begrijpbare taal voor de eindgebruiker", eventueel een reproductiepatroon en testinstructies.

Bij Smile gebruiken we een eigen systeem om dit gat in te vullen, maar in feite gaat het erom dat je je meldingen en revisies op 1 of andere manier moet koppelen aan je versies en dat je op basis daarvan je releasenotes beschrijft

[ Voor 16% gewijzigd door Tubby op 24-11-2011 22:15 ]

[pkouwer]

Tubby schreef op donderdag 24 november 2011 @ 22:13:
Atlassian Jira is volgens mij een redelijk standaard tool

ik zal hier eens naar kijken, maar je begrijpt precies waar ik tegen aan loop. Een compleet beleid gaat misschien wat ver maar wel iets om over na te denken...

[Ventieldopje]

Kun je niet gewoon bij elke commit een omschrijving invullen? Changelog maak je dan zoals Tubby het zegt

Zelf gebruik ik als mede-tweakers Git op Windows icm. Tortoise Git en de integratie in m'n IDE (Aptana Studio).

[Tubby]

Ventieldopje schreef op donderdag 24 november 2011 @ 22:18:
Kun je niet gewoon bij elke commit een omschrijving invullen? Changelog maak je dan zoals Tubby het zegt

Zelf gebruik ik als mede-tweakers Git op Windows icm. Tortoise Git en de integratie in m'n IDE (Aptana Studio).

Nou; over het algemeen zijn je releasenotes van een ander aggregatie niveau als je commits.

Meestal heb je meer commits voor 1 releasenote, maar als het soms tegenzit heb je meerdere releasenotes met 1 commit. Dat laatste zou niet voor moeten komen als je gewoon vaak kleinere werkende stukjes commit, en als je je werk (nog)niet commit omdat je er geen releasenote waardig commentaar bij kan verzinnen ben je al helemaal fout bezig .

Commit messages zijn hoofdzakelijk voor de ontwikkelaars zodat hun begrijpen wat er gewijzigd is

[Tubby]

pkouwer schreef op donderdag 24 november 2011 @ 22:17:
[...]


ik zal hier eens naar kijken, maar je begrijpt precies waar ik tegen aan loop. Een compleet beleid gaat misschien wat ver maar wel iets om over na te denken...

Beleid is een groot woord, je kunt wel vast nadenken over het werken met branches en tags voor je versies in subversion. En op 1 of andere manier je meldingen koppelen aan versies, heel praktisch gezien zou je een soort interne melding gekoppeld aan de versie kunnen maken om je releasenote te beschrijven.

Tada; instant releasebeleid

[pkouwer]

die interne melding, dat is het hem nou juist. Met name het inzichtelijk maken van wat bij welk project is gedaan aan releases is de uitdaging....

[The Eagle]

En toch is Excel, zeker voor grote software, eigenlijk het prettigst.
1) Iedereen kant het bestand openen
2) Je kunt een bijna ongelimiteerd aantal kolommen hebben waarin je aggregatie en detailniveaus kwijt kunt
3) Per major release kun je 1 sheet bijhouden, die per minor release geupdate wordt
4) Zoeken is een peuleschil
5) 1 bestand online, altijd laatste versie, kun je zelfs je svn op loslaten als je wilt

Ik krijg ze voor PeopleSoft ook gewoon per Excel van Oracle support aangeleverd. Zit overigens wel een leuke macro bij om diverse pivottables te genereren Mocht je er eentje als voorbeeld willen hebben: doe maar even een DM, trek ik hem voor je van de supportsite af