Schlagwort-Archiv: Continuous Delivery

Bürokratie bremst Unternehmen. Schlechte Prozesse noch mehr.

Bürokratie gilt in Deutschland und der EU schnell als Hauptgrund dafür, dass Unternehmen langsam werden. Fristen, Nachweise, Dokumentationspflichten, Prüfungen und Berichte kosten Zeit und Nerven. Aber oft ist nicht nur die Regulierung das Problem, sondern auch der Umstand, dass Informationen im Unternehmen unstrukturiert vorliegen und erst dann zusammengesucht werden, wenn eine Anfrage von außen kommt.

Genau hier liegt der Hebel. Unternehmen können Bürokratie nicht einfach abschaffen, aber sie können ihre internen Prozesse so aufsetzen, dass Nachweise, Dokumentationen und Prüfpfade nicht jedes Mal neu produziert werden müssen. Wer relevante Informationen laufend sauber erfasst, spart im Ernstfall Zeit, reduziert Fehler und wird gegenüber Behörden, Prüfern und Partnern deutlich auskunftsfähiger.

Warum Bürokratie so belastend wirkt

Wer ein Startup gründet oder eine GmbH führt, kommt um Dokumentation nicht herum. Neben der laufenden Buchhaltung und der Aufbewahrung von Rechnungen, Verträgen und Geschäftsunterlagen müssen Geschäftsführer je nach Unternehmensgröße und Branche zahlreiche weitere Nachweise führen. Dazu zählen Arbeitszeiten, Datenschutz- und IT-Sicherheitsmaßnahmen, Gesellschafterbeschlüsse, steuerliche Dokumentationen, Qualitätsmanagement, Compliance-Vorgaben oder Nachhaltigkeitsberichte.

Hinzu kommen Meldungen an Behörden, Sozialversicherungsträger oder Berufsgenossenschaften sowie Nachweispflichten rund um externe Dienstleister, etwa im Bereich der Künstlersozialkasse. Die meisten dieser Anforderungen entstanden aus nachvollziehbaren Gründen. In der Praxis führen sie jedoch dazu, dass Unternehmen einen erheblichen Teil ihrer Informationen nicht für das Tagesgeschäft erfassen, sondern vor allem, um gesetzlichen, steuerlichen oder regulatorischen Vorgaben gerecht zu werden.

Was Behörden und Regulatoren in der Praxis wirklich sehen wollen

Die Anforderungen wirken oft abstrakt, bis man sie in einzelne Fragen zerlegt. Dann wird schnell klar, dass Behörden und Prüfstellen in vielen Fällen nicht nach großen Strategien fragen, sondern nach belastbaren, konkreten Nachweisen. Wer war wann beschäftigt? Welche Leistung wurde von wem erbracht? Welche Verträge galten in welchem Zeitraum? Wo liegt die Einwilligung? Wann wurde eine Maßnahme beschlossen, umgesetzt und dokumentiert?

Im Alltag entsteht daraus ein erstaunlich breites Pflichtenheft. Das Finanzamt interessiert sich für ordnungsgemäße Belege, Aufbewahrungsfristen und konsistente Buchungen. Die Rentenversicherung will Beschäftigungsverhältnisse, Zeiträume und Abgrenzungen nachvollziehen können. Die Künstlersozialkasse schaut auf Honorare, Auftragnehmer und die Frage, welche Leistungen tatsächlich eingekauft wurden. Datenschutzaufsichten wollen sehen, dass Prozesse, Verantwortlichkeiten und technische Maßnahmen nicht nur behauptet, sondern dokumentiert sind. Im Lieferkettenumfeld geht es zusätzlich um Selbstauskünfte, Risikoanalysen, Bewertungen, Maßnahmen und Berichtsfähigkeit.

Das klingt nach sehr unterschiedlichen Welten, folgt aber fast immer derselben Logik: Externe Stellen wollen aus verstreuten Unternehmensaktivitäten eine nachvollziehbare Kette von Informationen lesen können. Genau deshalb wird Dokumentation so schnell zum Engpass. Nicht weil jede einzelne Anforderung unlösbar wäre, sondern weil dieselbe Organisation parallel für Steuer, Personal, Datenschutz, Lieferanten und Governance auskunftsfähig bleiben muss.

Das eigentliche Problem ist oft fehlende Systematik

Die eigentliche Belastung entsteht selten durch eine einzelne Pflicht. Problematisch wird die Summe vieler kleiner Nachweise, die in E-Mails, Excel-Dateien, PDFs, Kalendern oder in den Köpfen einzelner Mitarbeitender liegen. Sobald eine Prüfung ansteht, beginnt hektisches Zusammensuchen. Dann wird aus Verwaltungsaufwand schnell ein operatives Problem.

Viele Unternehmen dokumentieren deshalb nicht unbedingt zu wenig, sondern zu unsystematisch. Informationen existieren oft bereits, aber nicht in einer Form, die sich schnell prüfen, exportieren oder nachvollziehen lässt. Dadurch wird jede Rückfrage von außen zum Einzelfall. Wer Bürokratie nur als äußeren Zwang betrachtet, übersieht einen wichtigen Punkt: Ein Teil des Schmerzes ist hausgemacht.

Wenn die Prüfung kommt, zählt der Nachweis

Dokumentationspflichten wirken abstrakt, bis plötzlich eine konkrete Anfrage auf dem Tisch liegt. Dann geht es nicht mehr um politische Debatten über Regulierung, sondern um eine einfache operative Frage: Können die geforderten Informationen vollständig, konsistent und nachvollziehbar vorgelegt werden?

Ein typisches Beispiel ist die Prüfung im Umfeld der Künstlersozialkasse oder durch die Rentenversicherung. Dann müssen Zeiträume, Verträge, Tätigkeiten, Abrechnungen oder Beschäftigungsdaten sauber rekonstruiert werden. Wer diese Informationen erst in diesem Moment zusammensucht, arbeitet unter Druck und erhöht das Risiko von Lücken, Widersprüchen und unnötigen Rückfragen.

Kleine Werkzeuge schlagen hektische Nacharbeit

Genau an diesem Punkt zeigt sich der Wert kleiner, pragmatischer Werkzeuge. Statt Arbeitszeiten, Vertragszeiträume, Urlaubstage und Feiertage mühsam händisch nachzuhalten, lassen sich aus strukturiert gepflegten Daten nachvollziehbare CSV-Nachweise und prüfbare Übersichten erzeugen. Das ersetzt keine vollständige rechtliche oder steuerliche Prüfung, ist aber ein sinnvoller operativer Schritt, um Anforderungen besser zu beherrschen.

Daten liegen konsistent vor, Zeiträume sind sauber abgegrenzt, und die eigene Auskunftsfähigkeit steigt deutlich. Wer Dokumentation nicht erst im Ernstfall zusammensucht, sondern systematisch vorbereitet, reduziert Stress, Fehler und unnötige Diskussionen mit prüfenden Stellen. Bürokratie verschwindet dadurch nicht, aber sie wird beherrschbar.

Auch im Lieferkettenmanagement entscheidet die Qualität der Dokumentation

Das gleiche Muster zeigt sich beim Lieferkettengesetz und ähnlichen Regelwerken. Unternehmen müssen Informationen von Lieferanten einholen, Risiken zu Menschenrechten, Umwelt und Arbeitsbedingungen dokumentieren, Bewertungen nachvollziehbar festhalten und Ergebnisse für weitere Prüfungen oder Berichte nutzbar machen.

Ohne geeignete Werkzeuge landen diese Informationen in Excel-Dateien, PDFs, E-Mails und manuellen Listen. Mit einer strukturierten Lösung lassen sich Angaben zentral, einheitlich und risikobasiert erfassen. Das reduziert Verwaltungsaufwand und verbessert gleichzeitig Transparenz und Auskunftsfähigkeit.

Das von Kehrwasser entwickelte Tool unterstützt Unternehmen dabei, relevante Informationen von Lieferanten strukturiert zu erfassen und die Ergebnisse für weitere Prüfungen und Berichte nutzbar zu machen. Statt Daten manuell zusammenzutragen, werden die Angaben zentral, einheitlich und nachvollziehbar dokumentiert. So hilft das Tool, Anforderungen aus dem Lieferkettengesetz und ähnlichen Regelwerken effizienter, transparenter und mit weniger Verwaltungsaufwand umzusetzen.

Schaffen wir damit ungewollt einen Digital Twin des Unternehmens?

Man kann diese Entwicklung auch anders lesen. Vielleicht bauen Unternehmen unter regulatorischem Druck gerade schrittweise etwas auf, das einem Digital Twin erstaunlich nahekommt. Kein futuristisches 3D-Modell, sondern ein belastbares digitales Abbild der operativen Realität: Wer arbeitet woran, welche Verträge gelten, welche Lieferanten existieren, welche Risiken wurden bewertet, welche Maßnahmen beschlossen und welche Nachweise liegen vor.

Ein solcher Digital Twin entsteht nicht durch ein einziges Großprojekt, sondern durch viele kleine, sauber strukturierte Datenpunkte. Jede Zeiterfassung, jede Lieferantenauskunft, jede dokumentierte Freigabe und jeder nachvollziehbare Prozessschritt macht das Unternehmen maschinenlesbarer. Was zunächst wie reine Bürokratie aussieht, kann sich damit als Vorstufe zu etwas Produktiverem entpuppen: einer Organisation, die ihre eigene Realität digital so gut verstanden hat, dass sie schneller auswerten, steuern und automatisieren kann.

Die provokante Frage lautet deshalb nicht nur, wie viel Bürokratie zu viel ist. Vielleicht sind wir gerade unfreiwillig dabei, die Datengrundlage für bessere Unternehmenssteuerung zu schaffen. Wenn das stimmt, dann ist Dokumentation nicht nur Last, sondern auch Rohmaterial.

Bürokratie wird erst dann teuer, wenn Prozesse schwach sind

Regulatorische Anforderungen kosten immer Zeit. Richtig teuer werden sie aber dann, wenn Prozesse unklar, Verantwortlichkeiten diffus und Daten unstrukturiert sind. Dann vervielfacht sich der Aufwand bei jeder Anfrage, jedem Audit und jeder Berichtspflicht.

Der Unterschied zwischen lähmender Bürokratie und kontrollierbarer Dokumentation liegt deshalb oft weniger im Gesetzestext als im internen Setup. Unternehmen, die ihre Nachweispflichten als Prozessproblem begreifen, gewinnen Spielraum zurück. Sie reagieren nicht nur auf Anforderungen, sondern schaffen sich eine belastbare Grundlage, um mit ihnen effizient umzugehen.

Ist Bürokratie auch eine bequeme Innovationsausrede?

Bürokratie ist zweifellos ein realer Standortfaktor. Sie bindet Zeit, Geld und Managementaufmerksamkeit. Trotzdem lohnt sich eine unbequeme Gegenfrage: Nutzen wir sie manchmal auch als Erklärung dafür, dass wir langsamer, vorsichtiger und weniger innovativ sind, als wir es gern wären?

Denn nicht jede verpasste Innovation scheitert an Regulierung. Viele scheitern an schlechten internen Prozessen, an unklaren Zuständigkeiten, an fehlender Priorisierung oder daran, dass digitale Werkzeuge zwar diskutiert, aber nicht konsequent eingeführt werden. Bürokratie ist dann nicht die eigentliche Ursache, sondern die glaubwürdige Begründung, mit der sich operative Trägheit nach außen gut erzählen lässt.

Gerade deshalb ist der Blick auf Dokumentation so interessant. Wer es schafft, regulatorische Anforderungen in saubere Datenmodelle, klare Workflows und wiederverwendbare Nachweise zu übersetzen, baut nicht nur Compliance auf, sondern operative Stärke. Vielleicht ist die eigentliche Innovationsfrage also nicht, wie wir Bürokratie loswerden. Vielleicht geht es darum, ob wir gut genug darin sind, aus ihr produktive Systeme zu bauen.

Fazit

Bürokratie ist real, aber sie ist nicht in jedem Fall die ganze Erklärung. Ein großer Teil der Belastung entsteht dort, wo Informationen ungeordnet, unvollständig oder nicht wiederverwendbar vorliegen. Unternehmen können Regulierung nicht abschaffen, aber sie können die eigene Dokumentation so organisieren, dass Anforderungen nicht jedes Mal neue Hektik auslösen.

Die praktische Frage lautet daher nicht nur, welche Pflichten erfüllt werden müssen. Die wichtigere Frage ist, wie Informationen so erfasst werden, dass daraus im richtigen Moment belastbare Nachweise werden. Wer das sauber löst, macht Bürokratie nicht gut, aber deutlich weniger schädlich.

Und vielleicht liegt genau darin der produktive Kern der ganzen Debatte. Wenn Unternehmen gezwungen sind, ihre Realität präziser zu dokumentieren, kann daraus mehr entstehen als bloße Pflichterfüllung: bessere Steuerung, höhere Auskunftsfähigkeit und im besten Fall ein digitales Abbild des eigenen Betriebs, das Innovation nicht verhindert, sondern vorbereitet. Dann wäre Bürokratie nicht plötzlich gut. Aber sie wäre auch nicht mehr die bequemste Antwort auf die Frage, warum wir hinter unseren Möglichkeiten zurückbleiben.

Digitale Effizienz im Ausbau der Energiewende: Wie Solar Estate seinen Vertrieb neu konstruierte

Was passiert, wenn man ein datengetriebenes Vertriebsproblem nicht mit mehr Personal, sondern mit Mathematik und Systemdenken angeht? Die Antwort gibt ein Blick auf die Arbeitsweise von Solar Estate.

Das Problem: Vertriebsprozesse, die mitwachsen sollten – aber nicht konnten

Solar Estate plant und realisiert Photovoltaikprojekte auf Mehrfamilienhäusern in Deutschland. Die Nachfrage ist hoch, das Marktumfeld komplex. Jede Immobilie unterscheidet sich in rechtlicher, technischer und wirtschaftlicher Hinsicht. Die Folge: Der Aufwand für die Analyse, Bewertung und Angebotserstellung wuchs exponentiell mit dem Projektvolumen. Trotz hoher Nachfrage geriet das Vertriebsteam an Grenzen.

Kern des Problems war eine Exceldatei mit mehreren tausend Feldern und Verknüpfungen, in der alle Aspekte eines Projekts abgebildet wurden. Diese Datei war zwar funktional, aber schwer zu warten, nicht versionierbar und für neue Mitarbeiter kaum verständlich.

Der Umbau: Von implizitem Wissen zur expliziten Struktur

Statt den Vertriebsprozess personell auszuweiten, wurde das Modell selbst zerlegt, abstrahiert und neu strukturiert. Was als Werkzeug zur Projektbewertung begonnen hatte, wurde zu einem logischen Framework weiterentwickelt:

  • Alle Eingabefelder wurden typisiert, normalisiert und mit Abhängigkeiten versehen
  • Berechnungslogiken wurden aus der Datei extrahiert und in modulare Recheneinheiten überführt
  • Der gesamte Prozess wurde als Entscheidungsbaum mit über 100 Pfaden formell abgebildet

Das Ergebnis war ein Framework, das nicht nur die Rechenarbeit übernahm, sondern auch Vertriebsszenarien, Projektkonstellationen und technische Restriktionen in ein einziges Modell integrierte.

Das Resultat: Vertriebszeit halbiert, Skalierbarkeit verdoppelt

Die neue Architektur ermöglicht heute:

  • eine standardisierte Erstbewertung innerhalb weniger Minuten
  • automatisierte Entscheidungsvorschläge für oder gegen Projekte
  • Echtzeit-Anpassung von Finanzierungsmodellen und technischem Zuschnitt
  • ein Rollenmodell, in dem juniorige Vertriebskräfte ohne tiefes Vorwissen sinnvoll arbeiten können

Im Ergebnis wurde die Zeit für eine belastbare Projektbewertung um mehr als 90% reduziert. Noch wichtiger: Das Vertriebssystem ist nun nicht nur effizienter, sondern auch robuster gegen Fehler und besser adaptierbar für neue Rahmenbedingungen.

Ein Beispiel für datengetriebenes Wachstum im Mittelstand

Solar Estate zeigt, wie sich aus einem lokalen Vertriebsproblem eine strukturierende Kraft für die Gesamtorganisation entwickeln kann. Der Umbau des Excelmodells war kein IT-Projekt im engeren Sinne, sondern eine strategische Reaktion auf ein operatives Skalierungsproblem.

Die zugrundeliegende Logik lässt sich verallgemeinern: Wer den impliziten Code seiner Arbeitsweise sichtbar macht, kann ihn automatisieren, modulieren und dauerhaft verbessern.

Ausblick: Von der Datei zum digitalen Produkt

Die Entscheidung, aus einem internen Tool ein formalisiertes Framework zu machen, war kein Selbstzweck. Es öffnet nun die Option, dieses Wissen als Produkt weiterzudenken: für Partnerunternehmen, für andere Regionen, für angrenzende Segmente der Energiewirtschaft.

Solar Estate hat mit diesem Schritt nicht nur seinen Vertrieb restrukturiert, sondern ein Fundament geschaffen, auf dem weitere digitale Werkzeuge entstehen können. Die Energiewende braucht Tempo – und Tempo entsteht dort, wo Komplexität beherrschbar wird.

Dockerimage für CI/CD mit Sloppy CLI

In CI/CD-Situationen, also in Situationen, in denen wir automatisiert gewisse Aussagen über und Aufgaben am aktuellen Entwicklungsstand einer Software vornehmen wollen, sind wir häufig auf die Kommandozeile angewiesen.

TL;DR: Das Runner-Image z.B. für GitLab ist auf DockerHub frei verfügbar dielok/sloppy-cicd. Wir werden die Dockerfile auch in Kürze bei Github veröffentlichen.

Über entsprechende Skripte, also aneinandergereihte Befehle, automatisieren wir dann den Prozess und visualisieren ihn in Form von sogenannten Build- und Deploymentpipelines.

Auch mit dem Cloud-Anbieter Sloppy muss dies natürlich irgendwie innerhalb eines Skriptes möglich sein, damit wir den Entwicklungsstand auch automatisiert veröffentlichen können. So kann die Anwendung auch letztlich von Endnutzern verwendet werden. Dies kann ein Server sein, oder ein ganzes Netzwerk aus Servern, daher sprechen wir von Umgebungen. Auf der sogenannten Produktivumgebung läuft die Anwendung für den Endverbraucher. Umgangssprachlich „Prod“.

Auch auf Umgebungen die nicht produktiv sind, müssen die aktuellen Entwicklungsstände ausgerollt werden können. Diese dienen beispielsweise den Tests der Qualitätssicherung, Demonstrationen für Stakeholder und der Beobachtung des Fortschritts durch Manager. Das soll so zuverlässig, einfach und schnell wie möglich ablaufen: Also automatisiert.

Das geht mit Sloppy im Handumdrehen. Super einfach ist ein neues Projekt (Umgebung) angelegt, Services, Apps in Form von Docker-Containern definiert.Nicht nur in dem UI. dem Portal von Sloppy. Sloppy bietet eine gut entwickelte CLI-Anwendung, mit der Apps, Services und Projekte verwaltet und gesteuert werden können.

Und so können auch die Deployment-Schritte in der Pipeline mit Sloppys CLI-Tool automatisiert werden. Das Skript für diesen Schritt ist dann gerade einmal zwei Zeilen lang:

script:
- export SLOPPY_APITOKEN="$SLOPPY_APITOKEN"
- sloppy change --image docker/container:${CI_COMMIT_REF_NAME} umgebung/service/app

(Auszug aus der CI/CD-Konfiguration für Gitlab)

Zu verbessern wäre, dass dieser Pipelineschritt noch wartet, bis das Deployment erfolgreich abgeschlossen wurde und der Service gestartet werden konnte.

Doch wie bekommt die Pipeline die Sloppy CLI, sodass der Befehl sloppy überhaupt zur Verfügung steht? Entweder lädt und installiert die Pipeline die Binaries bei jeder Ausführung dieses Schrittes oder die Anwendung wird bereits in den zugrundeliegendeliegenden Container installiert und steht immer gleich zur Verfügung.

Für unser Zwecke habe ich den Container mal erstellt und auf Docker Hub verfügbar gemacht: dielok/sloppy-cicd. Viele Erfolg.

Wirtschaftlicher Nutzen von CI/CD

Produktinnovation ist in einer digitalisierten Welt der Schlüssel zum Erfolg. Um sich vom Wettbewerb abzuheben, sollen Innovationen so rasch wie möglich und voll funktionsfähig an den Markt gebracht werden. Doch konventionelle Entwicklungsmethoden sind meist schwerfällig und bremsen die Time-to-Market. Um die Zeitspanne zwischen Entwicklung und Marktveröffentlichung zu verkürzen, sind in der Vergangenheit effektive Ansätze entwickelt worden.

Bei konventionellen Vorgehensweisen, vergehen teilweise Monate bis es zu einem Release kommt. Zunächst müssen alle Fehler behoben und Funktionen entwickelt bzw. erweitert werden. Erst danach folgt ein großes Update. Dabei werden beinahe alle Änderungen und Anpassungen manuell durchgeführt und der Prozess wird dementsprechend anfälliger für Fehler. Der gesamte Prozess ist wenig flexibel sorgt oftmals für komplexe Workarounds für die Entwickler.

Eine Lösung für dieses umständliche Vorgehen muss her. Ein lohnender Ansatz soll den Entwicklungsprozess von Software vereinfachen und zugleich beschleunigen: Das CI/CD.

Unterschied zwischen Continuous Integration (CI) und Continuous Delivery (CD)

Was ist also CI/CI? CI bzw. CD steht für Continuous Integration bzw. Continuous Delivery. Continuous Integration (CI) ermöglicht eine kontinuierliche Integration von neuem Code in ein gemeinsames Repository während Continuous Delivery (CD) für die Überführung des Codes von Repository in die Produktion zuständig ist.

Durch die Anwendung von CI/CD können sowohl die Fehlerquote als auch der Release-Zyklus minimiert werden. Im ersten Schritt, der Continuous Integration, testet der Entwickler den von ihm produzierten Teil des Codes bevor er ihn in das Controle-Repository übermittelt. Danach folgt meist eine neue Quellcode-Version, welche mittels Unit-Tests auf Fehler geprüft und in Testumgebungen eingefügt wird. Hier werden auch ganzheitliche Systemtests durchgeführt. Wenn der neue Teil des Codes erfolgreich alle Tests durchlaufen hat, wird das Team automatisch benachrichtigt. Zudem werden Informationen über die Anzahl der Tests und der gefundenen Fehler gesammelt.

Continuous Delivery (CD) setzt dort an, wo Continuous Integration endet. Bevor Software in die Produktionsumgebung übermittelt wird, werden Systemtests, Unit-Tests (inklusive API-Tests und Lasttests) und Integrationstests durchgeführt. Diese Tests sind allesamt Teil von Continuous Delivery und werden automatisch durchgeführt. Über den kompletten CI/CD-Prozess hinweg, können Fehlermeldungen rasch und direkt über Feedback-Kanäle an die Entwickler weitergeleitet werden.

Nachfolgend sind die relevantesten Vorteile von CI/CD aufgelistet, die letztlich in einer Kostensenkung resultieren.

  • Kleine Schritte: Statt große Teile des Codes auf einmal zu integrieren und in späterer Folge deren Fehler umständlich zu beheben, werden bei CI/CD mehrere kleinere Teile in das Repository eingefügt. Das Continuous Testing wird dadurch erleichtert, weil nur kleinere Stücke untersucht werden müssen und mögliche Probleme somit eher gefunden werden.
  • Kürzere Release Rates: Durch das rasche Erkennen und Beheben von Fehlern, können mehrere kleinere Code-Teile in kürzeren Abständen released werden. Dies ist allerdings nur möglich, wenn in einem kontinuierlichen Prozess entwickelt und der Code in einem releasefähigen Zustand gehalten wird.
  • Ordentlicher Backlog: Wird CI/CD in den Entwicklungsprozess integriert, so verändert sich die Fehlerquote im Backlog. Da kleinere Fehler rascher gefunden werden, kann sich das Team auf kritische Probleme konzentrieren.
  • Einfache Wartung: Mithilfe von Microservices können einzelne Bereiche eines Systems heruntergefahren werden ohne das restliche System betroffen ist. Somit können Wartungsarbeiten nahezu unbemerkt stattfinden.
  • Continuous Feedback: Durch die regelmäßige Integration des Codes, entsteht eine verlässliche und kontinuierliche Feedbackschleife. In dieser befinden sich vor allem Entwickler. Deren Rückmeldung zu Pipeline Build-Fehler, Merging-Problemen, Architektur-Rückschlägen usw. ist enorm wichtig für den gesamten Prozess.

Darauf sollte geachtet werden

Den Entwicklern soll die Arbeit mit dem CI/CD-Ansatz erleichtert werden, weshalb ein einfacher Prozessaufbau essentiell ist. Je weniger sie sich mit dem eigentlichen Prozess und manuellen Aufgaben aufhalten, desto effektiver kann gearbeitet werden. Zudem sollten Entwickler bis auf wenige Ausnahmen, direkt am Master-Branch arbeiten um eine sofortige Integration und das zugehörige Testen zu ermöglichen.

Wird CI/CD in den Entwicklungsprozess von Software integriert, so müssen automatisierte Tests auf allen Ebenen durchgeführt werden. Dies schließt mitunter Unit-, Integrations- und Systemtests ein, genauso wie automatisierte Tests für Funktionalität, Benutzerfreundlichkeit, Leistung, Last, Stress und Sicherheit durchgeführt werden müssen. Erst dann kann von CI/CD ganzheitlich profitiert werden.

Als nützliche Tools erweisen sich beispielsweise Repository-Management-Systeme wie Gitlab und Bitbucket oder Services für die Build-Automatisierung wie Jenkins oder eben auch Gitlab. Beispiele für die Testautomatisierung sind das Tool Katalon Studio oder jUnit in der Javawelt. Aber die Auswahl ist praktisch unendlich.

Fazit

Continuous Integration und Continuous Deployment zerstückeln den Entwicklungsprozess in kleine Teile. Diese Teile werden in regelmäßigen Abständen in ein gemeinsames Repository integriert und nach dem Testen dem Kunden rasch zur Verfügung gestellt. Sie sind ein zentrale Teil der DevOps-Methodik. Der gesamte Entwicklungsprozess wird übersichtlicher und flexibler, dadurch werden Fehler einfacher gefunden und behoben. Um mit der Konkurrenz mitzuhalten bzw. diese sogar zu übertreffen und unnötige Fehlersuche zu vermeiden, ist die Integration von CI/CD in den Entwicklungsprozess also eine einfache, effektive aber auch mittlerweile unverzichtbare Methode.