Massig Material Effektiver entwickeln€¦ · Der perfekte Microservice 106 Enterprise IT Warum Microservices in großen Unternehmen mehr als nur Software sind 114 Java-Microframeworks

Container:

Docker & Co. revolutionieren die IT-LandschaftGrundlagen, Ökosystem und Orchestrierung

DevOps:

IT-Kulturwandel eint Entwickler und AdministratorenCompliance, Sicherheit, APM und Change Management

Continuous Delivery:

Basiswissen, Einführung, Tools und ManagementChef, Puppet und Ansible im Dienst der Continuous Integration

Microservices:

Architekturparadigma stützt Continuous Delivery und DevOps

Effektiver entwickeln

Auf der Heft-DVD

Massig Material für Entwickler

Software: Ubuntu, Eclipse, Docker,Kubernetes, Ansible, Chef,Puppet, Jenkins, Vagrant,Mesos, VirtualBox etc.

Multimedia:4 Continuous-Lifecycle-

Videos zu Continuous Delivery, DevOps und Branch-

Modellen; mehrere Episoden desSoftwareArchitek-TOUR-PodcastsLiteratur: Microservices (Broschüre), Continuous Delivery (Buch auszüge), iX Developer „Bessere Software“ (Sonderheft)

2/2016

Mehr als drei Buzzwords:

Continuous Delivery, DevOps und Containerpr

äsen

tiert

von:

www.he

ise-d

evelo

per.d

e

Prozesse – Tools – Erfahrungen

Mannheim, Congress Center Rosengarten,14.-16. November 2016

www.continuouslifecycle.de

Veranstalter:

CONTINUOUS WHAT? CONTINUOUS EVERYTHING!

D ie drei Auflagen der Continuous Lifecycle haben es deutlich gezeigt: Continuous Delivery, DevOps und Containertechniken sind in der Praxis angekom-

men – nicht nur in Web-2.0- und Cloud-Firmen, sondern auch in Unternehmen, die klassische Unternehmens- oder Embedded-Anwendungen herstellen.

Wie aber setzt man diese Konzepte und die damit verbun-denen Techniken sinnvoll im eigenen Projekt oder Unter-nehmen ein? Wo steckt das größte Potenzial, wo liegen

die Fallstricke? Antworten auf diese Fragen gibt Ihnen die Continuous Lifecycle – die wichtigste deutsche Konferenz zu Continuous Delivery, DevOps und Containerisierung. Ganzheitlich widmet sie sich den Konzepten, Prozessen und Werkzeugen hinter Continuous Delivery, DevOps und Co. und bietet Erfahrungen, die Ihnen praktisch weiterhelfen.

Silber-Sponsoren:Gold-Sponsor:

Call for Papers bis 30. Mai 2016

THEMEN (Auszug)

■ Der richtige Umgang mit Continuous Delivery

■ Praktische Umsetzung von DevOps-Methoden

■ Werkzeuge für agiles Application Lifecycle Management (Versionskontrolle, Continuous Integration, Ticketing und Bugtracking)

■ Containerisierung mit Docker und den Werkzeugen aus dem Docker-Ökosystem

■ Build Management

■ Code-Reviews

■ Testen und Qualitätssicherung

■ Betrieb und Monitoring

■ Fallstricke und Best Practices verteilt arbeitender Software-Teams

ZIELGRUPPE

■ Softwareentwickler

■ Softwarearchitekten

■ Administratoren

■ Projektleiter

■ IT-Strategen

iX Developer 2016 – Effektiver entwickeln 3

EDITORIAL

D ie Softwareentwicklung zeigt derzeit Mut zur Größe –zur kleinen Größe. Der Trend geht weg von monolithi-schen Systemen hin zu kleinen Bausteinen wie Micro-

services. Auch die Zeiträume zwischen Releases schrumpfen:Statt alle ein bis drei Jahre ein großes Major Release herauszu-bringen und durch Service Packs zu ergänzen, veröffentlichenUnternehmen mithilfe von Continuous Delivery eine neueSoftwareversion, sobald sich eine Komponente ändert. GroßeInternetfirmen wie Google, Amazon oder Facebook aktualisie-ren ihre Plattformen inzwischen im Minutentakt. Dass dieNutzer davon nur bei Änderungen der Oberfläche etwas mitbe-kommen, zeigt, wie reibungslos die kontinuierlichen Prozessefunktionieren können. Ein Wartungsfenster am Wochenendeexistiert im Internet nicht. Die Softwareentwicklung wird zum ewigen Kreis.

Container bieten Entwicklern eine in sich abgeschlossene unddamit überschaubare Umgebung zum Testen und Ausrollen derAnwendungen. Dank der einfachen Reproduzierbarkeit könnendie Teams auf große Testumgebungen verzichten. Ändern sichdie Anforderungen oder Umgebungen, passen sie einfach dieSchablone an und rollen neue Container aus.

Containerisierung, Komponenten oder kontinuierliche Pro-zesse sind keine Erfindung der 2010er-Jahre, sondern haben in der ein oder anderen Ausprägung immer wieder den Weg indie Schlagzeilen geschafft. Oft scheiterten sie in der Realitätjedoch an Komplexität und Inkompatibilitäten. Es gibt jedochentscheidende Unterschiede, die den aktuellen Techniken undTools zum Erfolg verhelfen sollten.

Microservices punkten durch die Unabhängigkeit der einzel-nen Dienste voneinander: Jeder hat seine eigene Ablaufum -gebung und kommuniziert über Standardnetzwerkprotokollemit der Außenwelt. Frühere Modularisierungskonzepte be -dienten oftmals eine spezielle Sprache oder verwendeten einenApplikationsserver und scheiterten an der Zusammenarbeitüber die Grenzen hinweg. Docker-Container haben einenklaren Fokus auf Entwickler und sind leichter zu verwendenals vorherige Ansätze. Jenkins ist besonders wegen seiner Flexibilität und des offenen Plug-in-Konzepts zur festen Größefür Continuous Delivery geworden. Bei den Konfigurations-Management-Systemen buhlen vor allem Chef, Puppet und Ansible mit unterschiedlichen Stärken um die Gunst der Anwender.

Die technische Basis und die weitgehend quelloffenen Werkzeuge sind jedoch nur die halbe Miete. DevOps, also dasZusammenspiel von Softwareentwicklern (Dev) und den Administratoren (Ops), erfordert ein Umdenken der Beteilig-ten: Die Fraktionen müssen zusammenarbeiten und bei Pro -blemen gemeinsam nach Lösungen suchen. Wenn Entwicklerim Prozess der kontinuierlichen Verteilung eine Komponenteändern und damit einen neuen Build anstoßen, der die Ände-rung sofort ins Livesystem übernimmt, kommt ihnen undihrem Werk zudem eine höhere Bedeutung zu als bisher. Der Satz „You build it, you run it“ von Amazons CTO WernerVogels bringt es auf den Punkt: Jeder Entwickler ist für seinenCode verantwortlich und bekommt dadurch mehr Bezug zum Gesamtprodukt.

Der Kulturwandel erfordert Umdenken auf allen Ebenen. In einigen Projekten erweist es sich als sinnvoll, dass sich dasManagement aus dem Tagesgeschäft heraushält und somit deneinzelnen Teams mehr Verantwortung zuteilt. Auch traditio-nelle Unternehmen wie Maschinenbauer können durchaus von moderner Softwareentwicklung profitieren und mit denpassenden Ansätzen den Produktionsbetrieb in der Fabrik opti-mieren, ohne dort den reibungslosen Ablauf zu gefährden.Damit schließt er sich wieder, der ewige Kreis.

Mit diesem Heft möchten wir Ihnen helfen, sich bei denThemen Continuous Delivery, DevOps, Containerisierung undMicroservices zurechtzufinden. iX und heise Developerwünschen Ihnen viel Spaß beim Lesen!

RAINALD MENGE-SONNENTAG & ALEXANDER NEUMANN

Der ewige Kreis

Continuous Delivery… verspricht Produktivsetzungen der entwickeltenSoftware auf Knopfdruck bei besserer Qualität. Was sind die zentralen Ideen dahinter, welche Voraus-setzungen muss man schaffen, um damit erfolgreichzu sein, und was sind die wichtigsten Tools?

ab Seite 36

DevOps… lebt nicht nur von geeigneten Werkzeugen, sondernvor allem von gegenseitigem Vertrauen und geteilterVerantwortung. Erst dann lässt sich die Idee hinterDevOps umsetzen, wie Erfahrungen mit entsprechen-den Tools aus der Praxis zeigen.

ab Seite 66

EinführungPräambelWie DevOps, Continuous Delivery und Containerisierung zum idealen Gespann werden 8

QualitätssicherungZuverlässige Tests in der agilen Softwareentwicklung 12

Build-SecurityRisiken beim Bau von Anwendungen und Lösungsansätze für die Sicherheit 16

SystemautomatisierungEntwicklungs- und Produktionsumgebungen automatisiert bereitstellen und verwalten 24

Continuous DeliveryEine Einführung in Continuous Delivery – TutorialGrundlagen 36Commit Stage 40Acceptance Test Stage 46Bereitstellen der Infrastruktur 50

IntegrationswerkzeugContinuos Integration und Continuous Delivery mit Jenkins 54

DatenbankenSchemamigrationen mit Liquibase und Flyway 60

DevOpsIT-KulturDevOps führt Systemverwalter und Softwareentwickler zusammen 66

Automatisierungs-ToolsChef, Puppet und Ansible: Im Dienst der Continuous Integration 70

APMDevOps und Application Performance Management 76

DevSecDevOps, Compliance und Sicherheit 82

Strategien gegen die BlockadeSoftwareinnovationen im Maschinenbau 86

Change ManagementAgil allein reicht nicht – Veränderungen bei der 1&1 MyWebsite 90

BizDevOpsNächster Schritt in der Evolution mit einem holistischen Ansatz 94

4 iX Developer 2016 – Effektiver entwickeln

INHALT | IX DEVELOPER

Microservices… lassen sich unabhängig skalieren, und der Ausfalleines Service beeinflusst die anderen nicht. Je kleinerer ist, desto größer der Vorteil. Aber wo liegt dieGrenze für die Größe eines Microservice? Und wannergeben sie überhaupt Sinn?

ab Seite 100

Docker… vereinfacht den Test- und Produktivbetrieb. Die Docker-eigenen Werkzeuge decken die Grund -bedürfnisse ab, darüber hinaus ist inzwischen einreiches Ökosystem zur Orchestrierung der Container in nahezu beliebig komplexen Szenarien gewachsen.Best Practices sorgen für einen sicheren Betrieb.

ab Seite 126

MicroservicesArchitekturkonzeptMicroservices: Modularisierung ohne Middleware 100

PatternsDer perfekte Microservice 106

Enterprise ITWarum Microservices in großen Unternehmen mehr als nur Software sind 114

Java-MicroframeworksEin Blick auf Spark, Ninja, Jodd und Ratpack 120

ContainerEinführungWie Docker die IT-Landschaft revolutioniert 126

Docker-ToolsMulti-Tier-Applikationen mit Docker Compose, Machine und Swarm 130

ÖkosystemMehr als das Standardvorgehen: Tool-Auswahl für komplexe Docker-Szenarien 136

OrchestrierungMit Google Kubernetes viele Docker-Container verwalten 145

VirtualisierungDocker-Container sicher betreiben 150

SonstigesEditorial 3

DVD-Inhalt 6

Inserentenverzeichnis 113

Impressum 113


Alle Links: www.ix.de/ix1614004

Artikel mit Verweisen ins Web enthalten am Ende einenHinweis darauf, dass diese Webadressen auf dem Server deriX abrufbar sind. Dazu gibt man den iX-Link in der URL-Zeile des Browsers ein. Dann kann man auch die längstenLinks bequem mit einem Klick ansteuern. Alternativ stehtoben rechts auf der iX-Homepage ein Eingabefeld zur Verfügung.

http://www.ix.de/ix1614004


SERVICE | DVD-INHALT

Auf der Heft-DVDMultimediaVideos (Continuous Lifecycle 2015)

The Rationale for Continuous DeliveryDave Farleys Keynote-Vortrag von der Continuous Lifecycle 2015 ist ein zeit gemäßer Überblick zu den mit Con tinuous Delivery und DevOps ver -bundenen Entwicklungsprozessen.

Reinventing your Workplace – Struktur,Technik und Kultur bei 1&1 MyWebsiteDer Vortrag von Matthias Kainer und Marcel Devantier zeigt, wie Struktur,Technik und Kultur Hand in Hand gehen,welche Werkzeuge man dabei verwendenkann und wie schwierig es ist, alles zu ändern.

Microservices, DevOps, Continuous Delivery – mehr als drei BuzzwordsEberhard Wolffs Vortrag zeigt, wie Micro-services, Continuous Delivery und DevOpszusammenpassen und dass Microservicesmehr als ein Hype sind.

Branch-Modelle mit GitVerschiedene Entwicklungsszenarien erfordern passende Branches. Der Vortragvon Bjørn Stachmann und René Preißelzeigt Möglichkeiten, diese und weitereRelease-Prozesse mit Git umzusetzen.

Audio (SoftwareArchitekTOUR)

• Modularisierte Architektur für große Systeme• Know-how für Architekten• Architekturanalyse und -bewertung• Soziale Kompetenz für Architekten

SoftwareUbuntu 14.04.4Long-Term-Support-Release der populären Linux-Distribution, die für viele Artikel des Hefts herangezogen wurde.

Eclipse 4.5.2Auf der Heft-DVD finden Leser das zweite Update der Entwick-lungsumgebung in der Mars-Distribution für Java-Entwickler.

DevOps- und ProduktivitätswerkzeugeContinuous Delivery und DevOps sind ohne diese auf DVD zu findenden Tools nur schwer vorstellbar: Ansible, Chef, Puppet, Docker, Kubernetes, Marathon, Aurora, Mesos, Vagrant, Flyway,ˇLiquibase, Jenkins, VirtualBox.

Listings und LizenzenDie Listings zu den Heftartikeln und die Lizenzen zu den Software-paketen auf der Heft-DVD.

LiteraturMicroservices (Broschüre zum Buch)Diese von Eberhard Wolff konfektionierte Broschüre gibt eine kurze Einführung in dasThema Microservices und stellt dar, was Micro-services überhaupt sind und welche Vorteile sie haben. Das soll den Einstieg in das Themaerleichtern und helfen, die Einsetzbarkeit undden Nutzen von Microservices in einem be-stimmten Kontext abzuschätzen. So könnenMicroservices vom Hype zum sinnvollen Be-standteil im Werkzeugkasten eines Architektenwerden.

Continuous Delivery – Der pragmatische Einstieg (Buchauszüge)Continuous Delivery ermöglicht es, Softwareviel schneller und mit wesentlich höherer Zuverlässigkeit in Produktion zu bringen. Eberhard Wolffs Buch hilft, sich mit dem Auf-bau einer Continuous-Delivery-Pipeline ver-traut zu machen, und erklärt, welche Technolo-gien Entwickler dazu einsetzen können.

iX Developer „Bessere Software“Das von heise Developer 2013 zusammen -gestellte Heft zur Qualitätssicherung in derSoftwareentwicklung setzt auf 180 Seiten den Fokus auf die Schlagwörter „Agile ALM“, „Continuous Delivery“ und „DevOps“.

Hinweis für Käufer

• PDF-, Android- und iPad-Version: In der iX-App findenSie einen Button zum Download des DVD-Images.

• PDF-E-Book: Folgen Sie im Browser der unter „Alle Links“ angegebenen URL.

Alle Links: www.ix.de/ix1614006 x



Testqualität, Build-Security, SystemautomatisierungDie hier im Heft behandelten Themen Continuous Delivery, DevOps und Micro-services sind mehr als nur ein Hype, auf den sich alle stürzen. Grundlagen hierfürwie agile Testverfahren sowie Build- und Systemautomatisierung sind seit Jahrenbewährt. Das nährt die Hoffnung auf eine goldene Zukunft.

Wie DevOps, Continuous Delivery und Containerisierung zum idealen Gespann werden 8

Zuverlässige Tests in der agilen Softwareentwicklung 12

Risiken beim Bau von Anwendungen und Lösungsansätze für die Sicherheit 16

Entwicklungs- und Produktionsumgebungen automatisiert bereitstellen und verwalten 24

D ie Zahl der Untersuchungen und Konferenzen zum auchin diesem Sonderheft zentralen Thema DevOps nimmtkontinuierlich zu, genauso die Zahl der Unternehmen, die

mit Werkzeugen, Services und Dienstleistungen, aber auch Fort-bildungsangeboten an dem großen Kuchen rund um DevOpspartizipieren wollen.

Der Begriff selbst geht auf den Belgier Patrick Debois zu-rück, der Ende Oktober 2009 die ersten DevOpsDays mitorga-nisierteˇ[a]. Die Kombination aus „Dev“ für Anwendungsent-wicklung (Development) und „Ops“ für IT-Betrieb (Operations)steht für das Zusammenrücken der beiden Bereiche mit der Ab-sicht, dass eine Organisation Software schneller und fehlerfreiererstellen und verfügbar machen kann. Ziel ist also eine Verbes-serung ihrer Prozesse durch die hoffentlich gelebten DevOps-Prinzipien. Sie beruhen vorrangig auf denen der agilen Soft-wareentwicklung, genau genommen auf den Forderungen desdieses Jahr den 15-jährigen Geburtstag feiernden agilen Mani-festsˇ[b].

Immer wieder ist auch davon die Rede, dass mit DevOps nundie agilen Entwicklungspraktiken Einzug in den IT-Betrieb ge-halten haben. De facto sind die Zeiten vorbei, in denen Softwaresprichwörtlich „über die Mauer geworfen“ wird. Der Kommu-

nikation zwischen den Abteilungen kommt so eine viel größereBedeutung zu, wie schon das agile Manifest propagiert.

Das Ziel von DevOps-Praktiken wie Continuous Delivery –übrigens ebenfalls ein Schlagwort im erwähnten Manifest –,Versionskontrolle und automatisierte Tests ist eine häufigere In-betriebnahme von Software bei gleichzeitiger Reduzierung derAusfälle. Das impliziert ein reibungsloses Zusammenspiel zwi-schen den Abteilungen und mündet in Zufriedenheit mit demJob, da Softwareentwickler ihr Produkt schnell und transparentausliefern – ein Erfolgserlebnis ist sichtbar – und Administrato-ren einen zuverlässigeren Betrieb gewährleisten können. Hinzukommt, dass alle Beteiligten am Entwicklungs- und Auslie -ferungsprozess oder zumindest möglichst früh in die Design -entscheidungen eines Systems eingebunden sind. Das fördert ei-nerseits das Gemeinschaftsgefühl, andererseits werden Fehlerwomöglich früher erkannt.

Dass die Einführung der DevOps-Maßnahmen in der Praxistatsächlich fruchtet, ist aus jüngsten Erhebungenˇ[c] zum Themazu beobachten: Mehr als drei Viertel der deutschen Entwicklersind demnach der Meinung, dass seit der Anwendung von Dev -Ops weniger Probleme beim Live-Gang von Neuentwicklungenauftreten. Zugleich kommt es wohl zur Verkürzung der Release-


EINFÜHRUNG | PRÄAMBEL

Wie DevOps, Continuous Delivery und Containerisierung zum idealen Gespann werden

TriumviratAlexander Neumann, Rainald Menge-Sonnentag

Ohne Frage ist DevOps mehr als nur ein Hype, auf den

Tool-Hersteller, Dienstleisterund Konferenzanbieter auf-springen. Mehrere Indikato-ren sprechen für die Durch -dringung der mit dieser Bewegung einhergehendenPrinzipien in den IT-

Abteilungen.

Zyklen und zur Steigerung der Produktivität in der IT insge-samt. Allerdings scheint bislang noch nicht mal die Hälfte allerdeutschen Entwicklungsabteilungen die DevOps-Konzepteoder -Praktiken eingeführt zu haben. Jedoch planen anscheinendviele, auch auf den DevOps-Zug aufzuspringen. Die damit ein-hergehenden Prinzipien zu etablieren, stellt jedoch kein leichtesUnterfangen dar. Denn DevOps bedeutet an erster Stelle einenKulturwandel, auf den sich mindestens die IT-Abteilung einesUnternehmens einigen muss.

Die Mauern überwinden

Doch sind in vielen Unternehmen Softwareentwicklung und IT-Betrieb immer noch zwei getrennte Einheiten, die traditionellgegenläufige Ziele verfolgen und zumindest bis vor kurzem un-terschiedliche Werkzeuge einsetzten. Während die Entwicklungneue Features in möglichst hoher Frequenz veröffentlichenmöchte, ist der Betrieb für eine hohe und schnelle Verfügbar-keit verantwortlich. Dieser Gegensatz zwischen Veränderungund Stabilität hat häufig Konflikte zur Folge – insbesonderedann, wenn in Unternehmen keine übergreifende Sicht auf die-ses Thema existiert, was die Spannungen noch verstärkt. Manspricht hier von einer „Wall of Confusion“ zwischen Entwick-lern und Admins, die nicht selten sogenannte „Blame Games“zur Folge haben („Die Artefakte und Config-Dateien warenfehlerhaft.“; „Bei uns hat alles funktioniert, ihr habt was falschgemacht.“ etc.). Währenddessen kann niemand mit der Soft-ware arbeiten – irgendwie blöd, denn Kunden ist es egal, obder Fehler bei Development oder Operations liegt. Die Konse-quenz muss also sein, dass die beteiligten Parteien näher zu-sammenrücken.

Die womöglich über Jahrzehnte gewachsenen Strukturenaufzubrechen, ist jedoch nicht einfach. Deswegen verwundertes nicht, dass viele an der DevOps-Einführung Beteiligte voneinem anfänglichen Chaos sprechen. Fast drei Viertel der mitDevOps experimentierenden Unternehmen greifen deswegenauf externe Dienstleister zurück, um sich helfen zu lassenˇ[d].Die zum Einsatz kommenden Werkzeuge können dabei eine zu-nehmend gewichtigere Rolle spielen. Glücklicherweise habenviele der auch in diesem Heft zur Sprache kommenden Toolsmittlerweile den Status eines De-facto-Standards: Beispielswei-se kommt der Continuous-Integration-Server Jenkins unter denCI-Tools schon auf eine Verbreitung von 75ˇProzent. Quellof-fene Konfigurations-Management-Systeme wie Ansible, Chef

und Puppet genießen große und immer noch zunehmende Ver-breitung.

Mit Docker gibt es nun das Werkzeug schlechthin, mit demsich (nicht nur) die Zusammenarbeit von Devs und Ops sinn-voll praktizieren lässt. Es bietet neue Möglichkeiten, wie Soft-ware gebaut, verteilt und betrieben wird. Denn es definiertSchnittstellen zwischen den Teams mit der Folge, dass AdminsMonitoring, Logging, Networking und Persistenz für Anwen-dungs-Container bereitstellen können, ohne dass das Auswir-kungen auf die Software im Container hat. Das bedeutet in derKonsequenz, dass Anwendungen, die in der Testumgebung feh-lerfrei arbeiten, in der Produktivumgebung ebenso funktionie-ren. Sollten denn doch Fehler auftauchen, lassen sie sich immergenau zuweisen.

Die Nutzung von Docker bedeutet jedoch auch, dass sich dieArbeitsweise, wie bislang Software entwickelt und adminis-triert wurde, grundlegend verändert – Softwareentwickler sindmehr denn je als Kommunikatoren gefragt. Nicht wenige spre-chen bei Docker gar fast schon von einer Revolution für dieSoftwareentwicklung; zumindest lässt sich feststellen, dass esbisher kaum eine Software gegeben hat, die von Entwicklernund Administratoren gleichermaßen begrüßt wurde. Das bei-seite gelassen, ist die Popularität von Docker konkret mit Zah-len festzumachen. So hat sich laut der erwähnten Right Scale-Studieˇ[d] der Einsatz des Werkzeugs innerhalb eines Jahresoffenbar von 13 auf 27ˇProzent mehr als verdoppelt. Weitere35ˇProzent planen die zukünftige Verwendung. Bei den über1000 befragten Entwicklern arbeiteten mehr als 40ˇProzent fürUnternehmen mit mehr als 1000ˇAngestellten.

DevOps ist womöglich erst der Anfang

In einem weiteren und hier letzten Schritt mag es sogar sinnvollsein, das Thema DevOps noch größer zu denken und weitereAbteilungen (Schlagwort „DevOpsBiz“), ja sogar das ganze Un-ternehmen in die agilen Prozesse einzubinden. Einige wenigepraktizieren das schon, andere informieren sich in die Richtung,für die meisten Firmen ist das jedoch ferne Zukunftsmusik –wenn überhaupt. Die Zeiten, in denen IT-Abteilungen innerhalbvon Unternehmen eine Randrolle spielten, sind jedoch vorbei.„Software Is Eating the World“ – das Bonmot von Marc An-dreessen, dem Erfinder des Netscape-Browsers und heutigen In-vestor, trifft im Zuge einer zunehmend digitalisierteren Gesell-schaft heute noch mehr zu als im Jahr 2011, aus dem der Satzstammtˇ[e].

Derzeit befinden sich Softwareentwicklung und -betrieb alle-mal auf einem guten Weg. Was mit agiler Softwareentwicklungund Continuous Integration vor über 15ˇJahren seinen Auftaktnahm, dann seine Fortführung in Konzepten wie Continuous De-livery gefunden hat, erreicht bei DevOps ein erstes Zwischen-hoch, das in andere Unternehmensbereiche hineinwirkt. Tools wieDocker tragen ihren Teil dazu bei, möglichst konfliktfrei undgleichzeitig hochqualitativ Software über den ganzen Anwen-dungslebenszyklus hinweg zu entwickeln und auszuliefern. (ane)

Alexander Neumann und Rainald Menge-Sonnentagsind Redakteure von heise Developer und haben dieses Sonderheft konzipiert.


EINFÜHRUNG | PRÄAMBEL

[a] Erste DevOpsDays in Ghent www.devopsdays.org/events/2009-ghent/[b] Agiles Manifest agilemanifesto.org/iso/de/[c] Developer Week; Umfrage zu DevOps und

Cloud vs. Server, Teil 1: DevOpswww.developer-week.de/content/download/20642/225705/file/DWX2016-Studie_zu_DevOps.pdf

[d] Cloud Computing Trends: 2016 State of the Cloud Survey (Studie von RightScale)www.rightscale.com/blog/cloud-industry-insights/cloud-computing-trends-2016-state-cloud-survey

[e] Marc Andreessen; Why Software Is Eating The World www.wsj.com/articles/SB1000142405311190348

0904576512250915629460

Onlinequellen



M it dem Aufkommen agiler Softwareentwicklung stellensich viele Teams die Frage, wie sie das Testen der Soft-ware effektiv gestalten. Kurze Zyklen von wenigen Wo-

chen sind die Norm. Am Ende jedes Zyklus soll eine potenziellauslieferbare Version der Software entstehen. Das einzige, wasder Auslieferung im Wege steht, soll die Entscheidung einesVerantwortlichen wie des Product Owner in Scrum sein. Dafürist der ordentliche Test der Software unerlässlich, um Risikenvor der Auslieferung zu vermeiden und dem Endanwender keine„Bananensoftware“ zu liefern, die beim Kunden reift. Das Tes-ten von Software erfüllt damit einen essenziellen Mehrwert inder Bewältigung von Geschäftsrisiken.

Klassisch unterscheidet die Welt des Testens verschiedeneTestarten, -stufen und unterschiedliche Herangehensweisen.Unit-Tests, User-Acceptance-Tests, Integrationstests mit unter-schiedlichen Komponenten, Last- und Performancetests, manu-elles Testen und Testautomatisierung sind weitverbreitete Me-thoden, um die Qualität einer Software sicherzustellen. Für denErfolg kommt es vor allem auf die ausgewogene Mischung imjeweiligen Projektkontext an. In einem agilen Projekt liegt eingroßer Teil der Verantwortung beim Entwicklungsteam.

Bei der Antwort auf die Frage, wie ein agiles Team zu einersinnvollen Auswahl unterschiedlicher Vorgehensweisen kommt,hilft eine grundlegende Kenntnis der jeweiligen Stärken undEinsatzgebiete. Das Modell von Nassim Nicholas Taleb [1] un-terscheidet zwischen bewusstem und unbewusstem Wissen undUnwissen (s.ˇAbb.ˇ1). Bei unbewusstem Wissen handelt es sichum eingespielten Abläufe, die im Englischen „muscle memo-ry“ genannt werden. Bewusstes Wissen umfasst all das, wasMenschen mit etwas Anstrengung ihrer kognitiven Fähigkeitenabrufen können. Bewusstes Unwissen bezieht sich auf jeneDinge, über die sie (noch) nichts wissen. Das unbewusste Un-wissen ist alles, von dem sie noch nicht einmal wissen, dasssie es nicht wissen. Unterschiedliche Testarten können Teamsbei ihrem Wissen und Nichtwissen rund um ihre Software un-terstützen.

Bewusstes Wissen

Übertragen auf die Softwareentwicklung fällt unter bewusstesWissen beispielsweise die Kenntnis der Applikationsanforderun-


EINFÜHRUNG | TESTQUALITÄT

Zuverlässige Tests in der agilen Softwareentwicklung

Mit ArgusaugenMarkus Gärtner

Gute Tests sind ein Muss beim Erstellen zuverlässiger Software. Die kurzen Releasezyklen im Prozess der Continuous Delivery stellen neue Anforderungen

an die Tester. Sie müssen die richtigen Methoden für die jeweiligen Stufen auswählen und reproduzierbar wiederholen.

gen oder das Domänenwissen zum Einsatzgebiet der Software.Bei vorhandenen Systemen zählt auch das Know-how der Ar-chitektur und deren Design, also welche Elemente in der Soft-ware welchem Zweck dienen, die Aufgabe jeder kleineren Klas-se sowie das Zusammenspiel von mehreren Klassen, um dasdarunter liegende Businessproblem zu lösen.

Das wirft die Frage auf, in welcher Form Teams das gesam-melte Wissen festhalten können. Klassische Ansätze orien -tieren sich zumeist an Anforderungsdokumenten sowie Archi-tektur- und Designspezifikationen. Über die Zeit können dieDokumente jedoch veralten und nicht mehr viel mit dem An-wendungsverhalten zu tun haben. Die agile Softwareentwick-lung setzt einen stärkeren Fokus auf funktionierende Softwareals auf allzu ausführliche Dokumentation, weil Letztere nurschwerlich alles notwendige Wissen vermitteln kann. Die Ein-arbeitung neuer Projektmitarbeiter durch die Dokumentationist nicht unmittelbar möglich. Zudem prüfen Kunden ausführ-liche Anforderungsdokumente nicht unbedingt vollständig aufihre Korrektheit.

Automatisierte Tests können an die Stelle klassischer Doku-mentation treten. Die Vorteile davon liegen auf der Hand: Wenndie Tests regelmäßig, beispielsweise in einem Continuous-Inte-gration-System, mit jeder Änderung ausgeführt werden, ist si-chergestellt, dass sie das Wissen widerspiegeln, das zur Entwick-lung eines Teils der Software vorhanden war. AutomatisierteUnit-Tests auf der kleinsten Ebene wie individuelle Klassen undFunktionen dokumentieren dabei das Softwaredesign. Tests, diemehrere Klassen heranziehen, dokumentieren die größeren De-sign- und Architekturentscheidungen. Automatisierte Akzeptanz-tests halten zum einen die Anforderungen an die Software – alsodas Domänenwissen – fest, zum anderen steckt auch die Kennt-nis der Architektur im Automatisierungscode.

Im Gegensatz zu klassischer Dokumentation erfüllen die au-tomatisierten Tests eine weitere Bedingung: Durch regelmäßigesAusführen ist sichergestellt, dass sie auf dem aktuellen Standhinsichtlich der Codebasis sind. Damit kann eine gute automa-tisierte Testbasis Wissen zur Anwendung auch für Neulinge imCode dokumentieren und effektiver transportieren als geschrie-bene Texte.

Unbewusstes Wissen

Unbewusstes Wissen umfasst die Dinge, die der Mensch ohnegezielt eingesetzte Überlegungen tut. Wer morgens immer dengleichen Weg zur Arbeit nimmt, kennt den Effekt. Man steigtmorgens in das Beförderungsmittel seiner Wahl und weiß amEnde der Reise gar nicht mehr, wie man ins Büro gekommenist. In dem Fall hat der Mensch unbewusstes Wissen für das Au-tofahren oder das Umsteigen bei öffentlichen Verkehrsmittelnverwendet.

Notfalleinsatzkräfte trainieren in regelmäßigen AbständenAbläufe, die sie in einer brenzligen Situation unbewusst abrufen

können müssen. Dazu gehört die obligatorische Auffrischung imAbstand von zwei Jahren.

Ähnlich verhält es sich mit diversen Praktiken rund ums Ent-wickeln und Testen: Wer in einem stressigen Projekt ist und kei-ne Zeit hat, an seinen Fertigkeiten zu arbeiten, sollte im Eiferdes Gefechts Grundwissen abrufbereit haben. In der SoftwareCraftsmanship Community ist daher das stetige Durchführenvon Code-Katas verbreitet. Das sind kleine, abgeschlosseneÜbungen, bei denen es um die effektive Anwendung von test-getriebener Entwicklung und emergentem Design geht. Soft-warehandwerker wissen, dass sie regelmäßig einstudierte Prak-tiken in stressigen Situationen unbewusst abrufen können. Dafürgibt es den englischen Fachausdruck „Deliberate Practice“, alsowohldurchdachtes Praktizieren.

Vergleichbares kann man auf mehreren Ebenen für Soft-waretests anwenden. In einem stressigen Projekt oder Sprint,in dem ein Mitstreiter ausgefallen ist, sollen Teams ein Grund-maß an Wissen schnell abrufen können, ohne lange darübernachzudenken. Zum Einstudieren können sie beispielsweise regelmäßig an Testing Dojos teilnehmen. Dabei schärfen dieTeilnehmer anhand kleiner Applikationen ihre Fähigkeiten undlernen, nützliches Wissen außerhalb der Arbeitsumgebung ineinem sicheren Umfeld anzuwenden. Vor allem entsteht wäh-rend der Trainingsphase kein Schaden, wenn doch ein Fehlerübersehen werden sollte.

Weitere Möglichkeiten zur Schärfung des unbewussten Wis-sens bestehen darin, frei im Internet verfügbare Applikationenzu testen und dabei beispielsweise Wissen aus einem frisch ge-lesenen Blog-Eintrag anzuwenden. Vor einigen Jahren hat derAutor bei einem Kunden einen Testing-Dojo-Workshop organi-siert, bei dem es darum ging, das Wissen rund um den Billing-Teil der Applikation zu vertiefen. In den Teams vor Ort kam esbei Änderungen an der Abrechnungskomponente immer wiederzu Problemen, aber kein Teilnehmer wusste, wie sie die Modi-fikationen testen konnten. Geholfen hat schließlich, dass meh-rere testaffine Teilnehmer jeweils in Paaren unter Zuhilfenahmeder REST-API-Dokumentation gearbeitet haben. Am Ende desWorkshops hat die Gruppe zusätzliche Schritte zur Verbesserungder Testbarkeit der betroffenen Komponente auf den Weg ge-bracht, sodass sich die unterschiedlichen Personen jetzt sichererim Umgang mit ihr fühlen.

Bewusstes Unwissen

Das bewusste Unwissen umfasst die Dinge, von denen derMensch weiß, dass er sie nicht weiß. Darunter fällt etwa das Do-


Wissen und Unwissen könnenbewusst und unbewusst sein(Abb.ˇ1).

bewusstes Wissen

bewusstes Unwissen

unbewusstes Wissen

unbewusstes Unwissen

Test-drivenDevelop ment

(TDD) und Accep-tance Test-driven

Development(ATDD) adressie-ren unterschied -

liches Wissen. Während es bei

TDD um die einge-setzte Technologie

geht, hilft ATDDbeim Verstehen

der Anwendungs-domäne (Abb.ˇ2).

Dom

ain

Technology

simple

chaos

complicated

Complex

complicated

lex

Com

ATDD

TDD

mänenwissen beim Entwickeln einer neuen Applikation. Eskann auch das Know-how der eingesetzten Techniken sein: WennEntwickler ein neues Framework im Code ausprobieren wollen,treffen sie auf eine unbekannte Funktionsweise. Teile des be-wussten Unwissens kann man ignorieren. Wenn jedoch bei-spielsweise das Spezialwissen eines Teammitglieds gefragt ist,das in Urlaub ist oder ausfällt, hindert die Unkenntnis das Teamdaran, weiteren Wert für den Kunden zu schaffen, bis der Kol-lege zurück ist.

Weg zur Erkenntnis

Bei bewusstem Unwissen können sich die Betroffenen mit derneuen Technologie oder dem Unbekannten auseinandersetzen.Sie erlangen neues Wissen, wenn sie mehr über das Unbekanntelernen. Kent Beck setzt etwa testgetriebene Entwicklung (engl.:Test-driven Development, TDD) auch dazu ein, um Entwicklermit einer neuen Umgebung vertraut zu machen. Als Seiteneffektentstehen bei diesem Vorgehen Unit-Tests, die das Gelernte inbewusstes Wissen überführen.

Diese Technik lässt sich analog auf die Anwendungsdomäneanwenden (s. Abb. 2). Wenn Teams bei neuen Funktionen Ak-zeptanztests festhalten und sie automatisieren, schaffen sie denÜbergang von bewusstem Unwissen zu bewusstem Wissen. Dieautomatisierten Akzeptanztests reflektieren nach der Implemen-tierung der Funktion das, was die Mitarbeiter bei der Umsetzunggelernt haben. Das ermöglicht eine gezielte Transformation vonUnkenntnis zu einer manifestierten Wissensbasis.

Damit das gelingt, müssen entsprechende Unit- oder Ak -zeptanztests aussagekräftig geschrieben sein. Wenn sich jemandNeues mit der Funktion in der Zukunft auseinandersetzt, solltendie Entwickler die aktuelle Lernkurve nachvollziehen können.Unit-Tests müssen daher fokussiert und überschaubar sein. Diegleichen Prinzipien gelten für automatisierte Akzeptanztests.Wenn sie geskriptet sind, dokumentieren sie nur auf schwer über-schaubare Art und Weise das darunter liegende Businessproblemund dessen Lösung. Deswegen sind für akzeptanztestgetriebe-ne Entwicklung (engl.: Acceptance Test-driven Development,ATDD) ebenfalls aussagekräftige Tests ein wichtiger Bestandteil.Teams sollen sich nicht lange erarbeiten, was sie sich bei einerUmsetzungsentscheidung gedacht haben, sondern das im Ideal-fall in drei prägnanten Zeilen bereits ablesen können.

TDD sowie ATDD können wichtige Entscheidungen gezieltvon bewusstem Unwissen zu bewusstem Wissen überführen.Bei TDD halten die Mitarbeiter Designentscheidungen für dieZukunft fest. Bei ATDD erhalten sie langfristig eine Wissens-basis, die sie beispielsweise bei neuen Entwicklungen heranzie-hen können, um vorab Seiteneffekte erkennen zu können.

Unbewusstes Unwissen

Der Umgang mit unbewusstem Unwissen ist schwieriger. Esumfasst die Dinge, von denen Menschen noch nicht mal wissen,dass sie über etwas keine Kenntnis haben. Dazu gehören bei-

spielsweise überraschende Effekte im Reiseverkehr, etwa wennein Vulkan Asche in die Atmosphäre pustet und deshalb keineFlugzeuge mehr starten oder landen dürfen.

Solche Effekte existieren ebenso in der Softwareentwicklung.Der Autor war beispielsweise vor einigen Jahren für den Sup-port eines Systems eingeteilt, das Mobilfunktelefonate in Echt-zeit abrechnete. Als er abends einen Anruf bekam, schaute ersich die Log-Informationen des Systems an und fand mehrereFehler. Es dauerte über einen Tag, bis er die Probleme des Sys-tems erkannt hatte: Es handelte es sich um eine Neuinstallationeines Systems, auf dem 100 Mobilfunkteilnehmer testweise ak-tiv geschaltet waren. Natürlich hatte die Installation einen UserAcceptance Test (UAT) im Vorfeld hinter sich. Trotzdem war esfaktisch für keinen der Teilnehmer möglich, ein Telefonat zu tä-tigen. Innerhalb von 24 Stunden hatte der Autor etwa 20 kriti-sche Fehler aus den Log-Dateien identifiziert. Auf keinem derTestsysteme traten die Fehler zuvor auf. Viele davon ließen sichdarauf zurückführen, dass unterschiedliche Subkomponenten inProduktion in Grenzfällen nicht miteinander sprechen konnten.Selbstverständlich gab es im Vorfeld umfangreiche Testmaßnah-men, von denen aber keine auf die Probleme hinwies. Erst imProduktionssystem war das Team in der Lage, das unerwünschteVerhalten zu beobachten.

Risiken einschätzen

Unbewusstes Unwissen steht oft im Fokus des traditionellenRisikomanagements: Man versucht, Projektrisiken vorab ein-zuschätzen, um sie bekämpfen zu können. Das soll Unwissenbewusst machen. In Bezug auf das Testen von Software kannein risikobasierter Ansatz dabei helfen, unbekanntes Unwissenzu ergründen. Ein agiles Team mit seinen kurzen Iterationenwill möglichst früh Gefahren erkennen. Dabei kann ein Ansatzüber risikobasierte Tests helfen, unbekanntes Unwissen aufzu-decken.

Exploratives Testen kann in beiden Fällen dafür genutzt wer-den, sich mit der Applikation vertraut zu machen und so vor-handenes Unwissen zu entdecken. Dabei arbeiten Teams in kur-zen Zeitabschnitten von beispielsweise 60ˇMinuten unter einemThema mit der Applikation. Das auch Testcharter genannte The-ma [2] hilft dabei, die Aktivitäten in der kurzen Zeit zu fokus-sieren. Wenn etwas Unvorhergesehenes eintritt, können Testerentscheiden, ob es zur Testcharter passt und sie das Problemweiterverfolgen oder ob sie sich eine kurze Notiz machen undsich in einer zukünftigen Session damit auseinandersetzen. NachAblauf der 60ˇMinuten geht der Tester seine Notizen durch undidentifiziert neue Themen, auf die er noch ein Auge werfenmöchte.

Das große Zusammenspiel

Bewusstes Unwissen lässt sich mithilfe testgetriebener Ent-wicklung in bewusstes Wissen überführen. Auf neues Un -wissen stoßen Teams dabei, indem sie in regelmäßigen Abstän-

den exploratives Testen verwenden, um all dieDinge, die sie bislang noch nicht antizipiert ha-ben, entdecken zu können. Bei jedem neuenProblem, das sie mit explorativem Testen ent-decken, können sie sich überlegen, ob sie denAufwand in die Automatisierung eines Testsstecken, damit sie das Know-how zukünftigpräsent haben werden. Damit schaffen sie den


EINFÜHRUNG | TESTQUALITÄT

Zeit für Automatisierung kann nicht mehr in das Erforschen von Risiken gesteckt werden; Zeit für manuelles Testen kann nicht mehr für die Automatisierung genutzt werden (Abb.ˇ3).

Exploration

Automation

Weg von unbewusstem Unwissen über bewusstes Unwissenhin zu bewusstem Wissen. Die Feedbackschleife von explo -rativem Testen zu automatisierten Tests führt dazu, dass sieneue Risiken in regelmäßigen Abständen entdecken und miti-gieren können.

Dabei muss das Team allerdings auch den Aufwand für diejeweiligen Aktivitäten im Auge behalten. Die Zeit, die es in dieAutomatisierung eines Tests steckt, fehlt eventuell für dasAdressieren von Risiken durch explorative Tests. Andersherumgilt: Jeder manuelle Test nimmt dem Team die Zeit, einen Testzu automatisieren (s. Abb. 3).

Fazit

Die Frage nach dem richtiges Maß an Automatisierung undExploration lässt sich nicht kontextfrei beantworten: Hat einTeam viele Risiken in Form von Altlasten im Code bezie-hungsweise in Form technischer Schulden aufgebaut und kanndeshalb nur schwer automatisiert testen, wird es vermutlichmehr manuellen Testaufwand einplanen. Wenn die Applikationmit einer hohen Codeabdeckung testgetrieben auf Unit- undAkzeptanztestebene entwickelt wurde, wird das Team mehrAufwand in die Pflege der vorhandenen Testbasis stecken unddadurch weniger Zeit für manuelle Tätigkeiten haben. Das ge-sunde Maß hängt auch davon ab, wie gut das Team die Anwen-dungsdomäne und die eingesetzten Techniken kennt. Daher be-stimmt der jeweilige Projektkontext die richtige Mischung ausautomatisierten und rein manuellen Tests. In der Agilität setzt

man dazu bewusst auf regelmäßige Retrospek tiven, in deneneine ungesunde Balance zwischen den beiden transparent wer-den kann. Das Team kann dadurch gezielt sein Vorgehen aufden Projektkontext anpassen.

Darüber hinaus sollten sich alle Mitarbeiter kontinuierlichweiterentwickeln. Coding- und Testing-Dojos helfen dabei, Fä-higkeiten rund um testgetriebene Entwicklung, emergentes De-sign und Architektur sowie exploratives Testen zu verbessern,damit alle Beteiligten sie in ihren Projekten effizient anwendenkönnen. (rme)

Literatur[1]ˇNassim Nicholas Taleb; The Black Swan – The Impact of the

Highly Improbable; Random House 2010[2]ˇElisabeth Hendrickson; Explore It! – Reduce Risk and Increase

Confidence with Exploratory Testing; O’Reilly 2013

Markus Gärtnerarbeitet als Organizational Design Consultant, Certified Scrum Trainer (CST) und Agile Coach für die it-agile GmbH in Hamburg. Er schrieb unter anderem ATDD by Example – A Practical Guide to Acceptance Test-driven Development und erhielt den Most Influential Agile Testing Professional Person Award in 2013.




In einem Projekt läuft ein Build auf einen Fehler. Die Detailsder Fehlermeldung zeigen auf eine bestimmte Datei, eine Java -Script-Bibliothek. Nur, dass diese Datei keinen JavaScript-

Code enthält, sondern stattdessen HTML, mit der Botschaft:„Diese Domain können Sie kaufen.“ Der Autor der Bibliothekhatte augenscheinlich seine Domainregistrierung nicht verlän-gert, sodass sie an einen Grabber gefallen war, der nicht mehrdas ursprüngliche JavaScript, sondern stattdessen seine Werbungals HTML auslieferte.

An dieser Anekdote ist leider nichts erfunden; sie ist dem Au-tor genau so passiert. Es handelte sich um ein großes Enter -prise-Projekt, in dem die Anwendungssicherheit kontinuierlich

thematisiert wurde und verschiedene Reviews und Prozesse vor-geschrieben waren, um sie zu stützen. Die Build-Umgebung hat-te man dabei jedoch weitgehend außen vor gelassen.

Zu Unrecht: Denn bei entsprechende krimineller Energie hät-te auch Schlimmeres in der veränderten Datei stecken könnenals nur Werbung. So gesehen ist das Projekt haarscharf am Alb-traum eines erfolgreichen Angriffs vorbei geschrammt.

Die Spitze des Eisbergs

Die Projektbeteiligten hatten sich dabei keineswegs außerge-wöhnlich leichtsinnig verhalten, sondern nur gehandelt, wie esheute üblich ist: Sicherheitsanalysen konzentrieren sich aufden selbstentwickelten Anwendungscode und die Infrastrukturder Produktionsumgebung. Mit dem eigenen Anwendungscodeüberprüft man aber nur einen kleinen Bruchteil dessen, wasschlussendlich in der Produktionsumgebung läuft. Eine beispiel-hafte Zählung der Codezeilen einer gerade verfügbaren produk-tiven Ruby-on-Rails-Anwendung ergab die in Abbildungˇ1 dar-gestellten Ergebnisse.

Das passt ins allgemeine Bild: Softwareentwickler verdankendie eigenen Erfolge auch der immer leistungsfähigeren vorge-


EINFÜHRUNG | BUILD-SECURITY

Risiken beim Bau von Anwendungen und Lösungsansätze für die Sicherheit

Achtung: Baustelle in Gefahr

Andreas Krüger

Unternehmen härten Anwendungen, um zu verhindern, dass ein AngreiferSchadfunktionalität einschmuggelnkann. Sie schützen ihre Produktions -um gebungen und schotten sie ab. Aber Angreifer können versuchen,„über Bande zu spielen“ und in eineAnwendung einzubrechen, indem sie die Build-Umgebung manipulieren.

Documents

Massig Material Effektiver entwickeln€¦ · Der perfekte Microservice 106 Enterprise IT Warum Microservices in großen Unternehmen mehr als nur Software sind 114 Java-Microframeworks