Suche

über alle News und Events

 

Alle News

 

Ein knackiger und kompakter Überblick auf die...

Weiterlesen

Auch am dritten Tag gab es interessante...

Weiterlesen

Die großen Ankündigungen aus dem ersten Tag...

Weiterlesen

Keynote - Stand der Integration - Jon Fancey:...

Weiterlesen

Integrieren Sie noch oder managen Sie bereits den...

Weiterlesen

Inwieweit lassen sich vorhandene BizTalk Lösungen...

Weiterlesen

Wie kann ein Prozess Monitoring einfach und...

Weiterlesen

Führende Veranstaltung rund um Connectivity auf...

Weiterlesen

Stellenanzeige: Wir suchen dringend an unserem...

Weiterlesen

How-to: DevOps Deployment CI/CD - BizTalk Shared Application

Automatisches Deployment CI/CD ist immer mehr ein Thema. Man hat nicht nur eine bessere Übersicht über die Releases, sondern spart auf Dauer auch Ressourcen. Dabei werden auch Applikationen deployed, die von verschiedenen anderen Applikationen gebraucht werden: Sogenannte «Shared Application’s».

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/


­­­

Ihre Kontaktmöglichkeiten

Sie haben eine konkrete Frage an uns


 

Bleiben Sie immer auf dem Laufenden


 

Mit meinem "Ja" erkläre ich mich mit der Verarbeitung meiner Daten zur Zusendung von Informationen einverstanden. Ich weiß, dass ich diese Erklärung jederzeit durch einfache Mitteilung widerrufen kann. Bei einem Nein an dieser Stelle erhalte ich zukünftig keine Informationen mehr.

© QUIBIQ GmbH · Impressum · Datenschutz