Regulatorische Compliance ist in etwa so aufregend wie eine Wurzelbehandlung. Die gute Nachricht ist aber, dass es nicht annähernd so schmerzhaft sein muss.

Mittlerweile haben Sie höchstwahrscheinlich schon einmal was von DevOps gehört. Vielleicht stimmen Sie sogar dem Argument zu, dass DevOps dabei helfen kann, Compliance-Standards einzuhalten. Nicht nur, weil Automatisierung ein integraler Bestandteil von DevOps ist, sondern weil es gleichzeitig ein guter Weg ist, um sicherzustellen, dass Entwicklungs- und Deployment-Pratiken verlässlich, wiederholbar und nachvollziehbar sind. Nicht zu vergessen, dass Automatisierung den gesamten Prozess beschleunigt, wodurch Sie genauso schnell arbeiten können wie Ihre Mitbewerber (oder sogar schneller). Außerdem legt DevOps den Fokus auf eine transparente Unternehmenskultur, was sich besonders bei Audits auszahlt.

So etwas lässt sich nicht über Nacht erreichen, aber in vier – nicht unbedingt einfachen, aber absolut machbaren – Schritten können auch Sie es schaffen.

Schritt 1: Identifizieren und dokumentieren Sie alle Richtlinien, von denen Ihr Team betroffen ist

Dieser Schritt ist so selbstverständlich, dass er leicht zu übersehen ist. Sorgen Sie dafür, dass Ihre Teammitglieder und Stakeholder genau wissen, welche Vorschriften Sie einhalten müssen, wie Sie sie einhalten werden und wo alle relevanten Informationen nachgeschlagen werden können (für den unwahrscheinlichen Fall, dass sie nicht über ein fotografisches Gedächtnis verfügen). Um die „Dokumentenversionshölle“ (übrigens auch ein Fachbegriff) zu vermeiden, sollten Sie alles auf Wiki-Seiten dokumentieren und Links zu diesen Seiten auf allen Teamportalen, Dashboards, etc. platzieren. Besonders praktisch ist, wenn Sie bestimmte Personen als „Beobachter“ eintragen, damit diese im Falle eines Updates direkt benachrichtigt werden.

Schritt 2: Erstellen Sie Ihr Automations-Backlog

Sobald alle Beteiligten verstanden haben, welche Dinge wichtig sind und weshalb, können Sie die Grundlage für Automatisierung kreiren, die Ihnen die Compliance erleichtern wird. Beginnen Sie mit repetitiven Aufgaben, die sich gut automatisieren lassen.

Hierzu gehören typischerweise:

  • Pull-Requests – Obwohl Pullanfragen stets einer sorgfältigen Überprüfung durch einen Mitarbeiter unterliegen sollten, können Sie die mühsamen Bestandteile der Anfragen automatisieren. Zum Beispiel könnten Sie dafür sorgen, dass immer mindestens zwei Prüfer die Pullanfrage bestätigen müssen und dass es keine fehlgeschlagenen Builds oder Testläufe geben darf, die im Zusammenhang mit dem jeweiligen Commit stehen.
  • Codeabdeckung – Jedes gute CI/CD-Tool kann so konfiguriert werden, dass Builds als fehlgeschlagen markiert werden, wenn die Testabdeckung unter einem bestimmten Schwellenwert liegt.
  • Erstellen Sie Verknüpfungen – Stellen Sie sicher, dass Änderungen am Code, Code-Reviews, Build-Ergebnisse, Deploys und Issues alle miteinander verknüpft sind. (Damit meine ich, dass Sie mit nur einem Mausklick von einer Sache zur anderen springen können). Das macht die alltägliche Arbeit und auch Audits wesentlich einfacher.
  • Berechtigungen – Sicherheit…ein schwieriges Thema. Aber Sie können Ihren Repository-Manager so konfigurieren, dass nur bestimmte Leute Änderungen an bestimmten Repos und/oder Branches vornehmen können – außerdem können Sie einstellen, dass niemand Änderungen direkt in der Produktion vornehmen kann.
    • Hinweis: Alle Repos und Branches sollten nur mit Lesezugriff zugänglich sein. Der Grund: DevOps. Und weil diese Art von Transparenz einfach praktischer ist.
  • Audit-Trails – Schützen Sie sowohl Ihren Verstand als auch den Regenwald, indem Sie Build-, Test- und Deployment-Resultate automatisch protokollieren lassen. Schließen Sie dann den Kreis, indem Sie Commits, Reviews und Issues wie oben erwähnt miteinander verknüpfen.
  • Failover und Wiederherstellung – Infolge eines fehlgeschlagenen Deployments automatisch einen Rollback durchführen zu lassen, ist wesentlich sicherer als ihn manuell durchzuführen. Außerdem ist es nachvollziehbarer und schneller, was Ihnen wiederum dabei helfen wird, SLAs (Service Level Agreements) einzuhalten.

Sorgen Sie dafür, dass eine Handvoll dieser Tipps in jede Iteration eingebaut wird. Und reflektieren Sie regelmäßig: „Sind unsere Zugriffskontrollen für Branches effektiv oder übertrieben?“ „Hat unsere Code-Abdeckung die Auditoren zufrieden gestellt?“. Der Trick ist es, Ihre Obligationen zu erfüllen, ohne sich dabei selbst im Weg zu stehen. Auch hier müssen Sie hin und wieder versuchen, das berühmte Kamel durchs Nadelöhr zu treiben.

Schritt 3: Sorgen Sie für mehr Kultur

Um ehrlich zu sein, sollte dieser Schritt parallel zu den Schritten 1 und 2 stattfinden, denn in der Welt von DevOps ist Unternehmenskultur immer eine Priorität. (Aber „immer“ würde unsere schön durchnummerierte Liste durcheinander bringen).

Wenn Ihr Team unter schlechter Kommunikation, ständigen Schuldzuweisungen und/oder unklaren Rollen und Verantwortungen leidet, wird vereinzelte Automatisierung allein nicht ausreichen. Organisieren Sie ein Meeting mit Ihrem Team, identifizieren Sie die Probleme und finden Sie gemeinsam Wege, um diese zu lösen. Klingt zwar nicht gerade einfach, aber keine Angst: Das Atlassian Team Playbook kann Ihnen weiterhelfen.

Teams, die genau wissen wo das Problem liegt, können sich direkt die Sammlung von Plays ansehen und nach Problemen filtern. Leiden Sie unter „Kommunikationsabbrüchen“? Oder vielleicht am „Mangel-an-Leadership-Syndrom“? Das Team Playbook wird Ihnen eine Reihe von hilfreichen Techniken vorschlagen, mit denen Sie Ihr Team wieder auf die Beine helfen können.

Vergessen Sie nicht, dass die Plays keine zusätzliche Arbeit darstellen. Sie sind lediglich unterschiedliche (und effektive) Wege, um die Arbeit anzugehen, die Sie bereits erledigen müssen.

In vielen Fällen kennen dysfunktionale Teams die Gründe für Ihre Probleme nicht. In solchen Situationen kommt der Team Health Monitor zum Einsatz. So hat Ihr Team die Chance, sich mit leistungsstarken Teams und deren Attributen zu vergleichen und herauszufinden, was verbessert werden kann. Sie erhalten zusätzlich Vorschläge für Plays, die Ihnen bei der Lösung Ihrer Probleme helfen können.

Praktischerweise enthält das Team Playbook einen “Spielplan“, speziell für den Aufbau einer DevOps-Unternehmenskultur – darunter befinden sich beliebte Plays wie “Pre-mortem” oder “Rules of Engagement“. Spielpläne sind eine nützliche Abkürzung, aber Sie sollten trotzdem den Team Health Monitor nutzen, um die Performance Ihres Teams zu überprüfen. Das meine ich ernst.

Vergessen Sie außerdem nicht, Ihre Siege zu feiern! Selbst ein kurzes High Five bei einem Standup für Dinge, die trivial erscheinen (die Codeabdeckung ist um 20 Prozent gestiegen – Super!“) wirkt Wunder, was die Aufrechterhaltung der Motivation und Teammoral angeht.

Schritt 4: Verbessern Sie kontinuierlich Ihren Entwicklungs-Workflow

Nun da Sie sich auf dem Weg in Richtung guter Teamgesundheit befinden, ist es Zeit, an Ihrem Dev-Workflow zu arbeiten. Verschaffen Sie sich einen Überblick und suchen Sie nach leicht erzielbaren Erfolgen, mit denen Sie anfangen können. Eine häufige DevOps-Praktik ist beispielsweise die Einführung eines Feature-Branching-Workflows mithilfe von Git oder Mercurial.

All die unordentliche Arbeit in einem isolierten Feature-Branch aufzubewahren, bis sie sich als produktionsreif herausgestellt hat, wird mit fast absoluter Sicherheit dafür sorgen, dass Sie keinen „Oh Mist!“-Moment erleben werden – Beispielsweise, wenn Sie feststellen, dass Sie eine Deobfuscation aller Kundendaten in Ihren Produktionslogs durchgeführt haben. Außerdem können Sie die oben erwähnten automatisierten Berechtigungen nutzen, um den Fluss von Veränderungen von Branch zu Branch und Umgebung zu Umgebung besser zu kontrollieren.

Überprüfen Sie, ob Sie über die nötige Code-Abdeckung verfügen und ob sie dort vorhanden ist, wo sie benötigt wird. „Spezifikation nach Beispiel“ funktioniert hier besonders gut. Arbeiten Sie mit Ihrem Compliance Lead zusammen, um zu verstehen wie ein Compliance-Verstoß aussehen würde („wie würde sich der Verstoß in den Logs manifestieren?“). Schreiben Sie anschließend Tests, die den Build fehlschlagen lassen, sobald diese Bedingungen erkannt werden.

Wenn Sie über umfangreiche Auto-Tests verfügen, haben Sie die Möglichkeit, Builds automatisch in die nächsthöhere Umgebung weiterleiten zu lassen, je nachdem unter welchen Regulationen Sie arbeiten. Automatisierte Deployments sind Ihr Freund. Sie sind verlässlich und nachvollziehbar – Traits-Auditoren lieben das.

Welcher Overhead würde sich mithilfe von Automatisierung noch eliminieren lassen? Wenn Sie beispielsweise JIRA Software verwenden, um Ihre Arbeit zu protokollieren, könnten Sie es mit Bitbucket integrieren, um von den „Smart Commits“ zu profitieren. Diese leiten relevante Issues automatisch in den nächsten Workflow-Schritt weiter und Sie sparen sich dadurch den Weg zurück zum Agile-Board. Oder Sie können Ihren Repository-Manager mit Ihrem CI/CD-Tool integrieren, um automatisch einen Build auszulösen, wenn eine Pullanfrage erstellt wird.

Es ist ein langer Weg und kein Schalter, der sich umlegen lässt

Tut Ihnen schon der Kopf weh? Machen Sie sich keinen Stress. Die einzelnen Punkte nach und nach abzuarbeiten und zu iterieren macht den Übergang hinsichtlich der Logistik wesentlich machbarer. Erinnern Sie sich noch an Maria? Kontinuierliche Verbesserung ist genau das, was ihrem Team wieder auf die Beine geholfen hat. Ich würde lügen, wenn ich Ihnen jetzt erzählen würde, dass es einfach für sie war. Aber ihr Team hat es geschafft und jetzt läuft bei ihr alles rund.

Was den technischen Aspekt angeht, sollten Sie es in Betracht ziehen, zu einem  Git-Repository-Management-Tool wie beispielsweise Bitbucket Server oder Bitbucket Data Center zu wechseln. Teams, die in regulierten Branches arbeiten, profitieren von Bitbuckets Workflow-Verbesserungen (wie die Notwendigkeit, dass „grüne Builds“ oder mehrere bestätigte Code-Reviews vorliegen müssen), Adminkontrolle auf Projektebene und granulare Berechtigungsoptionen.

Wenn Sie bereits Bitbucket Server/Data Center nutzen und Ihre CI-Praktik ausbauen möchten, sollten Sie einen Blick auf Bamboo werfen. Es verfügt über ein Set von Compliance-relevanten Features wie beispielsweise Projektorganisation, Berechtigungen und eine tiefgreifende Integration von Bitbucket Server und JIRA Software.

Weitere Fragen? OIO Braintime ist Atlassian Enterprise Partner

OIO Braintime ist Atlassian Platinum Solution Partner (Enterprise) und hat das langjährige Knowhow, um gerade auch große Unternehmen in allen Facetten des Einsatzes von Atlassian-Tools zu unterstützen. Wir beraten und unterstützen Sie zusätzlich bei folgenden Anforderungen:

  • Auswahlberatung und Einführungsstrategie
  • Rollendefinition, Aus- und Weiterbildungs-Beratung sowie Schulung und Coaching in der Nutzung mit vielen Usern
  • Integration Ihrer Systeme mit Ihrem System-Umfeld
  • Beratung in Fragen des Lizenzmanagements und lokaler Ansprechpartner rund um alle ALLE Atlassian Produkte
  • Enterprise Betriebskonzepte wie Konsolidierung von Systemen sowie Skalierung und Ausfallsicherheit und Performance- Tuning Ihrer Atlassian Systeme

Können wir Ihnen helfen? Dann kontaktieren Sie uns noch heute.