Teamarbeit und umgebungspezifisches Repository – Best Practice?

  • Beitrag
    HoffmannK
    Teilnehmer
    Hier ein kleiner Beitrag, welcher Neueinsteigern, die noch großes vorhaben, vielleicht hilft.

    Es gibt bereits die Anleitung, wie man sein Repository in GitHub einbindet. Wir nutzen hier TFS.
    Wenn 2 Kollegen auf 2 Entwicklungsservern parallel an Themen arbeiten gibt es zwangsläufig Überschneidung. Da hilft bei den Ressourcen auf jeden Fall der Abgleich über den TFS.

    Damit allein ist es aber zumindest in unserer Umgebung nicht getan.
    Aktuell setzen wir 3 vollständig getrennten Nachrichtenstrecken ein. Wir nennen Sie PRO (produktiv), TST (test) und DEV (development).
    Jede dieser Stecken hat z.B. eine Anbindung an eine eigene Projektmanagement, Personalmanagement und ERP-Software. (vollständig getrennte Instanzen)

    Daraus ergibt sich zwangsläufig, dass auch die Adapteranbindung immer eine eigenständige ist.
    Bislang haben wir das stets so gelöst, dass die Adapter nicht an ein Projekt gebunden sind. Beim Austausch der jeweiligen Repository beschränkten wir uns auf den Austausch mit einem Filter über Projekte. Das System wird aber mit jedem zusätzlichen Abgleich von Inhalten (Artikel, Projekte, Kunden,…) immer komplexer.
    Wir haben daher auf jedem Server immer den für diesen Server gültigen Adapter z.B. ADR-ERP für den lesenden Zugriff auf die ERP-System-Datenbank.
    Zusätzlich zu diesem gibt es dann immer gleich für alle Umgebungen den spezifischen Adapter. In diesem Fall ADR-ERP-PRO, ADR-ERP-TST und ADR-ERP-DEV.
    Den Verweis auf die jeweiligen Adapter bilden wir mittel Variablen im jeweiligen Prozess ab. So kann man auch mal schnell aus der DEV auf Daten der PRO zugreifen, wenn notwendig.

    Neben den Adaptern gibt es aber auch noch eine XML-Ressource mit Konstanten. Diese dient z.B. der Unterscheidung bei Fehlernachrichten. So können Nachrichten sofort nach Quell-, Ziel- und Übertragungssystem unterschieden werden.

    Diese System machte es aber mit den aktuellen Möglichkeiten auch schwierig mal das gesamte Repository über alle Server glatt zu ziehen.

    Daher habe ich die einzelnen Möglichkeiten so umgenutzt, dass mittels eines kleinen Powershell-Skripts die notwendigen Anpassungen vorgenommen werden.

    Ich exportiere das Repository nicht als ZIP-File, sondern in den lokalen Ordner für den TFS-Abgleich.
    Mittels des Skripts kann ich nun die notwendigen Attribute der Adapter auf den Standard-Adapter übertragen. Auch die XML-Ressource wird so kopiert.
    Und wenn ich es möchte, werden auch gleich alle „Nachrichten mit Zeitstempel“ deaktiviert.

    Diese Skript liegt mit im Abgleichordner mit den umgebungsspezifischen Aufrufen. Wenn man auf Nummer sicher gehen möchte, kann man das Repository während der Anpassung auch in einen neuen Austauschordner verlagern.

    Falls jemand zu ähnlichen Themen eine bessere Lösung hat, würde mich das sehr interessieren.

    Wer möchte, kann das Skript auch gern nutzen. Bislang hat die Änderung an den XML-Quellen kein Problem im Repository verursacht.

    0
    0
Ansicht von 1 Antwort (von insgesamt 1)
  • Antworten
    Hallo Herr Hoffmann,

    Danke für den sehr interessanten Beitrag!

    Um eine saubere Trennung zwischen allgemeiner Flusslogik und umgebungsspezifischen Parametern ohne separates Skript zu realisieren, empfehlen wir eine Trennung der Projekte sowohl im TRANSCONNECT® als auch in der Versionsverwaltung.

    In Ihrem Beispiel würden also die Prozessressourcen und Transformationen, die auf allen Umgebungen gleich sind, in einem Projekt liegen, nennen wir es MAIN. Zudem würde es drei Projekte PRO, DEV und TST geben, die jeweils den Adapter ADR-ERP sowie die xml-Ressource mit Umgebungskonstanten enthalten – entsprechend mit umgebungsspezifischen Parametern. Eine Umgebung neu aufzusetzen würde entsprechend den Import des MAIN-Projekts und eines Umgebungsprojekts erfordern.

    Vorteile dieser Variante:

    • Keine separate Skript-Verwaltung notwendig.
    • Keine Schalter in Prozessen notwendig, das MAIN-Projekt reduziert sich auf den Logik-Kern.
    • Die Zugangsverwaltung zu Zielsystemen kann auch in der Rechteverwaltung komplett getrennt von der Implementierung der Prozesslogik geschehen.
    • Die Umgebungsprojekte können separat von der Prozesslogik in der CI/CD hinterlegt werden.

    Am Ende ist die Entscheidung für eine Variante sehr abhängig von den konkret bei Ihnen existierenden Deployment-Prozessen und anderen Randbedingungen.

    Wir sind sehr interessiert daran, im Bereich umgebungsübergreifendes Deployment noch besser zu werden – und freuen uns immer über weiteres Feedback oder Erweiterungsvorschläge am TRANSCONNECT®.

    Viele Grüße,

    Sebastian Melzer

    0
    0
Ansicht von 1 Antwort (von insgesamt 1)
  • Du musst angemeldet sein, um auf dieses Thema antworten zu können.