Suche

über alle News und Events

 

Alle News

 

Die E-Rechnung kommt. Sind Sie vorbereitet?

 

Weiterlesen

Start am 3. August 2020: Jerome, unser erster...

Weiterlesen

Automatisches Deployment CI/CD ist immer mehr ein...

Weiterlesen

Stellenanzeige: Wir suchen dringend an unserem...

Weiterlesen

Nordex Energy Customer Success Story: Effiziente...

Weiterlesen

Das klingt perfekt: Einfacher Nachrichten- und...

Weiterlesen

Auf der INTEGRATE 2020 läutet Jon Fancey,...

Weiterlesen

20 Jahre ist es her, dass Dr. Felix Weil, Dr.-Ing....

Weiterlesen

Zunächst sind wir glücklich darüber, dass bislang...

Weiterlesen

Homeoffice, Online-Konferenzen, ein...

Weiterlesen

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/


­­­

Nehmen Sie gerne hier Kontakt zu uns auf

 

© QUIBIQ GmbH · Impressum · Datenschutz