Maven, Git, Jenkins - Source Talk Tage 2006
Werbung
Sourcetalktage 2012 Referent: Tobias Heisecke ( [email protected] ) - seit 1995 bei der ZAD-GmbH in Northeim ( Dienstleistungsrechenzentrum im Gesundheitswesen ) - Forderungseinzug für Krankentransport- und Rettungsdienste sowie Ambulante Pflegedienste - seit 17 Jahren Entwickler und Unix-Linux-Administrator - Wir suchen Entwickler Den Entwicklungsprozess im Griff mit Maven, Jenkins und Git Überblick Tagesablauf ● ● 10:00-11:00 Uhr Vorstellungsrunde / Rechnercheck ( Netzwerkverbindungen etc.. Internet.. ) 11:00-12:30 Uhr Theoretischer Teil: Was soll heute erreicht werden und warum ○ Anforderungen an Projekte / Wozu benötige ich Maven ○ Maven ist .. ○ Glossar / Begriffe ○ Versionierung und weitere Regeln ○ Wie bekomme ich Maven ○ Neues Maven Projekt ○ Projektbeschreibung in der .pom - Datei ○ Maven Lifecycle ( Phasen, Plugins, Goals etc. ) ○ Maven Repository Manager - Nexus ○ Git ( Versionsverwaltung ) ○ Jenkins Integrationsserver ● 12-17 Uhr Praktischer Teil ○ Installation der einzelnen Server ( JBoss, Jenkins, Nexus, Git-Daemon ) und Einrichten der Projektumgebung, Aufsetzen eines Vaadin Beispielwebprojektes Rechnercheck 1. 2. Namensschilder / Vorstellungsrunde Rechnercheck / Fragen ○ Internet auf dem Notebook? ○ Internet in der openSuSE? ○ Firewall aus? ○ ssh aktiviert? ○ Daten kopieren möglich, zwischen Wirt und Gast? ... gegenseitiges Helfen erlaubt!! Anforderungen an Projekte - Anforderungen: Die neue Anwendung sollte ... - Webanwendung ( ohne Plugins ) - performant - sicher sein - getestet sein - automatisch gebaut werden - zeitgesteuert Dinge tun - drucken können - faxen können - mailen - usw ........ daraus resultieren eine Menge Abhängigkeiten an Fremdbibliotheken Abhängigkeiten zu Fremdbibliotheken Vaadin und Vaadin Addons JBOSS / JEE-Libs ( JPA, Hibernate ... ) Arquillian gnu-hylafax GWT Guava JRebel Jasper ( Drucken ) Wozu benötige ich Maven - Teamarbeit ● ● ● ● ● Integrationshölle vermeiden Plattformunabhängig: Das Maven-Eclipseplugin erzeugt die nötigen plattformabhängigen Projekt-Dateien ( .classpath, .project, .settings ) aus einer .pom-XML-Datei und benutzt plattformabhängige Variablen aus einer settings-XML-Datei um das Projekt zu steuern IDE-Unabhängigkeit ( Abhängigkeiten werden in .pom-Datei deklariert ) Versionsnummern der Pakete: Alle Entwickler arbeiten automatisch mit den gleichen Versionen der Fremd-Bibliotheken Abhängigkeiten: Es erleichtert die Verwaltung von Abhängigkeiten ( Dependencies ) und deren transitiven Abhängigkeiten Wozu benötige ich Maven ● ● ● Archivierung der Pakete: Es soll immer auf jeden Entwicklungstand zurückgegangen werden können, bedeutet, wenn das Projekt damals mit Vaadin 6.0.0, und der eigenen AddressBook Version 1.0.1 gebaut worden ist, muss genau dieser Stand nochmal baubar sein Schnelle Einarbeitung: Neue Entwickler sollen sich schnell einarbeiten können und nicht Tage benötigen, um ihre Entwicklungsumgebung einzustellen Automatisches herunterladen der Pakete: Benötigte Libraries sollen automatisch geladen werden Maven ist ... Zitat Wikipedia: Maven ist ein Build-Management-Tool der Apache Software Foundation und basiert auf Java. Mit ihm kann man insbesondere Java-Programme standardisiert erstellen und verwalten. Eigene Darstellung: Maven übernimmt für mich in Kombination mit weiteren Tools: dependency Management, autom. Build, autom. Testen, autom. packaging, autom. Deploy, autom. Erzeugung der Projektdokumentation Maven Glossar ● Artefakt / Artifakt: jar, war, ear etc. ... Projekt ● Maven Koordinaten: der Projektpfad, bestehend aus GroupId = de.mycompany.addresbook ArtifactId= AddressBook Version = Siehe Versionierung ( z. B. 1.0.1 ) PackagingTyp = jar, war, ear, pom ( Reaktorprojekt ) Classifier = für manche Pakete gibt es noch Classifier wie z. B.: -sources, javadoc oder jdk1.4, -jdk1.5 Maven Versionierung Versionierung für Snapshots ( Entwicklerversionen ): ● automatisch vergebene Versionierung mittels Zeitstempel und Buildnummer ● bei jedem build wird im Repository geprüft, ob eine neuere Version vorliegt und gegebenenfalls ins lokale Repo kopiert ● AddressBook-<Nummerierung Zielversion>-SNAPSHOT, die nächste angestrebte Release-Nummer Versionierung für Release ( major.minor.revision.classifier ) ● major = komplett Überarbeitet worden ( neue Feautures ), keine Abwärtskompatibilität gegeben ● minor = evtl. auch neue Features aber keine grundlegenden Änderungen Abwärtskompatibilität muss nicht gewährleistest sein ● revision = bugfixes, kleinere Anpassungen, Abwärtskompatibel ● classifier = alpha/beta ( frühe Vorabversionen / Testversionen ) sources / javadoc Maven Regeln Projektdateien ( Eingabe ) sollten in folgenden Pfaden liegen: src/main/java src/main/resources src/main/filters src/main/webapp = Projekt-Klassen = andere Textfiles, Bilder, etc... = text-ersetzen beim bauen = html-files, deployment descriptor, etc.. src/test/java src/test/resources src/test/filters = Projekt-Testklassen = andere Textfiles, Bilder, etc... = text-ersetzen beim bauen http://maven.apache.org/guides/introduction/introduction-to-the-standarddirectory-layout.html Maven Regeln Ausgabedateien werden in folgenden Pfaden abgelegt: Ausgabe unter = target/classes = target/apidocs = target/myproject.war ( exploded ) = target/myproject.war ( package ) Wie bekomme ich Maven ● ● ● ● ● Eclipse Plugin: Das Plugin heißt m2e ( Maven 2 Eclipse .. auch für Maven 3 ) und ist im Eclipse Indigo-Repository enthalten. Galileo und älter: http://m2eclipse.sonatype.org/sites/m2e Das eclipse-plugin wurde von der Firma Sonatype initiiert und später an die Eclipse Foundation abgegeben Vorsicht: m2e ist auch in den JBoss-Tools enthalten Unter Linux: maven-bootstrap ( 3.0.4 ) installieren für shell Wie bekomme ich Maven Wie bekomme ich Maven Neues Maven Projekt "File --> New Maven Project" Maven Multimodul-Projekt Projektbeschreibung in der .pom-XML-Datei ( Aufbau ) externes Bild ... reaktor-projekt-pom-aufbau.graphml Multimodul Kettenreaktion externes Bild ... mvn-reaktor-kette.graphml build-Ablauf starten... doch was verbirgt sich dahinter ... Maven Lifecycle Lifecycle bestehen aus mehreren Phasen, die den Lifecycle ausmachen. Folgende Lifecycle gibt es: default = build ( Bauen der Anwendung ) clean = Säubern des workspaces site = erzeugen der Dokumentation ( website ) Lifecyle können nicht direkt aufgerufen werden, sie dienen nur als Gruppierung. Maven Lifecycle: Phasen Der default- bzw. build-Lifecyle besteht aus folgenden Phasen: ● ● ● ● ● ● ● ● ● ● ● validate - Vorprüfung des Projektes, ob alle nötigen Informationen vorhanden sind process resources - Filtern der Resources-Dateien compile - Kompilieren des Projektquellcodes ( .java zu .class Bytecode ) process test-resources - Filtern der Test-Resources-Dateien test-compile - Kompilieren der Testklassen ( .java zu .class Bytecode ) test - Testen des komplilierten Codes. package - Einpacken des kompilierten Code in z. B. ein jar, war integration-test - deploy des Projekts auf einen Integrationsserver, auf dem die Tests laufen können verify - Prüfen, ob das Paket ordnungsgemäß erzeugt wurde install - Installieren des Pakets in das lokale .m2-Repository zur Benutzung in anderen lokalen Projekten deploy - kopieren des fertigen Paketes in ein entferntes Repository (nexus-Maven RepositoryManager ) Noch mehr Lifecycle-Phasen unter: http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html#Lifecycle_Reference Maven Lifecycle: Plugins Auf jede dieser Phasen kann man Plugins anwenden, die in der jew. Phase etwas ausführen: ● maven-compiler-plugin ( compile .java --> .class ) ● maven-site-plugin ( erzeuge Projekt-Webseite ) ● maven-release-plugin ( Veröffentliche Software ) ● maven-javadoc-plugin ( Erzeugen der javadoc, Phase: package ) ● maven-source-plugin ( Einpacken des Quellcode, Phase: package ) ● maven-surefire-plugin ( Testen des Codes JUnit ) ● maven-failsafe-plugin ( Ausführung von Integrationstests ) ● projektspezifisch: gwt-maven-plugin, vaadin-maven-plugin und jboss-asmaven-plugin, ansonsten maven-war-plugin Noch mehr Plugins unter: http://maven.apache.org/plugins/index.html Maven Lifecycle: Goals Jedes dieser Plugins hat Goals ( Ein Befehl, der eine bestimmte Funktionalität des Plugins ausführt ) Aufruf: mvn plugin:befehl Standard-Goals sind zum Beispiel: ● mvn install:install → Baue die Anwendung, packe sie in ein Archiv und installiere es im lok. . m2-Repository-Ordner ● mvn deploy → alle Phasen werden bis mvn install durchlaufen, und anschließend in entferntes Maven Repository kopiert ● mvn release:prepare → Release vorbereiten ( -SNAPSHOT entfernen in allen .pom Dateien und einchecken in Versionsverwaltung ) ● mvn release:perform → Release durchführen ● mvn release:rollback → Release zurücksetzen ● mvn clean → Projekt-Workspace aufräumen Maven Lifecycle: Weitere Goals Weitere Goals: Testen: mvn test Hilfe: mvn help sehr ergiebig: ● ● ● ● ● ● mvn mvn mvn mvn mvn mvn help active-profiles help all-profiles help effective-pom help effective-settings help system help:describe -Dcmd=package Maven Lifecycle: Weitere Goals Weitere Goals: Website erstellen ( Achtung nur plugins ab 3er Version für Maven 3 ): mvn site:site → erzeugt Dokumentation in Paket-Ordnerstruktur. Achtung erst mvn install mvn site:stage → notwendig für Multimodulprojekte mvn site:deploy → erzeugt Dokumentation in Paket-Ordnerstruktur und kopiert diese in den im Repository-Tag angegebenen Server Javadoc erstellen: mvn javadoc:javadoc → erzeugt Javadoc-Dokumentation Maven Lifecycle: Weitere Goals Weitere Goals: Dependencys managen ( aufräumen, neu holen, etc.. ): mvn dependency:list → Abhängigkeiten auflisten mvn dependency:resolve → Löst alle Abhängigkeiten auf und lädt sie ins lokale Repositorie mvn dependency:purge-local-repository → alle abhängigkeiten löschen und nochmal neu laden mvn dependency:go-offline → lädt alles herunter incl. Build und reporting-Plugins mvn dependency:sources → lädt die source-Pakete zu den Abhängigkeiten mvn dependency:tree → zeigt den Abhängigkeitsbaum Maven Lifecycle: Überblick externe Grafik ... maven-lifecycle.graphml Maven Dependency Scopes Wann werden die Abhängigkeiten benötigt? Dependency scopes dienen dazu, die transitiven Abhängigkeiten zu begrenzen und sind mit den Lifecyclephasen fest verdrahtet Es gibt 6 unterschiedliche Scopes: ● compile ( default scope .. wird auch verwendet, wenn kein Scope angegeben ist. Compile dependencies sind in allen Klassenpfaden eines projekts enthalten ) ● provided (Bibliotheken, die schon im Application-Server enthalten sind ( z. B. Servlet-Api ) und die nur zur Compilezeit und für Tests zur verfügung gestellt werden müssen. ) ● runtime ( Wird nicht für die übersetzung des Codes benötigt, sondern nur zur Laufzeit. ) ● test ( Ausschließlich für die Phasen test und test-compile ) ● system ( Müssen durch variable systemPath auf der jew. Maschine bereitgestellt werden / aus dem lok. Dateisystem ) ● import ( kann nur in dependencyManagement verwendet werden und importiert den dependencyManagement Abschnitt aus der importierten POM und fügt es dem aktuellen Projekt hinzu. ) Maven Repository Manager Maven-Repository-Manager ● beinhaltet Artifakte ● bekannte Maven Repository Manager: ○ Nexus ( Sonatype ), ○ Artifactory, ○ Apache Archiva Feature Matrix: http://docs.codehaus.org/display/MAVENUSER/Maven+Repository+Manager+Feature+Matrix Was hat die Versionsverwaltung damit zu tun? ● ● Die .pom-Dateien werden in die Versionsverwaltung mit eingecheckt und sorgen dafür, das bei Wiederherstellung alter Stände, alles wieder sauber gebaut werden kann. Der Integrationsserver checkt den Quellcode aus der Versionsverwaltung aus und baut ihn komplett neu Integrationsserver Jenkins ● ● ● ● ● Checkt aus der Versionsverwaltung ( Git ) aus Analysiert die Maven-Reaktor-POM Lädt die Dependencies herunter Testet das Projekt komplett durch Und deployed bei Erfolg anschließend in die Betriebsumgebung, in unserem Fall auf einen laufenden JBoss Entwickler Überblick externes Grafik ... maven-all.graphml Ende theoretischer Teil Vielen Dank für Ihre Aufmerksamkeit! [email protected] Praktischer Teil
