|
Erstellen eines SVS Paketes (TotalCommander) mit Hilfe von Wise Package Studio. Dabei wird das Paket vollständig manuell erstellt, es basiert also nicht auf einem SnapShot (SetupCapture).
ERSTELLEN EINES "TOTALCOMMANDER" SVS PAKETES
Diese Anleitung soll als Einstieg dienen, wie ein Altiris SVS Paket entwickelt wird.
Als Beispielprogramm wird dabei das Shareware Programm „Total Commander 7.02“ von Christian Ghisler (www.ghisler.com) verwendet. Dieses ist einerseits vom Aufbau relativ einfach, zeigt aber andererseits einige wichtige (und durchaus allgemeingültige) Punkte auf, die unbedingt zu beachten sind.
Das Vorgehen wird an Hand einer kompletten Neuentwicklung demonstriert, d.h. die Paketentwicklung wird quasi „auf der grünen Wiese“ begonnen. Es wird also insbesondere nicht auf Basis eines Setup-SnapShots (Setup-Capture Verfahren) entwickelt.
Als Ausgangsbasis für diese Anleitung dient ein Rechner, auf dem das Programm bereits auf traditionelle Weise installiert und konfiguriert ist (C:\Program Files\totalcmd). Dieses Installationsverzeichnis dient im Wesentlichen als Sourcen-Lieferant.
Die Programmentwicklung startet mit dem Sart von „Wise Package Studio“ (im Folgenden mit WPS abgekürzt):
Dort wird das Tool „Virtual Package Editor„ per Doppelklick gestartet.
Erscheint das Fenster „New Virtual Package“ nicht sofort, so wählen wir „Create a New Project“ aus. Hier entscheiden wir uns zum Erstellen einer neuen Applikation im .WVP-Format.
Product Details
Zuerst tragen wir bei „Product Details“ den Namen, die Version und den Hersteller (Manufacturer) der Anwendung ein.
TIP: Am besten die neue Anwendung gleich speichern, z.B. als „Ghisler_TotalCommander_7.02_MUL_1.0.0.wvp“.
In der Praxis hat sich üblicherweise obige Struktur etabliert:
-
Hersteller
-
Produktname
-
Produktversion
-
Produktsprache
-
Paketrelease
Mit der Angabe Paketrelease ist die Revisions-Nummer bei der Paket-Entwicklung gemeint.
Üblicherweise beauftragt ein Kunde das Release _1.0.0.
Die Entwicklungs-Abteilung erstellt ein Paket-Release 1.0.0 und übergibt dieses an die Test-Abteilung.
Falls das Paket den Installations- und/oder Funktions-Test nicht besteht, oder irgendwelche formalen Anforderungen nicht erfüllt werden (z.B. wurden die Namenskonventionen nicht eingehalten), so geht das Paket zurück an die Entwicklungs-Abteilung. Dort wird ein neues Release erstellt, das als Revisionsnummer 1.0.1 erneut an die Test-Abteilung übergeben wird.
Wird das Paket bei der erneuten Prüfung nicht mehr beanstandet wird es an den Kunden ausgeliefert (als Release _1.0.0).
Falls das Paket vom Kunden beanstandet wird geht es erneut mit einer entsprechenden Fehlerbeschreibung in die Entwicklungsabteilung.
Nach der Korrektur der Beanstandung geht das Paket erneut in die interne QA mit der Revisionsnummer 1.1.0. Fällt es dort erneut wegen Fehler durch die Qualitätsprüfung, so muss es erneut korrigiert werden und geht anschließend erneut in die QA, diesmal mit Revisionsnummer _1.1.1.
Bei erfolgreichem Test geht mit der Revisionsnummer _1.1.0 erneut an den Kunden.
Und so weiter.
Pakete, die zum Festpreis abgerechnet werden, werden i.d.R. kostenfrei korrigiert. Alle Pakete mit einer Revisionsnummer _1.x.x werden nur einmal abgerechnet, wenn das Verschulden auf Seiten des Auftragnehmers lag. Selbst kleinere Korrekturen, die auf Grund fehlerhafter Angaben durch den Auftraggeber notwendig wurden sind nicht selten kostenfrei.
Allerdings passiert es auch manchmal, dass die vom Auftraggeber zur Verfügung gestellte Installationsanleitung in der Form fehlerhaft war, dass eine komplette Paket-Neuerstellung notwendig wird. In diesem Fall muss der Auftraggeber einen neuen Paketierungsauftrag ausstellen, der auch entsprechend kostenpflichtig wird. Für diesen Fall beauftragt der Kunden eine Anwendung mit der Revisionsnummer 2.0.0.
Und so weiter!
Files
In dem Menü „Files“, und später auch „Registry“, ist die Aufteilung der Fenster so, dass die obere Ansicht die Ressourcen des Host-Rechners darstellt, die untere den Inhalt des Paketes.
In der Drop-Down-Liste „Sublayer“ lassen sich die Layer „Read-Only“ oder „Writeable“ auswählen. Standardmäßig startet das WPS mit der Ansicht des „Read-Only“-Layers. Im unteren Fensterabschnitt werden jeweils nur diejenigen Paket-Ressourcen angezeigt, die dem entsprechenden Layer zugeordnet sind.
Wir wählen nun oben das entsprechende TotalCommander Verzeichnis (hier: „totalcmd“) der lokalen Festplatte aus und fügen dieses samt Inhalt über „Add Contents“ unserem Paket hinzu. Der entsprechende Ordner „totalcmd“ wird dabei unten automatisch in dem von uns zuvor im unteren Fenster markierten Ordner „Program Files“ angelegt.
Im nächsten Schritt wiederholen wir diesen Vorgang für die Shortcuts:
Im unteren Fensterbereich selektieren wir das Zielverzeichnis, also Windows\Profiles\All Users\Start Menu\Programs\. Im oberen Fensterbereich wählen wir das Verzeichnis C:\Dokumente und Einstellungen\All Users\Start Menü\Programme\ und fügen die Verknüpfung dem Paket hinzu. Dies kann per Drag&Drop oder über den Button „Add File“ geschehen.
Nun müssen noch zwei Konfigurationsdateien des „Total Commander“ in das SVS-Paket integriert werden, die sich bei einer Standardinstallation des TCM im Windows Verzeichnis befinden:
Registry
Dieselben Vorgänge, die bisher für Dateien durchgeführt wurden, müssten jetzt auch für die entsprechenden Registry-Keys durchgeführt werden. Allerdings benötigt der TCM nicht zwangsweise Registry-Keys, deshalb brauchen wir im Menü „Ressources“ -> „Registry“ nichts weiter konfigurieren (tatsächlich werden durch das Originalsetup schon Registry-Keys angelegt, aber wie gesagt, sie sind nicht unbedingt für die Funktion des TCM notwendig).
Im Menü „Registry“ muss für den TCM nichts konfiguriert werden.
Exclusions
In dem Menü “Exclusions” müssen jetzt noch diejenigen Verzeichnisse und/oder Datei-Typen (Datei-Endungen) eingetragen werden, die nicht vom Application-Layer verwaltet werden sollten.
Dazu gehört z.B. die Datei wincmd.ini und alle .bar-Dateien, weil diese Dateien Konfigurationsänderungen des TotalCommanders speichern und wir nicht wollen, dass alle nachträglich (nach dem Import und dem ersten Aktivieren des Application-Layers) vom Benutzer gemachten Einstellungen bei einem Zurücksetzen des Application-Layer verloren gehen. Um nur diese Dateien von der Verwaltung durch den Application-Layer auszuschließen wäre es durchaus ausreichend nur die wincmd.ini und alle .bar-Dateien im “Exclusions” Menü einzutragen.
Viel wichtiger jedoch als das Ausschließen dieser wenigen Konfigurations-Dateien ist es aber ALLE Dateien von der Verwaltung durch den TCM Application-Layer auszuschließen. Ansonsten würden alle Dateioperationen (Konfigurationsänderungen am TCM, File-Copy Aktionen, usw.) im „Writeable“ Sub-Layer gespeichert werden. Bei einem Zurücksetzen (Layer-Reset) des TCM Application-Layers würden all diese Änderungen verloren gehen und ein entsprechenden Datenverlust (Dateien) wäre die unausweichliche Folge!
Mit dieser Erkenntnis definieren als Exclusion den kompletten “Destination Computer” ( = [SYSTEMDRIVE] !.
Diese Einstellung bezieht sich auf das komplette Laufwerk C:\ inkl. Unter-Verzeichnisse.
Dateioperation, die auf Netzwerklaufwerken oder externen USB Geräten ausgeführt werden unterliegen standardmäßig nicht der Layer-Verwaltung, d.a. alle Dateioberationen werden am Basis-System durchgeführt.
HINWEIS: Es ist nicht möglich REGISTRY-Keys von der Verwaltung durch den entsprechenden Applications-Layer auszuschließen.
Jetzt kann man das Paket kompilieren und hat damit ein SVS Paket für den TCM erstellt!
|
