Die Eidgenössische Zollverwaltung (EZV) hat gemeinsam mit dem BIT die Anwendung E-Begleitdokument in gerade einmal einem halben Jahr realisiert. Erste Speditionen übermitteln die Begleitdokumente für ihre Fracht bereits elektronisch an die Zollverwaltung, anstatt diese in Papierform an der Grenze vorzuweisen. E-Begleitdokument ist die erste Anwendung, die das BIT mit der neuen Arbeitsweise DevOps und mithilfe von Microservices entwickelt hat.
E-Begleitdokument: Startschuss für DevOps im BIT
Bisher mussten Chauffeure die für den Import, Export oder Transit ihrer Fracht notwendigen Dokumente an der Grenze in Papierform vorweisen. Das ist dank der erfolgreichen Produktivsetzung der Anwendung E-Begleitdokument seit Anfang Januar nicht mehr nötig. Bereits heute übermitteln erste Pilotkunden ihre Dokumente elektronisch an die Zollverwaltung – noch bevor die Fracht das Lager verlässt. Die Anwendung E-Begleitdokument ist ein erstes konkretes Ergebnis aus dem Transformationsprogramm DaziT, in dem die Eidgenössische Zollverwaltung (EZV) ihre Prozesse bis 2026 komplett digitalisiert (mehr dazu auf www.dazit.admin.ch).
DevOps – die Grundprinzipien im Überblick
Der Begriff DevOps beschreibt ein Vorgehen in der Informatik, bei dem die beiden Bereiche Development (Entwicklung) und Operations (Betrieb) enger zusammenarbeiten. Es handelt sich bei DevOps am ehesten um eine Arbeits- und Denkweise: Die wichtigsten fünf Grundprinzipien von DevOps sind in der Abkürzung CALMS zusammengefasst:
Culture: Die funktionsübergreifende Zusammenarbeit von Entwicklern und Betrieb ist ein grundlegendes Prinzip für DevOps. Das setzt eine Unternehmens- und Zusammenarbeitskultur voraus, die von gegenseitigem Vertrauen geprägt ist und den stetigen Austausch sowie die Lernbereitschaft fördert.
Automatisierung: Die Automatisierung von Testing und Deployment ist ein weiteres Element von DevOps. Das heisst, dass z. B. bereits die Entwickler Testfälle codieren, die dann automatisch durchlaufen. Neu geschriebener Code wird so automatisch zu einem frühen Zeitpunkt getestet und kann dank einem automatisierten Deployment per Knopfdruck auf das produktive System eingespielt werden.
Lean: Der Begriff Lean beinhaltet, dass man sich aufs Wesentliche konzentriert, den Kunden rasch erste Funktionalitäten liefert und diese danach in kurzen Iterationen stetig verbessert. Die kontinuierliche Verbesserung von Prozessen hat bei DevOps einen hohen Stellenwert. In sogenannten Retrospektiven blickt das DevOps-Team gemeinsam zurück und analysiert was gut lief und was man verbessern kann.
Measurement: Einheitliche Bewertungskriterien und stetiges Messen der Leistung des Teams sowie der Qualität des Codes sind wichtig. Wie lange dauert es von der Entwicklung bis zum Deployment? Stehen die vom Kunden gewünschten Funktionalitäten in der definierten Qualität bereit? Wie oft treten wiederkehrende Fehler im Code auf? Auch hier läuft dank verschiedener Tools vieles automatisiert ab. Das BIT setzt z. B. eine Art Ampel ein, die direkt am Server angeschlossen ist. Läuft ein automatisierter Test von frisch programmiertem Code, zeigt die Ampel in Echtzeit an, ob der Test erfolgreich war oder nicht.
Sharing: Teilen von Wissen, Erfolgen und Verantwortung ist ein weiterer Grundpfeiler von DevOps – denn es rücken Bereiche der IT näher zusammen, die bisher sehr unterschiedlich gearbeitet haben.
Neue Arbeitsformen beschleunigen Inbetriebsetzung
«Bemerkenswert am Projekt E-Begleitdokument ist der kurze Zeitraum der Umsetzung – vom Start des Vorhabens, über die für E-Begleitdokument adaptierte und erweiterte Cloud-Plattform, die Realisierung bis hin zur Produktivsetzung sind gerade einmal sechs Monate vergangen», sagt Carsten Plum, Leiter Program Alignment & Coaching im neu geschaffenen Bereich komplexe Vorhaben (KVO) des BIT. «Das ist gelungen, weil wir konsequent auf neue Arbeitsformen gesetzt haben. Die Projektbeteiligten haben zum ersten Mal im BIT nach dem Ansatz DevOps gearbeitet.»
Entwicklung und Betrieb rücken enger zusammen
DevOps ist ein Kofferwort aus den Begriffen Development (Softwareentwicklung) und IT-Operations (IT-Betrieb). Die Idee dahinter: Gemeinsame Anreize, Prozesse und Werkzeuge sollen eine effektivere Zusammenarbeit zwischen Entwicklern und Betriebsspezialisten ermöglichen. Ziel ist, durch ein engeres Zusammenrücken der beiden Bereiche Software schneller und zuverlässiger zu entwickeln, zu testen und den Kunden zur Verfügung zu stellen (mehr zu DevOps in der Infobox).
Das Zusammenrücken ist durchaus bildlich zu verstehen. Für das Projekt hat das BIT extra einen Raum im Gebäude Titanic II zur Verfügung gestellt: Hier trifft sich das DevOps-Team, das im Scrum-Modus arbeitet. Es besteht aus einem Product Owner, Scrum-Master, Betriebsspezialisten, Cloud-Engineers, Testmanagern, Entwicklern, Lösungsarchitekten und weiteren Fachspezialisten. Das Team plant und reviewt hier aber nicht nur die zweiwöchigen Sprints: Der gemeinsame Raum dient auch als eine Art Labor, um neue Zusammenarbeitsformen zu erlernen.
Moderne Cloud-Technologie
Als Grundlage dient dem DevOps-Team eine in der BIT-Cloud Atlantica aufgebaute «Cloud Foundry»-basierte Plattform (Platform as a Service), auf der die Anwendung E-Begleitdokument entwickelt und betrieben wird. «Die Entwicklungs-, Abnahme-, Test- und Produktivumgebungen existieren auf der Plattform nur noch virtuell», sagt Product Owner Guido von Matt. «Das ermöglicht ein automatisiertes Deployment von Code. Wir können Software auf dieser Plattform unmittelbar von einer Umgebung auf die nächste deployen.»
Datenbank in zwei Minuten bereit
Teil der Plattform sind auch sogenannte Shared Services. Das können z. B. Datenbanken sein. «Bisher mussten wir mindestens eine Woche warten, bis eine bestellte Datenbank bereitstand», sagt Guido von Matt. «Dank der Shared Services dauert es noch zwei Minuten.»
Der Aufbau der Plattform und solcher Shared Services ist für das BIT neu und eine der Herausforderungen im Projekt. Ebenso anspruchsvoll ist die Tatsache, dass die Arbeit mit den neuen Werkzeugen eine andere Art der Zusammenarbeit erfordert. Ein Beispiel dafür ist das Testing: «Tests erfolgen nicht erst, wenn die Anwendung bereits fertig entwickelt ist, wie in Projekten mit einem linearen Vorgehensmodell», erklärt Java-Entwickler Oliver Santschi. «Stattdessen schreiben wir bereits im ersten Sprint automatisierte Tests für die entwickelten Funktionalitäten.» Dadurch verschieben sich bei DevOps Aufgaben, die in linearen Projekten erst zu einem späteren Zeitpunkt anstehen, in frühere Projektphasen. Bestimmte Arbeitsschritte wandern auf der Zeitachse von rechts nach links – man bezeichnet dieses Phänomen auch als «shift left».
Mit Microservices entwickelt
Eng mit der DevOps-Philosophie verbunden ist die Applikationsentwicklung, die auf einer Microservice-Architektur basiert. Ein Microservice ist ein Softwarebaustein, der genau eine Funktion erfüllt. «Für die Anwendung E-Begleitdokument hat das BIT erstmals Microservices entwickelt und erfolgreich eingesetzt», sagt BIT-Programmleiter Alexandre Proca. So ist z. B. ein Microservice dafür zuständig, die elektronischen Dokumente in die Anwendung hochzuladen, ein anderer hat ausschliesslich die Funktion, die Benutzeroberfläche der Anwendung darzustellen. Die Applikation E-Begleitdokument setzt sich aus verschiedenen solcher Microservices zusammen: Sie sind so aufgebaut, dass sie sich praktisch beliebig im Steckkastenprinzip kombinieren lassen. Microservices sind zusätzlich in Container verpackt, welche die Performance des Betriebssystems besser ausnutzen, das Deployment vereinfachen und Abhängigkeiten reduzieren.
Der Vorteil: Wenn sich an einem Microservice etwas ändert, dann muss man nicht die ganze Anwendung anpassen. Es genügt, den entsprechenden Baustein zu modifizieren. Das geht bei einem Microservice schneller und einfacher als bei komplizierter Software, die eine ganze Reihe von Funktionen abdeckt. Wenn die Zollverwaltung z. B. eine Änderung an der Uploadfunktion wünscht, dann muss nur dieser Microservice angepasst werden. Dank dem automatischen Deployment lässt sich dieser blitzschnell auf das produktive System einspielen. Ein Wartungsfenster oder Systemunterbruch ist in der Regel nicht nötig. «Wir haben bei der Anwendung E-Begleitdokument an einem Tag bereits mehrere Deployments eines Microservices ohne Systemunterbruch vorgenommen», sagt Guido von Matt. Ein weiterer positiver Effekt ist das flexible Anpassen der Leistung: Wenn mehr Rechenleistung benötigt wird, muss man keinen neuen Server bestellen. Einzelne Microservices lassen sich innerhalb von Sekunden skalieren.
Jeder Microservice wird vom Team, das ihn gebaut hat, auch betrieben und weiterentwickelt. Diese Teams bestehen wiederum aus Spezialisten verschiedener Fachbereiche, die den Microservice über den ganzen Lebenszyklus verantworten – also auch dann, wenn er auf produktiven Systemen im Einsatz ist.
Go-Live geglückt
Dass DevOps und der Einsatz von Microservices im BIT funktioniert, hat der erfolgreiche Go-Live der Anwendung E-Begleitdokument Anfang Januar gezeigt. «Die Anwendung läuft sehr stabil. Die bereits angepassten Verbesserungen konnten während dem Betrieb, ohne dass die Kunden davon etwas mitbekommen haben, eingespielt werden», sagt Kuno Zimmermann, Product Owner bei der EZV. Die Pilotkunden laden ihre Dokumente täglich hoch, den Benutzerkreis will die EZV in nächster Zeit kontinuierlich ausweiten. E-Begleitdokument ist aber noch nicht fertig entwickelt: Funktionale Erweiterungen wird das DevOps-Team auch in Zukunft dank gemeinsamer Werkzeuge, Prozesse und geteiltem Wissen viel schneller umsetzen, als bei einer Fachanwendung die nach klassischem Muster entwickelt und betrieben wird.
Microservice-Architektur kurz erklärt
Bei monolithischen Software-Architekturen sind verschiedene Funktionalitäten in einer Anwendung integriert. Einer anderen Logik folgt die Microservice-Architektur. Eine Anwendung besteht hier aus mehreren Microservices. Das sind kleine Softwarebausteine, die genau eine Funktionalität umfassen, eigenständig funktionieren und über sprachunabhängige Schnittstellen mit anderen Microservices kommunizieren. Die Microservice-Architektur vereinfacht die Wartung und Aktualisierung einer Anwendung. Liegt ein Problem bei einem Microservice vor, ist davon nicht die ganze Anwendung betroffen. Ein einzelner Microservice lässt sich ohne Unterbruch des Systems anpassen, testen und auf das produktive System einspielen. Ein weiterer Vorteil ist die geringere Komplexität einzelner Microservices. Dadurch bleiben sie übersichtlich und können leichter weiterentwickelt werden.
Autor: Daniel Wunderli
Abonnieren Sie den «Eisbrecher» kostenlos
Erhalten Sie alle drei Monate Neuigkeiten zu IT-Themen in der Bundesverwaltung und aktuellen Projekten des BIT.