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

Umstellung des Benutzerverzeichnisses „/Users“ auf eine andere Partition unter Mac OS X

Es gibt mehrere Möglichkeiten diese Aufgabe zu lösen. Ich stelle hier zwei Wege, wie man entweder das Benutzer-Verzeichnis eines Benutzers verschiebt, oder den kompletten Benutzer-Ordner umlenkt (gilt auch für allen danach neu angelegte Benutzer).

1. 1. Benutzer-Verzeichnis eines Benutzers verschieben.

Systemeinstellungen -> Benutzer
Bild 1: Systemeinstellungen: Benutzer

Melden Sie sich am besten als ein anderer Benutzer, als der, den Sie „umziehen“ möchten.

Öffne Sie die Systemeinstellungen und gehen Sie auf das Punkt Benutzer (siehe Bild 1). Unter Benutzer schalten Sie zuerst die Änderungsfunktion frei (das geschlossene Schloss unten links anklicken und mit Administratorrechten freigeben). Nun können Sie unter den Benutzer auswählen, dessen Benutzerordner Sie verschieben möchten. Klicken Sie auf diesen mit der rechten Maustaste (Kontextmenü) oder „Ctrl +  linke Maustaste“. Im Kontextmenü den Punkt „Erweiterte Optionen“ auswählen. Es gibt ja nur diesen Kontextmenü-Eintrag :-) (siehe Bild 2).

Erweiterte Optionen
Bild 2: Erweiterte Optionen

Im neuen Unterfenster kann unter anderem auch der Benutzerordner neu festgelegt werden (siehe Bild 3).

Ordner ändern
Bild 3: Ordner ändern

Der Zielordner muss auf dabei bereits vorhanden sein.

Diese Methode hat einen entscheidenden Nachteil. Für jeden neu angelegten Benutzer muss die Prozedur wiederholt werden. Das ist zwar im häuslichen Bereich bei 2-3 Benutzern vertretbar, bei mehr Benutzern empfehle ich aber die zweite Methode: „Umlenken des gesamten /Users Ordners“.

2. 2. Umlenken des gesamten /Users Ordners

Für diese Methode müssen wir uns des Terminals bemühen, da die Umlenkung des /User-Ordners durch einen so genannten symbolischen Link geschehen wird.

Als Erstes meldet man sich als Administrator an. Nach der Anmeldung sollten keine Programme im Hintergrund laufen (Mail usw.), da sonst das Löschen nicht richtig funktioniert (/Users wird sofort wieder neu angelegt). Das einzige Programm, das laufen soll, ist ein Terminalfenster.

Im zweiten Schritt wird das /Users-Verzeichnis auf die Zielpartition kopiert. Entweder über das Terminal oder auch mit dem Finder.

# sudo cp -Rp /Users /Volumes/NeuePartition/Users

Als Nächstes muss das „alte“ /Users-Verzeichnis gelöscht werden. Das erledigt man auch am besten im Terminal-Fenster.

# sudo rm -R /Users

Im letzten Schritt legt man das Symbolische Link an, damit das Verzeichnis /Users auf den Ordner auf der anderen Partition zeigt.

# sudo ln -s /Volumes/NeuePartition/Users/ /Users

Jetzt nur noch abmelden und neu anmelden. Alle Benutzer liegen nun auch der anderen Partition, auch neu angelegte.

Wer auf Nummer sicher gehen will, sollte diese Operationen entweder von einer Installation auf einer externen HDD starten oder von der Boot-DVD (Terminalfenster aufrufen, bevor die Installation anfängt). Dann sägt man sprichwörtlich nicht an dem Ast, auf dem man gerade sitzt.

In diesem Fall muss /Users durch /Volumes/SystempartitionName/Users ersetzt werden.

Auf demselben Weg kann auf Wunsch auch das Programm-Verzeichnis auf eine andere Partition „verschoben“ werden.

Nach der Neuinstallation des Systems muss man nur den symbolischen Link neu setzten und alle Benutzer (incl. aller deren Einstellungen) sind wieder da.

Ich hoffe dieser Beitrag hat einigen geholfen, das Mac OS X noch ein wenig komfortabler zu machen.

WARNUNG: Das Arbeiten im Terminal mit administrativen Rechten erfolgt auf eigene Gefahr. Jeder, der sich auch das Terminal begibt, sollte wissen, was er mit dem System mach, da es hier keinen doppelten Boden und keine Sicherheitsabfragen gibt. Ein SuperUser darf eben ALLES machen, ohne Nachfragen.

Update von Windows XP auf SP3 unter Snow Leopard (Bootcamp 3.0)

Die Neuerung, die Snow Leopard in Verbindung mit Bootcamp mit sich bringt, ist dass man nun auf die OS X Laufwerke unter Windows lesend zugreifen kann. Dieses an sich sehr schönes Feature bringt aber zugleich auch Probleme bei einer Neuinstallation von Windows XP (< SP3). Wenn man versucht SP3 nach der Installation der Treiber zu installieren, sieht Windows auch die Mac-Partitionen, die richtigerweise vor der Windows-Partition sitzen. SP3 versucht aber auf die erste Partition einige Dateien zu schreiben. Diese ist aber Mac OS X Systempartition, auf die Windows nur Schreibzugriff hat. Die Installation bricht immer wieder ab.

Die Lösung liegt darin, das Feature, die Mac-Partitionen zu sehen, temporär auszuschalten. Dazu muss im Ordner:

c:\Windows\System32\Drivers

In diesem Ordner muss die Datei AppleMNT.sys umbenannt werden. Nach dem Neustrat von Windows, werden die Mac-Partitionen nicht mehr erkannt und man kann den SP3 wie gewohnt installieren. Nach der Installation kann die Datei AppleMNT wieder zurück umbenannt werden.

Die Problematik ist auch bei Apple Support gut erklärt.

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.

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)