Fallbeispiele
Situation: Ein Kunde möchte eine Fehlerbehebung oder ein Update für eine bestimmte Version des Produkts.
Was passiert: Die spezielle Version des Kunden muss erst einmal
reproduziert werden. Wenn nicht alle Sourcefiles, Makefiles, Optionen,
Tools, Plattformen, Derived Objects und Released Objects sehr sorgfältig
versioniert wurden, kann das zu einer zeitaufwendigen Aufgabe werden.
Anschließend wird das Update eingespielt. Weil nicht klar ist, welche
zusätzlichen Bereiche des Programms mit dem Update tangiert werden, muss
jedes Mal ein sehr großer Bereich überarbeitet werden, um
Fehlermeldungen zu vermeiden. Die Entwickler arbeiten also großräumig um
das Problem herum, weil die Übersichtlichkeit fehlt.
Die LÖsung mit GMPS 5.0: Durch das automatische Versionieren beim Buildrun ist die Reproduzierbarkeit gegeben. Die Entwickler können die Version des Kunden anhand der eindeutigen Versionsnummer sofort nachbauen und das Update einspielen. Mithilfe der graphischen Darstellung der Abhängigkeiten können die Entwickler nun überprüfen, welche Targets tatsächlich von dem Update betroffen sind und müssen nur diese Targets überarbeiten. So wird die Update-Produktion beschleunigt und der Zeitaufwand minimiert sich.
Unser Tipp: Für eine bessere Übersichtlichkeit innerhalb ihrer Softwareentwicklung empfehlen wir unseren Kunden mit vier essentiellen VOBs (Versioned Object Bases/Datenbanken) zu arbeiten. Diese sind 1. der Source-VOB, in dem alle Source-Codes gespeichert sind, 2. der Tools-VOB, in dem alle verwendeten Werkzeuge gespeichert sind, 3. der DO (derived objects) -VOB, in dem alle erzeugten Objekte gespeichert sind und 4. der Release-VOB, in dem alle ausgelieferten Versionen gespeichert sind. So kann die Reproduktion einer bestimmten Version schneller erfolgen.
Situation: Im Projekt wird vom Versionsverwaltungssystem ClearCase auf Subversion umgestellt.
Was passiert: Die Entwickler müssen lernen mit dem neuen System umzugehen, sie müssen die neuen Kommandozeilenbefehle lernen und die neue Art ein Makefile zu schreiben. Bei Subversion ist das Makefile umfangreicher und komplizierter zu schreiben als bei ClearCase. Diese Umstellung kostet natürlich Zeit, die Entwickler können nicht mit gewohnter Schnelligkeit weiterarbeiten.
Die LÖsung mit GMPS 5.0: Mit GMPS 5.0 muss der Entwickler weiterhin nur das gmk-File schreiben. Der Umfang des gmk-Files ändert sich auch bei der Umstellung auf Subversion nicht. So muss der Entwickler nur die neuen Kommandozeilenbefehle lernen, nicht aber die Schreibweise des Makefiles. So kann der Zeitaufwand der Umstellung um einen nicht geringen Anteil reduziert werden.
Situation: Im Projekt wird die gesamte Struktur geändert.
Was passiert: Wird während der Softwareproduktion festgestellt, dass die
Struktur der Entwicklung unzureichend ist, kann es sein, dass diese
komplett geändert wird. Unter ClearCase und unter Subversion ist es
möglich die alte Struktur zu labeln bzw. zu taggen und dann eine neue
Struktur anzulegen. Nun müssen natürlich in allen Makefiles die
Speicherorte der Dateien geändert werden, damit diese beim nächsten
Buildrun wieder gefunden werden. Bei umfangreichen Projekten kann das zu
großen Verzögerungen in der Produktion führen.
Die LÖsung mit GMPS 5.0: Auf der zentralen "register/unregister-Seite" von GMPS 5.0 werden im Falle der Umstrukturierung des Projekts alle
alten Directories auf "unregister" gesetzt und alle neuen auf "register" und schon kann gmsmake wieder die Makefile-Generierung starten. Durch
die zentrale Konfigurierbarkeit von GMPS 5.0 kann in diesem Fall wieder
viel Zeit eingespart werden und der Projektleiter hat zusätzlich die
Sicherheit, dass wirklich alle Targets die neue Struktur übernommen haben.
Situation: Ein Entwickler ändert den Namen einer Library.
Was passiert: Der Entwickler kann nicht absehen, welche Folgen diese
Namensänderung hat. Er kann normalerweise nicht überprüfen, welche
Targets diese Library aufrufen und verwenden. Sobald er den Namen der
Library geändert hat, gehen alle Aufrufe der anderen Entwickler nach der
Library ins Leere und die Makefile-Generierung schlägt fehl.
Die LÖsung mit GMPS 5.0: Der Entwickler kann mithilfe der graphischen Darstellung der Abhängigkeiten überprüfen, wer außer ihm die Library noch benutzt und kann den entsprechenden Entwicklern den neuen Namen der Library mitteilen. Diese können dann in ihrem Target den Aufruf ändern und die Makefile-Generierung verläuft problemlos.
Sie haben ein SCM-Problem in Ihrem Projekt, das hier nicht aufgeführt ist? Dann berichten Sie uns davon und wir schicken Ihnen unseren Lösungsvorschlag mit GMPS 5.0 per E-Mail zu.
