Softwaremanagement & Versionskontrolle

[SusanneK]

Hallo,

ich suche Tipps (Links, Tutorials, Literatur) zu dem korrekten Aufsetzen und in Betriebnehmen eines Softwareprojektes vor allem bezüglich der Versionierung und dem Handhaben von Releases, Branches etc.

Es geht mir hierbei nicht darum, wie man z.b. Subversion in eine Entwicklungsumgebung integriert, sondern vielmehr um die Beantwortung folgender Fragen:

- Es ist eine v1.4 vorhanden, die noch 6 Monate lang supported und gefixt werden soll. Daraus entsteht aber gleichzeitig die v2.0, die weiterentwickelt wird, aber mit den gleichen Fixes versehen werden soll. Müssen beide Versionen doppelt gepflegt werden, sollte man Patches einspielen etc. (wie löst man so ein Problem am besten, wie machen es andere).

- die Software wurde bisher nur von einem Entwickler betreut, weshalb auch auf ein Versionskontrollsystem verzichtet wurde. Nun wurde noch ein Entwickler eingestellt und nun soll die v2.0 gleich "richtig" aufgesetzt werden. Wie geht man da von Anfang an ordentlich an die Sache, damit es nicht zu späteren Problemen mit den Releases, Branches etc. kommt.

Ich hoffe, ihr könnt mir ein paar Tipps geben, wie ich mich mit dem Thema eingehender beschäftigen kann.

Vielen Dank schon mal!

Liebe Grüße
Susanne

 

[AlArenal]

Um im SVN-Jargon zu bleiben, würde ich Version 1.4 im Trunk lassen. Wenn ich das richtig verstanden habe, ist das Ding ein Feature-Freeze und erhält bis zum nächsten Major Release lediglich noch Bug Fixes.

Für die zu entwickelnde nächste Version 2.0 würde ich einen Branch anlegen. Ob ihr Fixes für 1.4 in die Entwicklungsversion der 2er übernehmen könnt, können wir von hier natürlich nicht beurteilen. Das müsst ihr von Fall zu Fall schon selber entscheiden und habt entsprechend ggf. doppelten Aufwand. Ist 2.0 fertig bügelt ihr das Ding im Trunk über die dann nicht mehr aktuelle Version.

Ich machs ja noch etwas anders und arbeite mit Versionsnummern der Form x.y.z . Dabei ist z das Patchlevel der Minor Version und zum Zeitpunkt des ersten Releases 0. Erhöphungen finden für jedes weitere Release der Version stat, bis es eine neue Minor oder Major Version gibt (die es nur mgibt, wenn neue Features enthalten sind). Jede einzelne erzeugte Version wird als Tag festgehalten, das macht den späteren Abruf oder den Vergleich zwischen Patchleveln einfacher.

 

[SusanneK]

Ja hallo!

wow, das ging fix! vielen Dank schon mal für die Infos.

Du hast natürlich recht: Die Versionierung ist auch bei uns dreistellig (ich war oben nur faul und schluderig ). Korrekt muss es heißen: v1.1.4

Mir fehlen leider einfach noch so ein bißchen die Grundlagen, wie man so ein Projekt anlegen sollte, damit es auch auf lange Sicht konsistent bleibt. Wenn Du also noch ein paar Links zu Hintergrundinfos hast (oder auch eine Buchempfehlung), wäre das natürlich super.

Liebe Grüße
Susanne

 

[AlArenal]

Also ich habe hier SVN eingeführt, obwohl ich auch der einzige bin, der es nutzt. Ich sehe nicht, warum erst "echtes" Teamwork da sinngebend sein sollte, zumal man einem neuen Mitarbeiter wohl kaum erklären kann wie er tatgtäglich mit dem Repository arbeiten soll, wenn man selbst keine praktischen Erfahrungen damit hat.

Mehr als mal in der offiziellen Doku zu stöbern habe ich auch nicht gemacht, der Rest ergibt sich einfach im Arbeitsalltag. Der Einfachheit halber bin ich den offiziellen Empfehlungen zum Aufbau der Repositorys für meine Projekte gefolgt, d.h Aufteilung in /trunk, /tags, /branches . So muss man später hinzukommenden Mitarbeitern nich noch unnötig Transferleistung abfordern und kann einfach auf offizielle Doku verweisen.

 

[kama]

Hallo,

ich würde die Release 1.4 zuerst einmal einchecken und zwar im trunk (SVN - Jargon ) bzw. Mainline genannt.
Dann einen Tag erzeugen(Label), um den Entwicklungsstand zu kennzeichnen.

Weiterhin einen Release Branch für die Release 1.4 ziehen (nur zur Vorbereitung)

Im Trunk kann nun die Weiterentwicklung zur Release 2.0 erfolgen. Wenn hier der Feature-Freeze stattfindet, dann kann man hier einen Release Branch 2.0 ziehen und dann auf dem Release Branch für 2.0 nur noch Bug-Fixing machen. Wichtig dabei ist, dass für jeden Bug auch ein Branch gezogen wird.

Sollten jetzt in der 1.4 ein Bug auftreten, kann man vom Release-Branch 1.4 einen Bug-Fix Branch legen dort den Fehler korrigieren und in den Release 1.4 - Branch integrieren und dann als z.b. 1.4.1 ausliefern. Der gezogen Bug-Fix Branch kann dann recht einfach auch in die Main-Line (trunk) integriert werden oder auch später in den Release Branch für 2.0, sollte das notwendig sein.

Das war jetzt die einfache Variante.

Mann kann die Entwicklung auf der Mainine (Trunk) auch völlig auf Null schrauben und man entwickelt nur noch mithilfe von Branches (Feature-Branching). Das ist aber u.U. ein wenig Kontraproduktiv hat aber unter gewissen Umständen recht große Vorteile.

...die Software wurde bisher nur von einem Entwickler betreut, weshalb auch auf ein Versionskontrollsystem verzichtet wurde.

Typischer Fehler ;-)

EDIT: Hier mal was zum Branching und hier sozusagen, die Bibel zum Branching.

Ich habe sowohl SVN eingeführt, wie auch Migrationen von CVS, ClearCase auf Subversion geamacht und zwar in Teams von 2-50 Leuten bisher....Na ja und selbst nutze ich SVN, SVK etc. sehr intensiv...
MfG
Karl Heinz Marbaise

 

[SusanneK]

Hallöle,

vielen vielen Dank für die tollen Tipps! Das bringt mich jetzt schon mal weiter! :applaus:

Liebe Grüße
Susanne

 

[Hilefoks]

Und BTW: Bau dein System am besten gleich mit Integrationstests. D.h. das der Server automatisch ein build erstellt (einmal am Tag, alle 2 Stunden, o.Ä.) und bei einem Fehler selbstständig Mails oder Jabber-Nachrichten an die Entwickler verschickt. So können die Entwickler zeitnah auf Fehler reagieren und gleichzeitig haben Sie keine Angst mehr die aktuelle Version auszuchecken. Ohne solche Tests bleibt ein Entwickler gerne auf einer bestimmten Revision hängen, weil er Angst hat eine neuere könnte nicht mehr compilen.

MfG,
Hilefoks