Was bisher geschah…
Hallo miteinander
Schon bald lange ist’s her seit meinen letzten Beiträgen. Und ich muss zugeben, dass ich in der letzten Zeit etwas zu beschäftigt war und leider nicht die Zeit für regelmässige Beiträge fand. Jetzt bin ich aber wieder da, mit alter Frische und bereit der Welt viele positive Überraschungen zu offenbaren. Aber lassen wir die Katze nicht gleich im ersten Blog nach dieser Pause aus dem Sack.
Immer wieder hören wir, wie wichtig aktives Konfliktmanagement im Softwarebereitstellungsprozess sei. Vor allem innerhalb grösseren Unternehmungen mit einem erweiterten Umfang an zu integrierender Software, ist ein grosses Bedürfnis vorhanden, mit aktivem Konfliktmanagement die Einsparpotentiale innerhalb von Applikations-Lebenszyklen vollständig zu nutzen und proaktiv, anstatt reaktiv Software-Probleme zu lösen. Aber was bietet uns das Konfliktmanagement überhaupt? Wie weit gehen bestehende Lösungen und was sind die Schwächen?
Wenn man auf dem Markt die Augen offen hält, findet man genau zwei Schwergewichtige Firmen, welche ein Konfliktmanagementsystem für die Softwarepaketierung anbieten. Dies sind Symantec mit dem Conflict Manager, welches Bestandteil der Suite Wise Package Studio Professional ist und Acresso mit dem ConflictSolver, welcher mit dem AdminStudio Professional oder Enterprise vertrieben wird. Beide haben ähnliche Strategien und der eine fühlt sich beim ConflictSolver, wo wir noch eine integrierte ICE Validierung finden, eher zu Hause, der andere mag dagegen vielleicht lieber den Conflict Manager von Wise, bzw. Symantec. Bei Symantec figuriert der Conflict Manager als Teil einer ganzen Paketierungs-Philosopie, die unter dem Namen ESP, Enterprise Software Pakaging bekannt ist. Diese dort dokumentierten Bestpractice Ansätze kann ich ihrer Theorie nach nur unterstützen. Dennoch, was mich persönlich bei beiden Konfliktmanagementlösungen auffiel, ist die Tatsache, dass beide Produkte vor allem bei der Korrektur der ermittelten Konflikte Mängel aufweisen und es dem Softwarepaketierer nicht wirklich einfach gemacht wird. Ich möchte im Folgenden auf einige wenige dieser Mängel im Zusammenhang mit dem Conflict Manager von Wise Package Studio eingehen:
- Kein Auflösen von Windows Installer Standardproperties
Standardproperties, die der Windows Installer während des Costingprozesses ermittelt (weit über 100 Properties), werden durch den Wise Conflict Manager nicht aufgelöst (USERNAME, ComputerName, etc). Diese werden dem Paketierer vor allem bei der Ansicht von Registryeinträgen im Conflict Manager oder im Software Manager vorenthalten, bzw. verleiten zu Missinterpretationen.
- Diverse in der Filetabelle ausgewiesene Dateien, die nicht zu PE-Dateien gehören, führen generell zu keinem Konflikt
In zwei Softwarepaketen verwendete gleichbenannte Dateien in gleichen Verzeichnissen führen nicht zu einem Konflikt, wenn die ComponentId der entsprechenden Komponente unterschiedlich ist und die Komponente keine zusätzlichen Attribute vermerkt hat. Dies müsste eigentlich ein Konflikt ergeben, da nach Installation beider Produkte auf dem selben Client und anschliessender Deinstallation des einen Produktes die Datei entfernt wird und in der Folge der anderen Software fehlt.
- Nichtberücksichtigen des Aktionsstatus der Komponente
Egal, ob das Feature zur Installation kommt oder nicht und ob die Komponente aufgrund von Conditions zur Installation markiert ist oder nicht, Wise Conflict Manager gibt alle Konflikte ungefiltert aus den kompletten Ressourcen wieder. In den meisten Fällen möchte man aber nur diese Konflikte bereinigen, die im produktiven Umfeld auch zu Konfliktauswirkungen führen würden. Nach dem Motto: Ändern soviel wie nötig, aber so wenig wie möglich. Dieses Konzept lässt sich bei Wise Conflict Manager nicht anwenden.
- Irritierende Konfliktausgabe bei Dateikonflikten, wenn sich diese in unterschiedlichen Verzeichnissen befinden
Wise Conflict Manager markiert auch einen Konflikt, wenn eine Datei in zwei unterschiedlichen Softwarepaketen einen gleichen Namen trägt, aber jeweils in unterschiedlichen Verzeichnissen vorkommt. Der Konflikt erwächst, wenn andere Eigenschaften wie beispielsweise die Dateiversion dieser Dateien unterschiedlich sind. In meiner Praxis haben mich solche Konfliktanzeigen meist nur irritiert, denn meistens werde ich der Appplikation ihre eigenen Ressourcen mit ihren vorgesehenen Dateiversionen verwenden lassen, ausser es handelt sich um eine Datei, welche aufgrund eines zwingenden Patches geupdatet werden muss. Für solche Fälle gibt es aber andere Mechanismen der Erkennung.
- Mit speziellen Attributen korrigierte Komponenten werden nachwievor als Konflikt angezeigt
Werden bei einem Konflikt, der gleiche Ressourcen mit beispielsweise gleichen Eigenschaften (Version, date, etc) betrifft und der zu Konfliktauswirkungen bei einer gemeinsamen Installation zweier oder mehrerer konfliktierender Pakete und anschliessender Deinstallation eines Pakets entstehen kann, die Attribute mit beispielsweise msidbComponentAttributesPermanent erweitert, erscheint der korrigierte Konflikt in dem korrigierten Paket nachwievor und irritiert den Softwarepaketierer erneut. Dass im anderen, nicht angepassten Paket, die Ressource nachwievor als Konflikt ausgewiesen wird, ist klar. Unlogisch ist aber, dass aus der Anpassung keine Konflikt-Veränderung beim veränderten Paket resultiert.
- Automatische Korrektur: Synchronisation von ComponentIds, wo die Ressourcen unterschiedlich sind oder in unterschiedlichen Verzeichnissen vorliegen!
Zum Teil werden auch ComponentIds abgeglichen, obwohl die Ressourcen der abgeglichenen Pakete nicht gleich sind oder die Ressourcen aus unterschiedlichen Verzeichnissen stammen! Daraus sind zwangsläufig vielfach weitere Probleme zu erwarten. Siehe hierzu auch… Changing the Component Code
- Automatische Korrektur: Keine Anpassung der meisten Registrykonflikte
Die meisten Konflikte sind üblicherweise in der Registry oder aufgrund von SelfReg-Einträgen zu verzeichnen. Für die automatische Anpassung solcher Konflikte fehlen entsprechende Regeln (ausser ComponentId-Abgleich, der aber bei Registryressourcen sowieso nur in den seltesten Fällen zum Einsatz kommen kann)
- Automatische Korrektur: Unnötige Erweiterung von diversen Properties und Wise-Tabellen
Dieses „Feature“ verfolgt Wise konsequent in allen Tools und ist zum Teil auch störend. Als Ergebnis findet man nach der automatischen Anpassung über die Funktion Resolve with Rules diverse Wise-typische Erweiterungen von Properties und Wise-Tabellen im Korrekturpaket oder in der Korrekturtransformation, die mitunter auch zu Kolateralschäden führen können.
Fazit
Aus diesen Merkmalen lässt sich bereits erkennen, dass mit dem Conflict Manager, aber auch mit dem ConflictSolver ein aktives Konfliktmanagement schwierig ist. Einerseits erhalten wir durch eine automatische Anpassung selten eine konfliktfreie Situation, zweitens werden uns wichtige Konflikte vorenthalten (bspl. SelfReg), und nicht zuletzt muss fast jeder einzelne Konflikt eigens analysiert und deren Wahrheitsgehalt überprüft werden. Dies erfordert hohes Sachverständnis und viel Zeit. Und wenn man nicht genügend dokumentiert, fallen bei repetativen Analysen eines Pakets die gleichen Fragen später wieder an. Aus meiner Sicht sind die genannten Tools sehr umfangreich, bieten zum Teil auch erstklassige Zusatzfunktionen wie Remotekompilation, Revisionsmanagement, etc., sind hervorragend in ihre Suite integriert und verzahnt, aber für die Kernaufgaben sind sie, ausser bei der Erste-Hilfe-Analyse nach eingetretenem Schaden (reaktiv), leider nur beschränkt einsetzbar. Schwierigkeiten ergeben sich insbesondere auch bei der Integration von nicht aufgezeichneten Paketen, die bereits durch den Hersteller als Windows Installer Paket vorliegen.
Was bedeutet dies für uns Softwarepaketierer? Sollen wir auf das Design von qualitativ hochwertigen Windows Installer Paketen, welches auch im Verbund mit anderen Softwarepaketen noch fehlerfrei funktionieren, verzichten?
Nein! Aber mit diesem Thema möchte ich Euch erst in einem späteren Beitrag überraschen.
