Versionierungsstrategien

Artikeldaten
Erste Version 0.1 (22.08.2012)
Aktuelle Version 0.1(22.08.2012)

1. Kurzbeschreibung

Bei der Software-Entwicklung (und auch beim Schreiben von größeren Texten) ist es sinnvoll von Zeit zu Zeit den aktuellen Entwicklungsstand zu sichern. Am Anfang reicht hierfür vielleicht die Kopie des Projektordners auf einer externen Festplatte (in z.B. einen Unterordner mit dem Zeitstempel als Namen). Irgendwann wird dies aber zu umständlich und zu unübersichtlich. Es wird Zeit über ein Versionierungssystem nachzudenken und damit auch über eine Versionierungsstrategie. Dieser Artikel soll bei dieser Entscheidung helfen. Die vorgestellten Strategien sind unabhängig von dem eingesetzten Versionierungssystem (Git, TFS, Subversion, Mercurial usw.).

2. Ein-Zweig Strategie

Versionsstrategien - Ein-Zweig

2.1. Beschreibung

Diese Strategie ist relativ einfach. Alle Änderungen werden in einen einzigen Zweig abgelegt. Sobald der Code einen Release-Status erreicht hat, wird dieser Stand ausgeliefert und mit einem sprechenden Namen (meistens Versionsnummer) versehen. Damit ist diese Release-Version jederzeit in der eigenen Versionsverwaltung schnell auffindbar. Nach der Auslieferung der Release-Version geht die Entwicklung linear weiter.

2.2. Pro

  • Sehr einfache Benutzung
  • Kein Merge zwischen unterschiedlichen Zweigen notwendig
  • Sehr gut für den Einstieg in die Versionsverwaltung geeignet
  • Sehr gut für Dokument-Versionierung (Bücher, Artikel, Manuskripte usw.)

2.3. Kontra

  • Schwer zu handhaben, wenn mehr als nu rein Entwickler beteilig ist, da während des Release-Tests keine Weiterentwicklung für nächste Version möglich ist.
  • Hotfixes einer Version sind sehr schwer zu realisieren, da eventuell bereits unvollständige Features für neue Version da sind.

3. Master-Develop Strategie

Versionsstrategien - Master-Develop

3.1. Beschreibung

Diese Strategie ist auch relativ einfach. Das eigene Versionsverwaltungssystem besteht aus zwei Zweigen. In dem Master-Zweig werden nur benannte, getestete und abgeschlossene Versionen abgelegt (z.B. Stand einer Release-Version). Der Develop-Zweig wird dagegen wie in der Ein-Strang-Strategie benutzt. Alle Projektstände, die gesichert werden sollten (egal ob der Stand vollständig und / oder lauffähig ist), werden diese in den Develop-Zweig geschrieben. Ist ein Code / Text-Stand erreicht, der an den Kunden ausgeliefert werden kann, und ist getestet, wird der Master-Zweig mit dem Develop-Zweig zusammengeführt. Danach wird der Stand des Master-Zweiges benannt (z.B. mit Versionsnummer).

3.2. Pro

  • Bietet besseren Überblick über ausgelieferte / veröffentlichte Projektstände und belässt die Flexibilität bei der täglichen Arbeit.
  • Schneller Zugriff auf benannte Stände, da diese nur im Master-Zweig vertreten sind (ohne Entwicklungsbalast).

3.3. Kontra

  • Schwer zu handhaben, wenn mehr als nur ein Entwickler beteilig ist, da während des Release-Tests keine Weiterentwicklung für nächste Version möglich ist.
  • Hotfixes einer Version sind sehr schwer zu realisieren, da eventuell bereits unvollständige Features für neue Version da sind.

4. Git-flow Strategie

Versionsstrategien - Git flow

4.1. Beschreibung

Diese Strategie ist mit Git-Versionsverwaltung entstanden, da bei Git die Zweige (branches) sehr einfach erstellt und wieder gelöscht werden könne. Hier werden zwei Arten der Zweige verwendet.

imortal branches (unsterbliche Zweige)
Das sind Zweige, die über die gesamte Dauer des Projektes bestehen bleiben. Zu solchen Zweigen gehören bei Git-Flow-Strategie master und develop Zweige
mortal branches (sterbliche Zweige)
Das sind Zweige, die nur eine begrenzte Lebensdauer haben und nach dem Erfüllen des Zwecks, gelöscht werden (können). Zu solchen Zweigen gehören bei Git-Flow-Strategie die release, hotfix und feature Zweige.

feature

Auf dem „develop„-Zweig werden direkt nur sehr kleine Änderungen gemacht. Größere Änderungen werden in eigene sterbliche Zweige ausgelagert, die mit dem Präfix „feature“ anfangen (Ursprung ist „develop„-Zweig). Die Entwicklung der neuen Funktion erfolgt dann bis zur Fertigstellung auf diesem sterblichen Zweig. In der Zwischenzeit kann man diesen „feature„-Zweig mit „develop„-Zweig abgleichen, um die Unterschiede klein zu halten, oder bestimmte bereits bereinigte Fehler auch in diesem Zweig zu korrigieren. Nach dem Beenden der neuen Funktion wird der „develop„-Zweig mit dem „feature„-Zweig zusammengeführt und der „feature„-Zweig gelöscht.

  1. Neuen Zweig mit Namen „feature/bezeichnung“ erstellen.
  2. Entwicklung auf dem neuen Zweig „feature/bezeichnung„.
  3. Develop-Zweig mit dem neuen Zweig „feature/bezeichnung“ zusammenführen, sobald die Aufgabe erledigt ist.
  4. Den neuen Zweig „feature/bezeichnung“ löschen.

release

Ist ein Stand auf dem „develop„-Zweig erreicht, der ausgeliefert werden kann, wird ein sterblicher „release„-Zweig aufgemacht (Ursprung ist „develop„-Zweig). Dieser hat den Präfix „release„. Dieser Zweig dient dem Testen des fertigen Standes, ohne die Entwicklung auf dem „develop„-Zweig zu beeinträchtigen. Wenn die Tests Fehler zum Vorschein bringen, werden diese im „release„-Zweig korrigiert, bis der Stand wirklich ausgeliefert werden kann. Dann wird dieser Stand mit „master„-Zweig zusammengeführt und ein neuer Tag auf dem „master„-Zweig erstellt. Danach wird der „develop„-Zweig mit dem „release„-Zweig zusammengeführt. Abschließend wird der sterbliche „release„-Zweig gelöscht.

  1. Neuen Zweig mit Namen „release/vVersionNummer“ erstellen.
  2. Tests und Bugfixing auf dem neuen Zweig „release/vVersionNummer“ durchführen.
  3. Nach allen Tests und Korrekturen den Master-Zweig mit dem neuen Zweig „release/vVersionNummer“ zusammenführen.
  4. Master-Zweig-Stand benennen (tagen).
  5. Develop-Zweig mit dem neuen Zweig „release/vVersionNummer“ zusammenführen.
  6. Den neuen Zweig „release/vVersionNummer“ löschen.

hotfix

Die ausgelieferten Versionen sind meistens trotzt vieler Tests nicht frei von Fehlern. In solchen Fällen wird aus dem „master„-Zweig ein neuer sterblicher „hotfix„-Zweig erstellt, um den Fehler zu korrigieren. Dieser Zweig hat das Präfix „hotfix“ und erfüllt nur eine einzige Aufgabe, den gefundenen Fehler der Version zu korrigieren. Durch den eigenen Zweig für Fehlerkorrektur wird der Entwicklungsfluss nicht beeinträchtigt. Sobald der Fehler (oder auch mehrere) korrigiert wurde, wird der „master„-Zweig mit dem „hotfix„-Zweig zusammengeführt und neu getagt (benannt). Die Fehlerkorrektur muss auch in den „develop„-Zweig. Aus diesem Grund wird auch der „develop„-Zweig mit dem „hotfix„-Zweig zusammengeführt. Abschließend wird der „hotfix„-Zweig gelöscht.

  1. Neuen Zweig mit Namen „hotfix/vVersionNummer“ erstellen.
  2. Fehlerkorrekturen auf dem neuen Zweig „hotfix/vVersionNummer“ durchführen und testen.
  3. Nach der erfolgreichen Korrektur der Fehler den Master-Zweig mit dem neuen Zweig „hotfix/vVersionNummer“ zusammenführen.
  4. Master-Zweig-Stand benennen (tagen).
  5. Develop-Zweig mit dem neuen Zweig „hotfix/vVersionNummer“ zusammenführen.
  6. Den neuen Zweig „hotfix/vVersionNummer“ löschen.

4.2. Pro

  • Arbeiten im Team ohne Beeinträchtigungen möglich, da Aufgaben in eigenen Zweigen erledigt werden.
  • Saubere Implementierung der Hotfixes für Release-Versionen ohne Beeinträchtigung der Entwicklung möglich.
  • Paralelles Weiterentwicklen der nächsten Version und vorbereiten (testen) der aktuellen durch Release-Zweige möglich.
  • Auslieferung von Hotfixes in sehr kurzer Zeit möglich, da keine Rücksicht auf den Entwicklungsstand genommen werden muss.

4.3. Kontra

  • Komplexere Handhabung als beide vorhergehenden Strategien.
  • Momentan wird nur von wenigen graphischen Tools (z.B.: SourceTree unter OS X) direkt unterstützt.
  • Erfordert Disziplin beim Entwickeln, da für jede Aufgabe ein neuer Zweig aufgemacht werden muss.
  • Nicht geeignet, wenn mehrere Release-Versionen über lange Zeiträume parallel gepflegt werden müssen.

5. Ressourcen

5.1. Bilder

5.3. Bücher

Bootcam Installation mit mehr als 2 Partitionen

Nach dem Kauf eines Mac mini und deren Aufrüstung auf 4GB RAM und 500GB HDD (7200 U/min) stand nun die Frage, wie man am besten die lieb gewonnenen Strategiespiele auch unter dieser Maschine spielen soll. Der Grafikchip (nVidia GeForce 9400) ist dafür eigentlich völlig ausreichend. Den ersten Test machte ich mit Windows XP unter VMWare Fusion und Anno 1701. Das Ergebnis war leider nicht zufriedenstellend.

Die zweite Möglichkeit liegt bei Bootcamp. Den Assistenten gestartet, der meldet aber:

Das Startvolume kann weder partitioniert noch in einer Einzelpartition wiederhergestellt werden.
Für die Installation von Windows muss das Startvolume entweder ein als Mac OS-Extended (Journaled) formatiertes Einzelvolume oder bereits durch den Boot Camp-Assistenten partitioniert sein.“

Nach einiger Suche im Internet war die Ursache relativ schnell gefunden. Bootcamp funktioniert nur, wenn auf der Festplatte max. 2 Partitionen vorliegen (eine davon Windows Partition). Bei meiner Installation habe ich allerdings noch eine dritte Partition, auf der das User-Verzeichnis liegt. Somit war der Assistent nutzlos.

Weitere Recherchen ergaben dann 3 mögliche Vorgehensweisen:

  1. Benutzung von nur 2 Partitionen (Mac + Windows).
  2. Herumbasteln an der boot.ini, damit Windows von der richtigen Partition startet.
  3. Ein alternativer Bootmanager.

Da ich in Zukunft flexibel bleiben möchte (Parallelinstallation von weiteren Betriebssystemen – Windows 7, Ubuntu usw.), habe ich mich für die 3. Variante entschieden.

Nach einiger Suche bin ich auf den Bootloader rEFIt gestossen. Nach der einfachen Installation des rEFIt Bootloaders auf die Mac OS X Systempartition habe ich noch rEFIt aktiviert, damit dieser immer erscheint.

Dafür musste ich unter Terminal folgendes ausführen:

cd /efi/refit/
enable-always.sh

rEFIt BootmenüNach dem Anlegen der 3. Partition für Windows (mit Festplattendienstprogramm) startete ich die Windows-Installation von der CD. Nach dem ersten Neustrat während der Installation tauchte schon Windows als Startoption in rEFIt. Unter Windows wurde ganz normal dann alles installiert, incl. der Treiber von der Mac OS X DVD.

Das einzige Problem, dass bei der Installation von Windows XP bei mir auftrat, war die Installation von SP 3 mit den Treibern von Mac OS X 10.6 (Snow Leopard). Wie das funktioniert, beschreibe ich im nächsten Beitrag.

Auf der rEFIt Projekt-Homepage steht, dass es manchmal bei Mac OS X Updates zu Störungen kommen kann. Dann muss rEFIt einfach neu installiert werden. Beim Update von 10.6 auf 10.6.1 traten keine Komplikationen auf.

Duden Korrektor für OpenOffice unter Linux (Ubuntu)

So wie wahrscheinlich viele, leide auch ich unter der mangelhaften Rechtschreibkorrektur. Viele Fehler werden entweder gar nicht erkannt, oder falsch als Fehler gekennzeichnet. Insbesondere bei vielen zusammengeschriebenen Wörtern versagt die Prüfung komplett.

Um diesen Mangel zu beseitigen, benutzte ich schon seit Jahren unter Windows den Duden Korrektor (seit Version 3.5) für OpenOffice. Unter Windows klappt so weit alles gut, da der XP bis dahin praktisch nur in 32-Bit-Version lief.

Seit über 3 Jahren nutze ich vermehrt Linux, als primäres Betriebssystem, und seit einem Jahr noch Mac OS X 10.5 (Leopard) für meine Frau. Also wurde kurzerhand der Duden Korrektor (Version 5.0 mittlerweile) auch auf diese Systeme installiert, theoretisch. Bei Mac gibt es keine Probleme. Die Erweiterung läuft auf 64-Bit.

Unter Linux ist ein 64-Bit-System dagegen eine absolute Bremse. Es funktioniert einfach nicht. Auch konnte ich bis jetzt keine Workarounds finden, die eine funktionierende Umgebung erzeugen. Unter 32-Bit läuft es dagegen ohne Probleme (EeePC 1000H).

Die Anfragen an Duden Verlag direkt ergaben nichts. Es kommt nur die Antwort, das 64-Bit-Systeme nicht unterstützt werden, auch nicht in der Zukunft. Mittlerweile steht sogar in den Systemanforderungen (Version 6.0), dass Windows XP und Vista nur in den 32-Bit-Versionen unterstützt werden. Bei Linux wird merkwürdigerweise keine solche Ausnahme angegeben.

P.S.: Ein schneller Test der Version 5.0 mit OpenOffice 3.1 unter Windows 7 x64 RC1 zeigte, dass auch hier keine Inkompatibilitäten auftreten.

Testbericht: SanDisk Ultra Backup 32GB

Vor ein paar Wochen wurde in tecchannel.de nachgefragt, ob jemand einen 32 GB großen USB-Stick mit Backup Funktionen testen könnte. Ich habe mich da kurzerhand angemeldet und nach kurzer Zeit den USB-Stick auch zum Testen geliefert bekommen. Meinen Testbericht können Sie bei tecchannel.de nachlesen:

SanDisk Ulta Backup 32GB

Mittlerweile stehen auch Testberichte von 3 weiteren Testern zur Verfügung:

Erfahrungsbericht des SanDisk Ultra Backup 32GB als Festplattenersatz (von Legionen)

TecChannel Lesertest: SanDisk Ultra Backup 32 GByte (von Linuxgirl)

Lesertest 32 Gbyte SanDisk Ultra Backup USB-Stick (Test)