Gearconf - Gradle Workshop

Gradle für Einsteiger

Dr. Joachim Baumann

Referenzen  (Auszug)  n  Nürnberger  Versicherungsgruppe,  Nürnberg  

p  Absatzplanungssystem  der  Nürnberger  Versicherung  p  Technischer  Projektleiter  p  Architekt  

n  FIDUCIA  IT  AG,  Karlsruhe  p  Architekturberatung  p  Übernahme  kriFscher  Projekte  p  Qualitätssicherung  p  Coaching  

n  NTT  DATA,  Tokyo  p  Entwurf  einer  neuen  agil  basierten  Methode  für  24-­‐

Stunden  Entwicklung  p  VerifikaFon  der  Methode  in  einem  von  3  

Vergleichsprojekten  p  Preis  für  das  Projekt  von  NTT  DATA  

n  ArFkel,  Bücher,  Vorträge  p  3  Bücher    p  Über  40  ArFkel  p  Vorträge  auf  int.  und  deutschen  Konferenzen  p  Beispiele  

—  „Groovy:  Grundlagen  und  fortgeschriYene  Techniken“,  d.punkt  Verlag,  600  S.  

—  „Groovy:  Grundlagen“  in  iX-­‐Sonderhe\  Java  Kompakt  1/2009  „Gradle:  Ein  kompakter  EinsFeg  in  das  Build-­‐Management-­‐System“,  d.punkt-­‐Verlag,  260  S.  

Schwerpunkte  n  Architektur  großer  Systeme  n  Open-­‐Source-­‐Produkte  n  KommunikaFonsnetze,  Mobile  CompuFng,  Verteilte  Systeme,  

Datenbanken  n  Training,  Coaching,  Vorträge  n  Agile  Methoden  n  Big  Data  

Ausbildung  1986-­‐1992  InformaFk  

   UniversiYät  StuYgart  1994-­‐1999  PromoFon    

   Universität  StuYgart,  Universität  Genf  1999-­‐2000  Postdoc  

   Universität  StuYgart    Beruflicher  Werdegang  1993  ANT  Bosch  Telecom,  So\ware-­‐Entwickler  2000  COSS  So\waretechnik  AG,  Bereichsleiter  Produktentwicklung  

und  Forschung  2001  Junidas  GmbH,  Geschä\sführer  2005  Xinaris  GmbH,  Geschä\sführer  2007  Cirquent  GmbH,  Leitung  Competence  Center  iBPM,  Director  

Shoring  2012  codecentric  AG,  Geschä\sführer  Frankfurt  

codecentric auf einen Blick

Das Unternehmen codecentric AG

•  Europaweit •  10 Standorte •  200 Spezialisten

•  4 Bereiche •  Beratung •  Agile Software Factory •  Performance Solutions •  Meettheexperts

(Schulungen & Workshops)

Niederlande  Düsseldorf  Solingen  

München  

Serbien  Bosnien  und  Herzegowina  

Schweiz  

Frankfurt  

3  Datum / Unternehmensvorstellung

Hamburg  

Berlin  

Karlsruhe  

Werte der Codecentric

Erwartete Funktionalität eines Build-Management-Systems

•  Übersetzung von Quelltexten

•  Linken der Ergebnisse

•  Checkout der Quelltexte aus dem Versionsverwaltungssystem (kann ausgelagert werden)

•  Setzen von Tags (kann ausgelagert werden).

•  Ausführen verschiedener Arten von Tests. Beispiele sind:

–  Unit-Tests für einzelne Klassen

–  Modul- oder Komponententests

–  Integrationstests

–  Funktionale und nichtfunktionale Systemtests

–  Automatisierte Akzeptanztests

•  Detaillierte Test-Reports, die die Testergebnisse übersichtlich zusammenfassen.

•  Packen des Resultats (z.B. eine Jar-, War- oder Ear-Datei)

•  Transfer des Resultats zu den verschiedenen Testsystemen und Ausführung entsprechender Testarten (häufig durch Build-Server übernommen).

•  Unterstützung für polyglotte Projekte.

•  Erzeugung von Dokumentation und Release Notes.

Wünsche an ein Build-Management-System

•  Explizite Unterstützung des Workflows, der durch das Build- Management-System implementiert wird.

•  Leichte Anpass- und Erweiterbarkeit des Workflows, um sich an lokale Vorgehensmodelle anpassen zu können.

•  Leichte Lesbarkeit und selbsterklärende Notation der Sprache des Build-Skripts.

•  Verwendung von Konventionen, um vernünftige Vorgabewerte für die verschiedenen Schritte des Workflows zu haben (wie zum Bei-spiel die Orte, an denen sich die Quelltexte befinden).

•  Leichte Änderbarkeit der Vorgabewerte für die Anpassung an die lokale Umgebung.

•  Inkrementeller Build, der erkennt, welche Artefakte schon erzeugt sind.

•  Parallelisierung von unabhängig ausführbaren Schritten des Workflows, um die Wartezeit so kurz wie möglich zu halten.

•  Zugriff auf alle Artefakte, die durch den Build erzeugt wurden.

•  Status-Reports, die den aktuellen Zustand des Builds zusammenfassen.

Gradle für Einsteiger

•  Wichtig: Selbermachen, nicht zuschauen

•  Installation

•  Grundlagen

•  Konfigurations- und Ausführungsphase

•  Kurzüberblick Groovy

•  Plug-ins - Grundlagen

•  Ein Projekt –  Verzeichnisstruktur –  Abhängigkeiten –  Manipulation der Jar-Datei –  Tests –  Qualitätssicherung

•  Veröffentlichung der Artefakte

build

assemble

testcompileTest

compile

Grundlagen von Gradle

•  Gradle verwendet Build-Skripte, die build.gradle heißen

•  Jedes Build-Skript ist ein Groovy-Skript

•  Zwei sehr wichtige Prinzipien

–  Convention over Configuration

–  Don’t Repeat Yourself

•  Gradle erzeugt ein dynamisches Modell des Workflows in Form eines DAG

•  Alles ist änderbar

Installation

•  Herunterladen von Java www.javasoft.com

•  Herunterladen von Gradle www.gradle.org

•  Optional Groovy groovy.codehaus.org

•  Installation unter Windows: Verzeichnis \Program Files\Gradle\gradle-1.8

•  Installation unter OS X: /Library/Gradle/gradle-1.8

•  Installation unter Linux: /usr/local/Gradle/gradle-1.8

•  Symbolischen Link setzen

•  Pfad setzen

•  Texteditor

•  Shell

•  Falls noch viele herunterladen müssen, dann über USB-Stick

Konfigurationsphase

•  Es wird das Gradle-Build-Skript ausgeführt

•  Die Groovy- und DSL-Befehle konfigurieren das Objektgeflecht

•  Das Projekt-Objekt ist die Wurzel des Geflechts

–  Wird direkt zur Verfügung gestellt

•  Erzeugen neuer Tasks, die ausgeführt werden können

•  Erstes Skript in der Datei build.gradle println "Hallo aus der Konfigurationsphase"

Ausführungsphase

•  Führt alle aufgerufenen Tasks aus (normalerweise Kommandozeile)

•  Vorher werden alle Tasks ausgeführt, von denen dieser abhängig ist

•  Hierfür wird der DAG ausgewertet, um die Abhängigkeiten zu bestimmen

Definition eines Tasks

•  Erhält eine Konfigurations-Closure (optional) als Argument, alternativ direkte Argumente

•  Mit << (left-shift) können Aktionen an die Liste der Aktionen angehängt werden

•  Äquivalent zu doLast()

•  Einfügen am Anfang der Liste mit doFirst() task halloTask halloTask.doLast { print "aus der " } halloTask << { println "Ausführungsphase" } halloTask.doFirst { print "Hallo " } task postHallo (dependsOn: halloTask) << { println “Ende” }

Kurzüberblick Groovy

•  Vereinfachte Java-Syntax

–  Semikolon optional

–  Gstring

–  Grundsätzliche Verwendung von Objekten

–  Abkürzungen wie “println”

•  Skripte

•  Operatorüberladung

–  Vorgegebene

•  Beispiel <<

•  Operator für sichere Navigation a.?b

–  Eigene möglich

•  Benannte Parameter

•  Closures

•  Collection-Iteratoren

Plug-ins - Grundlagen

•  Plug-ins kapseln Funktionalität

•  Können in beliebigen VM-Sprachen geschrieben sein

–  Gute Wahl ist Groovy

•  Möglichkeiten

–  Mitgelieferte Plug-ins

–  Plug-ins, die über URLs geladen werden (nicht zu empfehlen)

–  Plug-ins, die über Repositories geladen werden

–  Plug-ins, die selbst geschrieben sind (meist im Verzeichnis buildSrc)

•  Erweitern Objekte

•  Stellen neue Objekte zur Verfügung

•  Konfigurieren existierende Objekte

•  Werden geladen über den Befehl apply plugin apply plugin: ‘java’

Ein einfaches Projekt

•  Wir benutzen das Java-Plug-in

•  Default-Pfade des Java-Plug-ins (angelehnt an Maven)

Klasse HelloWorld

package de.gradleworkshop; import java.util.ArrayList; import java.util.List; public class HelloWorld {

public static void main(String[] args) { HelloWorld hw = new HelloWorld(); for(String greeting : hw.generateGreetingsData()) System.out.println(greeting); } public List<String> generateGreetingsData() { List <String> greetings = new ArrayList <String>(); greetings.add("Hallo Welt"); return greetings; }

}

Manipulation des Manifests

•  Jede Jar-Datei enthält eine Datei MANIFEST.MF (siehe build/tmp)

•  Diese kann verändert werden

•  Enthält unter anderem eine Startklasse für das Jar-Archiv jar { manifest { attributes 'Main-Class': 'de.gradleworkshop.HelloWorld' } }

•  Alternativ

jar.manifest.attributes 'Main-Class': 'de.gradleworkshop.HelloWorld'

Tests

•  Platzieren der Testklassen in das richtige Verzeichnis sorgt für automatisches Übersetzen

package de.gradleworkshop; import java.util.List; import org.junit.*; import static org.junit.Assert.*; public class HelloWorldTest {

HelloWorld oUT; @Before public void setUp() { oUT = new HelloWorld(); } @Test public void testGenerateGreetingsData() { List<String> res = oUT.generateGreetingsData(); assertEquals("result contains wrong number of results", 1, res.size()); }

}

Konfigurationen und Abhängigkeiten

•  Gradle bietet Konfigurationsobjekte

–  Bieten Abhängigkeitsinformationen

–  Pfade zu Quellen und zu Zielen

–  Zugehörige Artefakte

–  Weitere Konfigurationsinformationen

•  Tasks hängen von Konfigurationen ab

•  Beispiele

–  compile, testCompile, runtime, testRuntime

•  Abhängigkeiten werden über ein Schlüsselwort dependencies definiert

•  Maventypische Notation dependencies { testCompile group: 'junit', name: 'junit', version: '4.+’ }

Anbindung von Repositories

•  Repositories stellen die Jar-Archive zur Verfügung

•  Es lassen sich Ivy- und Maven-Repositories anbinden, öffentlich und privat

•  Spezielle Repositories

–  Maven Central

–  Lokales Maven Repository (~/.m2/repository)

•  Verwendund des Schlüsselworts repositories repositories { mavenLocal() } repositories { mavenCentral() }

•  Es können mehrere Repositories definiert werden

Weitere Plug-ins

•  Das Application-Plug-in

–  Erzeugt Start-Skripte, die mit dem Task run verwendet werden können

–  Ein Zip-Archiv mit dem Task distZip

–  Setzen der Hauptklasse über mainClassName = "de.gradleworkshop.HelloWorld"

–  Verwendung mit apply plugin: 'application'

Verwendung von TestNG

•  Sehr einfach

dependencies {

testCompile group: 'org.testng', name: 'testng', version: '6.+'

}

test {

useTestNG()

}

Testklasse für TestNG

package de.gradleworkshop; import java.util.List; import static org.junit.Assert.assertEquals; import static org.testng.AssertJUnit.*; import org.testng.annotations.*; public class TestHelloWorld {

HelloWorld oUT; @BeforeTest public void setUp() { oUT = new HelloWorld(); } @Test public void testGenerateGreetingsData() { List<String> res = oUT.generateGreetingsData(); assertEquals("Falsche Anzahl Einträge", 1, res.size()); }

}

Qualitätssicherung

•  Unterstützung für PMD, Checkstyle, Findbugs, Emma, Sonar

•  Beispiel für PMD apply plugin: 'pmd' pmdMain { ruleSets = [ "basic", "strings" ] ignoreFailures = true }

•  Weiteres Beispiel unter Verwendung von withType() tasks.withType(Pmd) { ruleSets = [ "basic", "strings" ] ignoreFailures = true ruleSetFiles = files('config/pmd/rulesets.xml') reports { xml.enabled false html.enabled true } }

Veröffentlichung der Artefakte

•  Gradle definiert für jede Konfiguration einen Task upload<Konfiguration>

–  Baut und veröffentlicht die zur Konfiguration gehörenden Artefakte

•  Das Java-Plug-in erzeugt eine Konfiguration archives, die sämtliche im Task jar erzeugten Artefakte enthält.

–  uploadArchives kann also für die Veröffentlichung verwendet werden

•  Verwendung des Maven-Plug-ins mit apply plugin: ‘maven’

–  Absichtlich keine Verwendung des “normalen” Repositories

apply plugin: ‘maven’ version = '0.1-SNAPSHOT’ group = 'de.gradleworkshop’ uploadArchives {

repositories { flatDir { dirs "repo" } mavenDeployer { repository (url : "file:///gradleWS/myRepo/") }

} }

Zusammenfassung

•  Wir haben Gradle programmiert und

–  Eine Applikation gebaut

–  Die Tests für die Applikation gemacht

–  Ein alternatives Test-Framework eingesetzt

–  Die Qualität gesichert

–  In ein lokales Repository hochgeladen

•  Damit können Sie jetzt normale Projekte problemlos mit Gradle bauen

•  Migration von anderen Build-Systemen zu Gradle ist einfach

•  Gradle

–  ist einfach

–  It leicht verständlich

–  hat vernünftige Vorgaben

–  kann leicht angepasst werden

Fragen?

Dr. Joachim Baumann

codecentric AG

An der Welle 4

60322 Frankfurt

Joachim.Baumann@codecentric.de

www.codecentric.de

blog.codecentric.de

27  Datum/ Fragen