Problematik
Die Problematik bei einem Deployment von «Shared Application’s» ist die verwendete Referenz von anderen Applikationen. Dieses Problem taucht ebenfalls auf, wenn wir manuell vom VisualStudio aus deployen.
Wenn wir also zum Beispiel ein Schema einer «Shared Application» innerhalb einer anderen Applikation referenzieren UND verwenden, so kann diese «Shared Application» nicht mehr einfach gelöscht oder neu deployed werden. Die anderen Applikationen müssen zuerst vollständig gelöscht werden oder es wird eine sogenannte Versionierung angewendet.
Dass verknüpfte Schnittstellen-Komponenten nicht einfach ersetzt werden können, ist einerseits nicht sehr flexibel, andererseits verhindert es aber, dass gewisse Schnittstellen nach dem Deployment nicht mehr korrekt funktionieren.
Lösungsansatz
Versionierung
In der «AssemblyInfo.cs» Datei sind die klassischen Assembly Angaben drin.
Damit wir eine NEUE Version von den Schemas der «Shared Application» deployen können, müssen wir diese nach Änderungen hochzählen:
[assembly: AssemblyVersion("1.0.0.0")]
[assembly: AssemblyFileVersion("1.0.0.0")]
zu
[assembly: AssemblyVersion("1.0.0.1")]
[assembly: AssemblyFileVersion("1.0.0.1")]
Dies macht nicht nur bei einzelnen Anpassungen, sondern auch bei Minor-, Major- oder Versionsreleases Sinn. Hier wäre sicher ein automatischer Versions-Updater für die «AssemblyInfo.cs» Datei sinnvoll.
DevOps Release Pipelines
Im DevOps erstellen wir nun unsere Build Pipelines und Release Pipelines.
An den Build Pipelines ändert sich nichts, während wir die Release Pipelines aufteilen.
Wir haben dann pro Applikation eine Release-Pipeline. In unserem Beispiel eine für den IIS Service und zwei für die BizTalk Applikationen.
· BTS20 Shared BizTalk Application
· BTS20 BizTalk Application
Reihenfolge beachten: «Shared Application» zuerst deployen.
Sobald die Änderungen der Versionierung eingecheckt sind, kann die «Shared Application» deployed werden, aber nur mit dem «UPDATE BizTalk Server Application» Komponenten.
Das Deployment erstellt eine neue Ressourcen-Version im BizTalk. Das wiederum verhindert, dass gewisse Schnittstellen anschliessend nicht mehr laufen.
BizTalk Resources
Das Resultat des Deployment‘s sieht dann in der BizTalk Admin Konsole wie folgt aus:
Wir haben nun zwei verschiedene Versionen der «Shared Application».
Externe DLL’s als LibRepository (Manuelle Schritte)
Alle Applikation (nennen wir sie Haupt-Applikationen), welche diese «Shared Application» verwenden, sollten nun aktualisiert werden und die neuste Version verwenden. Diese Schritte werden hauptsächlich manuell durchgeführt.
Das heisst, wir müssen die alte DLL der «Shared Application» bei all diesen Haupt-Applikationen mit der Neuen ersetzen und die Haupt-Applikation dann neu kompilieren. Dabei kommt es, je nach Erneuerungen, in der neuen DLL der «Shared Application» zu verschiedensten Anpassungen in der Haupt-Applikation.
Sobald diese Änderungen eingecheckt sind, kann auch die Haupt-Applikation wiederum deployed werden.
Sobald alle Applikationen, die diese «Shared Application» verwenden, updatet sind, kann die alte Ressourcen-Version (1.0.0.0) im BizTalk wieder gelöscht werden. Ein solcher Cleanup kann zum Beispiel auch per Script erfolgen.
Fazit
Das automatische Deployment CI/CD mit «Shared Application’s» hat seine Schwierigkeiten auf Grund der Abhängigkeiten und ist deshalb dementsprechend aufwändig. Auf Dauer verbessert sich aber die Übersicht auf die einzelnen Releases und spart Ressourcen.
Ergänzende Links
· Unser eigenes quiTeq:
https://www.quibiq.ch/aktuelles/news-meldung/news/detail/News/wie-update-ich-gemeinsam-genutzte-biztalk-applikationen/
· MS best practices:
https://docs.microsoft.com/en-us/biztalk/core/best-practices-for-deploying-a-biztalk-application
· Pipeline Gemeinheiten:
https://www.biztalk-server-tutorial.com/2011/03/02/schema-versioning-in-biztalk-server/
