| - | ||
| | |
Uniface ohne KM-Kontrolle
Wenn Uniface ohne einen externen Quellcode-Manager verwendet wird, wird der gesamte Quellcode zentral in einer Datenbank Ihrer Wahl abgelegt. Es ist dabei unerheblich, ob es nun Code 'in Arbeit' oder 'Fehler beseitigt' oder vielleicht auch Code ist, der überhaupt nicht geändert wurde.
Sie können nun natürlich mehrere Datenbanken aufsetzen, und den Code zwischen diesen mit Hilfe des TRX import/export hin- und her kopieren, aber es wird immer jede dieser Datenbanken den GESAMTEN Code enthalten.
Dies liegt in der Natur von Uniface: Der Quellcode wird in Datenbank- Tabellen gespeichert. Ein Beispiel: Eine Tabelle habe 2 Komponenten, eine Hintergrundform bzw. ein Service zum Speichern und eine Anzeigeform. Jetzt wird die anzeigeform verändert, die Hintergrundform soll jedoch nicht verändert werden und somit auch nicht änderbar sein (Referenz-Code). Da aber beide Forms in der gleichen Datenbank-Tabelle sind, kann der Entwickler nicht nur einen Satz, sondern jeden Satz verändern.
Häufig wird dies mit Hilfe von Import/Export der zu ändernden Komponenten kontrolliert. Dieses Verfahren führt häufig zu Fehlern in Test- oder Integrationsumgebungen, von einfachen Problemen wie falsche Version bis hin zu komplizierten, nicht kontrollierbaren Änderungen früherer Versionen derselben Form etc.
Uniface mit dem UD6/CMtool Treiber und einem SCM/CM Werkzeug
Der UD6/CMtool Treiber erlaubt eine einfache quellcode-Kontrolle, indem er JEDE KOMPONENTE in einer eigenen Datei speichert, die von einem SCM/CM - Werkzeug oder vom Betriebssystem selbst kontrolliert werden kann.
Dazu müssen Sie einige Entscheidungen treffen, die sie früher nicht hatten. Die wichtigste ist:
Die 2. Frage 'Wo speichere ich meinen Entwickler-Code' wird noch detaillierter:
Es können verschiedene Kombinationen dieser 3 Basis-Möglichkeiten verwendet werden. Dies sollte im vorfeld geklärt werden.
quellcode, der nicht verändert werden kann
Der UD6/CMtool Treiber speichert Ihren Uniface Quellcode in normalen ASCII-Textdateien ab (im XML-Format). Die Dateien liegen in einer Verzeichnis- Struktur, die von Ihrer Assignment- und der Joins-Datei abhängen (Weitere Informationen dazu in der Installationsanleitung)
Nachdem Ihre Quellen in diese Struktur geladen und kompiliert wurden, werden normalerweise in einem ersten Schritt die Quellen schreibgeschützt, entweder mit Hilfe des Betriebssystems oder durch Laden in einen Quellcode- Manager (SCM) oder mit einer Kombination von beiden.
Einige Quellcode-Manager speichern Ihren Quellcode in einem Repository, welches keine Möglichkeit zum reinen Lesen der Referenzobjekte gestattet. Bei solchen Werkzeugen (wie z.B. CVS und PVCS) läuft beim 'Check In' und 'Check Out' ein zusätzliches Script, das eine 'Referenzumgebung' bereitstellt. In den entsprechenden Seiten der Hilfe-Datei finden Sie Details, wie solche Scripte angelegt werden.
Andere CM-Werkzeuge wie z.B. ClearCase haben ihre eigenen NFS-artigen Dateisysteme für den reinen Lesezugriff.
The Quellcode, der von einem oder mehreren Entwicklern verändert werden kann
Versionsmanagement ist wesentlich mehr, als nur eine Datei auf schreibgeschützt oder schreibbar zu ändern. Eine Änderung sollte nicht in den 'Referenzbereich' gelangen, bevor Sie fertig und getestet ist. Also sehen folglich einige Benutzer den Code, der gerade in Arbeit und damit verändert ist, während andere den 'alten' Referenzcode sehen.
Wenn also ein Entwickler eine Änderung machen möchte, so wird der Quellcode in einen anderen Bereich 'kopiert'. Dies wird im Allgemeinen als 'INUSE-Bereich', Sandkasten, Entwicklungsbereich, Arbeitsverzeichnis etc. bezeichnet. Der UD6/CMtool Treiber unterscheidet diese Dateien vom Referenzbreich, indem er sie in der INUSE-Datei einträgt. Die INUSE-Datei wird von den Diensprogrammen 'add2list.exe' and 'del2list.exe' verwaltet.
In den entsprechenden Kapiteln der Hilfedatei finden Sie detaillierte Informationen, wie sie dieses Verfahren für die gängigen SCM/CM-Werzeuge automatisieren können.
Wenn Sie ALLEN Enwicklern erlauben wollen, den modifizierten Code zu sehen:
Schützen der Quellen vor Beschädigung
Manche gehen einen Schritt weiter und erlauben es In dieser Situation sind die Quellen auf einem oder mehreren Servern, und können
nur von der Maschine 'gesehen' werden, auf der der Uniface Polyserver läuft.
Alle Dateien wie INUSE, JOINS etc. befinden sich auf dem Polyserver.
Verschiedene Entwickler oder Entwicklungsteams können durch verschiedene
Login in der Client-Assignment-Datei ihre 'eigenen' INUSE- bzw. JOINS-Dateien
haben . Ein Entwickler kann den Quellcode nur mit Hilfe des IDF 'sehen'.
Im IDF selbst kann ein entwickler nur auf den Code zugreifen, der durch das
SCM/CM-Werkzeug und den UD6/CMtool Treiber freigegeben ist. Das Aufsetzen einer solchen Umgebung mit dem UD6/CMtool Treiber sollte für
einen Administrator mit Polyserver-Schulungen nicht schwierig sein. Sie können
natürlich auch bei uns speziell geschulte Berater anfordern. Ein Hinweis zum Schluss: Wenn eine Organisation mit Uniface entwickelt und eine Quellcode
Kontrolle einführen möchte, sind WESENTLICHE Erfolgsfaktoren zu beachten: Wir haben speziell dann eine hohe Fehlerquote beobachtet, wenn die Entwickler
vom dahinter liegenden Quellcodemanager / Konfigurationsmanager 'ausgeschlossen'
sind. Firmen, die solche Werkzeuge wie PVCS, eChange Man, ClearCase etc.
entwickeln und vertrieben, haben viel Zeit und Geld in Produkte investiert,
die gerade die Entwickler unterstützen sollen. Wenn diese vor den Entwicklern 'versteckt' werden, scheint das eine hohe
Fehlerquote nach sich zu ziehen. Read more about Uniface Version Control
$Revision: 1.4.4.5 $ $Date: 2003/09/16 17:52:10 $ [go to top]