Für ein Unternehmen haben wir eine Azure-DevOps-Schnittstelle für eine bestehende Capability-Mapping-Software entwickelt. Im Mittelpunkt standen die Anbindung an Azure DevOps, der bidirektionale Zugriff auf Work Items sowie Oberflächen für Einstellungen und die Bearbeitung im Kontext der Erweiterung. Ergänzend haben wir die Umsetzung mit End-to-End-Tests abgesichert.
Ausgangslage
Ein Unternehmen wollte seine Capability-Mapping-Software an Azure DevOps anbinden. Die fachliche Aufgabe lag im Umfeld von Business-IT-Alignment, also der abgestimmten Betrachtung von fachlichen Anforderungen und technischer Umsetzung.
Dafür sollte eine Integration entstehen, die den Zugriff auf Work Items ermöglicht und die Nutzung direkt im Umfeld von Azure DevOps unterstützt. Aus dem Projekt ergab sich damit die Aufgabe, eine passende Erweiterung sowie die nötigen technischen Bausteine für den Datenaustausch und die Bedienoberflächen bereitzustellen.
Lösung
Wir haben eine native Azure DevOps Extension umgesetzt und dafür mehrere Bestandteile entwickelt. Dazu gehörten ein Backend-Service für den bidirektionalen Zugriff auf Work Items, eine Settings-Page sowie ein Custom Work Item Control mit AutoSuggest. AutoSuggest bedeutet, dass passende Vorschläge während der Eingabe angezeigt werden.
Die Arbeit lief von Dezember 2022 bis März 2023 in einem Team mit 2 Personen. Zusätzlich haben wir End-to-End-Tests umgesetzt. End-to-End-Tests prüfen komplette Abläufe aus Sicht der Nutzung und helfen dabei, Zusammenspiel und Bedienwege über mehrere Komponenten hinweg zu kontrollieren.
Ergebnis
Geliefert wurde eine Anbindung der Capability-Mapping-Software an Azure DevOps. Bestandteil des abgeschlossenen Projekts waren die native Extension, der Backend-Service für den bidirektionalen Zugriff auf Work Items, die Settings-Page, das Custom Work Item Control mit AutoSuggest sowie End-to-End-Tests.
Die Laufzeit betrug 4 Monate. Das Projekt wurde abgeschlossen.
Technik
Für die Umsetzung kamen Angular 14, TypeScript, React, NGXS, RxJS, Node.js, Jasmine, Karma, TailwindCSS, Azure DevOps Server, Jest und Puppeteer zum Einsatz.
- Angular 14, React und TypeScript dienten der Umsetzung der Oberflächen und Anwendungslogik.
- NGXS und RxJS unterstützten die Steuerung von Zuständen und Datenflüssen in der Anwendung.
- Node.js wurde für den Backend-Service eingesetzt.
- Jasmine, Karma, Jest und Puppeteer wurden für Tests verwendet, darunter End-to-End-Tests.
- Azure DevOps Server bildete die Zielumgebung der Anbindung.
Bei vergleichbaren Vorhaben sind Datenbankentwicklung, Schnittstellen und Datenmigration oft ein zentraler Teil der Umsetzung.
Warum eine Azure-DevOps-Schnittstelle hier sinnvoll ist
Eine Azure-DevOps-Schnittstelle ist dann sinnvoll, wenn Informationen aus einer Fachanwendung im Arbeitskontext der Projekt- oder Entwicklungssteuerung verfügbar sein sollen. Der zentrale Nutzen liegt meist nicht in einer zusätzlichen Maske, sondern darin, dass bestehende Informationen an der Stelle erreichbar werden, an der Teams ohnehin mit Aufgaben und Anforderungen arbeiten. Gerade bei fachlich geprägten Anwendungen hilft das, Medienbrüche zu reduzieren. Medienbruch bedeutet, dass Informationen manuell zwischen getrennten Systemen übertragen oder nachgepflegt werden müssen.
Für solche Vorhaben ist eine Erweiterung innerhalb der Zielplattform oft ein naheliegender Weg. Sie bringt Funktionen dorthin, wo Nutzerinnen und Nutzer bereits arbeiten, statt einen getrennten Zugang zu erzwingen. Wenn zusätzlich ein eigener Dienst für den Datenaustausch aufgebaut wird, lassen sich Aufgaben sauber trennen: Die Erweiterung kümmert sich um Darstellung und Interaktion, der Dienst übernimmt die Verbindung zum Fremdsystem, die Aufbereitung von Daten und die technische Kommunikation. Diese Trennung erleichtert typischerweise Wartung und Weiterentwicklung.
Wichtig ist außerdem die Richtung des Datenaustauschs. In vielen Projekten reicht es nicht, Daten nur zu lesen. Eine bidirektionale Anbindung erlaubt, Informationen in beide Richtungen zu übertragen. Das ist besonders dann relevant, wenn eine Fachanwendung und ein System für Aufgabenverwaltung denselben fachlichen Zusammenhang aus verschiedenen Blickwinkeln abbilden. Work Items sind Arbeitselemente wie Aufgaben, Anforderungen oder Fehlerberichte innerhalb von Azure DevOps.
Auch die Bedienung verdient Aufmerksamkeit. Wenn Eingaben innerhalb eines Work-Item-Kontexts erfolgen, sind kurze Wege und passende Vorschläge häufig wichtiger als eine große Zahl von Funktionen. Ein AutoSuggest-Feld kann hier helfen, weil es bereits während der Eingabe mögliche Treffer anzeigt und dadurch Eingaben vereinheitlicht. Das senkt typischerweise die Gefahr unpassender Zuordnungen.
Für Unternehmen und öffentliche Auftraggeber lohnt sich bei ähnlichen Vorhaben meist eine frühe Entscheidung über die Einbettung: eigenständige Anwendung, integrierte Erweiterung oder Kombination aus beidem. Sobald mehrere Systeme beteiligt sind, kommen zudem Fragen zu Berechtigungen, Datenhoheit, Betrieb und Änderungen an Schnittstellen hinzu. Wer ein solches Projekt plant, sollte diese Punkte nicht erst am Ende klären, sondern schon in der Konzeption gemeinsam mit Fachseite, IT und Betrieb betrachten. Für die eigentliche Umsetzung sind je nach Zielbild oft Webanwendungen und Portale sowie Schnittstellenentwicklung eng miteinander verbunden.
So werden Projekte mit Azure-DevOps-Schnittstelle typischerweise umgesetzt
Bei einer Azure-DevOps-Schnittstelle beginnt ein sinnvolles Vorgehen meist mit der fachlichen Klärung. Zuerst sollte feststehen, welche Informationen aus welchem System stammen, wo sie angezeigt werden und in welcher Richtung Änderungen erlaubt sind. Diese fachliche Zuordnung ist wichtiger, als früh über einzelne Technologien zu sprechen. Wenn nicht klar ist, welches System in welchem Fall führend ist, entstehen später leicht Konflikte bei Datenständen und Verantwortlichkeiten.
Darauf folgt in der Regel ein technisches Zielbild. Dabei wird festgelegt, welche Bausteine benötigt werden: etwa eine Erweiterung in Azure DevOps, ein vermittelnder Dienst für die Kommunikation, Oberflächen für Einstellungen und ein Konzept für Protokollierung und Fehlerbehandlung. Protokollierung bedeutet, dass technische Abläufe nachvollziehbar festgehalten werden, damit Störungen und Auffälligkeiten später untersucht werden können. In vielen Projekten ist außerdem früh zu entscheiden, ob die Anbindung nur lesen oder auch schreiben darf.
In der Umsetzung empfiehlt sich meist ein schrittweises Vorgehen mit kurzen Abstimmungen zwischen Fachseite und Technik. Gerade bei integrierten Oberflächen zeigt sich vieles erst im konkreten Nutzungskontext: Welche Informationen sind wirklich nötig, an welcher Stelle helfen Vorschläge, und welche Eingaben müssen abgesichert werden? Deshalb ist es oft sinnvoll, nicht nur die Verbindung der Systeme zu entwickeln, sondern parallel auch die Bedienoberflächen und die Prüfungen für typische Abläufe.
Ein weiterer wichtiger Teil ist die Qualitätssicherung. Bei Schnittstellenprojekten reicht es selten, nur einzelne Funktionen isoliert zu testen. Entscheidend ist, dass zusammenhängende Abläufe über mehrere Komponenten hinweg geprüft werden. End-to-End-Tests bilden genau solche Abläufe nach und zeigen, ob eine Funktion im Zusammenspiel tatsächlich nutzbar ist. Ergänzend sind klare Testfälle für Fehlerbilder hilfreich, etwa bei unvollständigen Daten, fehlenden Berechtigungen oder nicht erreichbaren Diensten.
Vor dem Livegang sollten schließlich Betrieb und Zuständigkeiten geklärt sein. Dazu gehören Fragen zur Überwachung, zu Fehlermeldungen, zu Änderungen an der Zielplattform und zu den Wegen für Support und Weiterentwicklung. Betrieb meint hier die technische Bereitstellung, Überwachung und Pflege einer Lösung im laufenden Einsatz. Wenn Sie ein ähnliches Vorhaben prüfen möchten, lassen sich erste Anforderungen häufig gut über einen Projekt-Check strukturieren.
Typische Stolpersteine bei Schnittstellen, Daten und Betrieb
Schnittstellenprojekte scheitern selten an einer einzelnen Funktion, sondern eher an unscharfen Annahmen. Ein typischer Stolperstein ist eine unklare fachliche Zuordnung von Daten. Wenn ähnliche Informationen in mehreren Systemen vorhanden sind, muss sauber festgelegt werden, welches System welche Daten liefert, wo Änderungen erlaubt sind und wie Konflikte behandelt werden. Ohne diese Regeln entstehen leicht doppelte Pflege, widersprüchliche Inhalte oder unerwartete Überschreibungen.
Ebenso wichtig ist der Umgang mit Berechtigungen. Nicht jede Person darf jede Information sehen oder ändern, und nicht jede technische Komponente sollte denselben Zugriff erhalten. Deshalb brauchen solche Systeme ein klares Berechtigungskonzept. Ein Berechtigungskonzept beschreibt, welche Rollen welche Aktionen ausführen dürfen und welche Daten dabei sichtbar sind. Gerade bei Anbindungen an Plattformen wie Azure DevOps sollte zudem geprüft werden, wie Identitäten, technische Zugriffe und Freigaben zusammenspielen.
Ein weiterer kritischer Punkt ist die Robustheit gegenüber Änderungen. Zielsysteme, Oberflächen und Datenmodelle entwickeln sich weiter. Wenn eine Integration zu eng an einzelne Details gekoppelt ist, führen kleine Änderungen schnell zu Störungen. Deshalb ist es in solchen Projekten sinnvoll, die Kommunikation über klar abgegrenzte Bausteine zu organisieren und Fehlerfälle bewusst mitzudenken. Dazu gehören etwa unvollständige Antworten, Zeitüberschreitungen, nicht mehr vorhandene Einträge oder vorübergehend nicht erreichbare Dienste.
Auch das Thema Datenqualität wird oft unterschätzt. Vorschlagsfunktionen, Zuordnungen und Suchfelder wirken nur dann verlässlich, wenn die zugrunde liegenden Daten ausreichend konsistent sind. Sonst entstehen mehrdeutige Treffer oder missverständliche Ergebnisse. Wer solche Funktionen plant, sollte daher nicht nur an die Oberfläche denken, sondern auch an Benennungen, eindeutige Merkmale und Pflegeprozesse.
Schließlich gehört der Betrieb von Anfang an in die Planung. Eine Schnittstelle muss nicht nur entwickelt, sondern auch nachvollziehbar betrieben werden. Dazu zählen Protokollierung, Überwachung, geregelte Zuständigkeiten und ein Verfahren für Änderungen. Überwachung bedeutet, dass technische Abläufe und Störungen sichtbar gemacht werden, damit im Betrieb reagiert werden kann. Wenn personenbezogene Daten oder besondere rechtliche Anforderungen betroffen sind, sollten diese Themen früh geprüft und bei Bedarf mit Datenschutzbeauftragten oder juristischer Beratung abgestimmt werden. Für den laufenden Einsatz kann je nach Vorhaben auch der Betrieb in der Microsoft Cloud relevant sein.
Häufige Fragen
Wovon hängen Aufwand und Kosten einer Azure-DevOps-Schnittstelle ab?
Der Aufwand hängt vor allem davon ab, wie viele Systeme beteiligt sind, ob Daten nur gelesen oder auch geschrieben werden, welche Oberflächen innerhalb der Zielplattform entstehen sollen und wie umfangreich Qualitätssicherung und Betrieb vorbereitet werden müssen. Auch Berechtigungen, Fehlerbehandlung und die fachliche Klärung der Datenhoheit wirken sich stark aus. Für eine erste Einordnung eignet sich der Kostenrechner oder ein Projekt-Check auf Basis einer kurzen Beschreibung.
Wie geht man bei einem solchen Integrationsprojekt am besten vor?
Sinnvoll ist ein Vorgehen, das Fachlichkeit, Technik und Betrieb gemeinsam betrachtet. Am Anfang sollten Datenflüsse, Verantwortlichkeiten und Nutzungskontexte geklärt werden. Danach wird ein technisches Zielbild für Erweiterung, Datenaustausch und Oberflächen entwickelt. In der Umsetzung helfen kurze Abstimmungen und eine frühe Qualitätssicherung mit realistischen Abläufen. So lassen sich Missverständnisse bei Funktionen und Zuständigkeiten rechtzeitig erkennen und nachsteuern.
Welche Risiken sind bei einer bidirektionalen Anbindung besonders wichtig?
Kritisch sind vor allem widersprüchliche Datenstände, unklare Führungsrollen der Systeme, unzureichend geregelte Berechtigungen und fehlende Behandlung von Fehlerfällen. Bei bidirektionalen Verbindungen muss klar sein, wann Daten übernommen, geändert oder bewusst nicht geschrieben werden. Ebenso wichtig sind nachvollziehbare Protokolle und klare Regeln für Ausnahmen. Wer diese Punkte zu spät klärt, erhöht das Risiko für Nacharbeit und Störungen im laufenden Betrieb.
Welche Rolle spielen Tests bei einer Azure-DevOps-Schnittstelle?
Tests sind zentral, weil hier meist mehrere Komponenten zusammenspielen: Oberfläche, Zielplattform, vermittelnder Dienst und fachliche Logik. Einzeltests allein reichen oft nicht aus. Wichtig sind vor allem Prüfungen vollständiger Abläufe, damit sichtbar wird, ob die Integration im Nutzungskontext funktioniert. Zusätzlich sollten typische Problemfälle berücksichtigt werden, etwa fehlende Berechtigungen, unvollständige Daten oder vorübergehend nicht erreichbare Verbindungen zwischen den beteiligten Systemen.
Was muss für Betrieb und Weiterentwicklung von Anfang an bedacht werden?
Schon vor dem Livegang sollten Zuständigkeiten, Überwachung, Protokollierung und der Umgang mit Änderungen an der Zielplattform festgelegt werden. Außerdem ist wichtig, wie Fehler erkannt, bewertet und bearbeitet werden. Wenn die Lösung in bestehende Betriebsprozesse eingebunden werden soll, braucht es dafür klare Schnittstellen zwischen Fachseite, IT und Betrieb. Gern besprechen wir bei ballmüller solutions in einem unverbindlichen Erstgespräch, worauf es bei einem ähnlichen Vorhaben ankommt.
