Um Werkzeuge, die dem Entwickler beim Bauen seiner Software viel
Arbeit abnehmen, geht es in der siebenundneunzigsten Episode des
Anwendungsentwickler-Podcasts. TL;DR Mit einem Build-Werkzeug
automatisiere ich die Schritte, die aus Quellcode eine lauffähige
Software machen. Dazu gehören etwa das Laden benötigter
Bibliotheken und das Ausführen von Tests; auch das Deployment lässt
sich einbinden. Ein automatisierter Build spart dir manuelle
Arbeit, verringert Fehler und bildet die Grundlage für Continuous
Integration sowie die anschließenden Prozesse bis zum Continuous
Deployment. Dein Build-Skript gehört zusammen mit dem Quellcode in
die Versionsverwaltung. An Gradle zeige ich dir, wie sich solche
Abläufe durch Skripte erweitern lassen und wie der Wrapper die
passende Werkzeugversion für dein Projekt bereitstellt.
Kapitelmarken [00:00:00] Begrüßung und Einstieg in Build-Werkzeuge
[00:02:16] Was gehört zu einem Build? [00:03:34] Wie ein
Build-Werkzeug den Ablauf automatisiert [00:04:43] Zeit sparen und
Wissen im Team verteilen [00:06:05] Das Works-on-my-machine-Problem
[00:07:09] Automatisierte Builds als Grundlage für CI und
Deployment [00:07:47] Build-Skripte beschreiben und versionieren
[00:09:42] Aufgaben eines Build-Werkzeugs [00:10:21] Abhängigkeiten
auflösen und Bibliotheken bereitstellen [00:13:02] Code kompilieren
und Tests ausführen [00:14:27] Code-Coverage und statische
Code-Analyse [00:15:11] Pakete erzeugen und in Artifactory
veröffentlichen [00:16:33] Software automatisch deployen [00:17:00]
IDE-Projektdateien für den jeweiligen Rechner erzeugen [00:18:50]
CSS und JavaScript zusammenfassen und verkleinern [00:20:02] Code
durch Obfuscation verschleiern [00:21:11] Technische Dokumentation
erzeugen [00:21:52] Eigene Build-Schritte ergänzen und Werkzeuge
auswählen [00:23:30] Zusammenhang mit Continuous Integration
[00:24:16] Bekannte Build-Werkzeuge für verschiedene Plattformen
[00:27:00] Erfahrungen mit automatisierten Builds für Natural
[00:28:50] Werkzeug und Voraussetzungen im Ausbildungsbetrieb
klären [00:29:59] Projektkonventionen und vorhandene Vorlagen
[00:32:02] Das eigene Build-Skript verstehen [00:33:05] Erzeugte
Dateien aus der Versionsverwaltung ausschließen [00:34:23] Gradle
für Java und Android [00:35:01] Gradle-Skripte mit DSL und Groovy
erweitern [00:36:44] Laufzeit von Gradle-Builds [00:36:59] Die
passende Gradle-Version mit dem Wrapper starten [00:38:04] Erste
Befehle: build, clean und eclipse [00:39:23] Buch und weitere
Quellen zu Gradle [00:40:55] Fragen für Episode 100 [00:41:47]
Ausblick auf den Buchclub zu JUnit [00:42:24] Newsletter und
Verabschiedung Inhalt Die Episode ist wie meine Einführung in die
Versionsverwaltung mit Git in mehrere Fragen aufgeteilt. Los geht
es mit allgemeinen Fragen zu Build-Werkzeugen. Dann folgen Fragen
zum Einsatz im eigenen Unternehmen. Und zuletzt gehen auf die
Details von Gradle ein. Allgemein Die folgenden Fragen sind
unabhängig vom konkreten Build-Werkzeug. Was ist ein Build? Der
Vorgang, der alle Aktionen umfasst, die zum Erstellen einer
lauffähigen und deploybaren Software aus Basisartefakten wie
Sourcecode nötig sind. Was macht ein Build-Werkzeug? Mit einem
Build-Werkzeug können alle notwendigen Build-Schritte automatisiert
werden. Was sind die Vorteile eines Build-Werkzeugs? Die Software
kann automatisiert und damit schneller und verlässlicher gebaut
werden. Kopfmonopole werden abgebaut. "Works on my machine" wird
verhindert. Ein automatischer Build ist die Grundlage für
Continuous Integration/Delivery/Deployment. Was ist ein
Build-Script? In einem Build-Script werden die notwendigen
Build-Schritte definiert. Es wird vom Build-Werkzeug wie
Programmcode ausgeführt. Warum sollten Build-Scripts versioniert
werden? Letztlich sind die Build-Scripts ausführbarer "Code", der
ganz normal mit versioniert werden sollte. Allein, um Änderungen am
Build mit Änderungen im Code zu synchronisieren und später auch
noch frühere Builds nachstellen zu können. Welche Aktionen kann ein
Build-Werkzeug bei einem Build durchführen? Abhängigkeiten auflösen
(z.B. fremde JARs oder DLLs einbinden) Kompilieren des Codes Testen
(mit Analyse der Code Coverage) Statische Code-Analyse durchführen
(z.B. Code-Style, bestimmte Bugs) Paketieren der Anwendung (z.B.
als JAR, DLL) Snapshots der Software erzeugen und in ein
Artefakt-Repository einstellen Deployment der Anwendung auf ein
Zielsystem Maschinenunabhängig Projekte für die jeweilige IDE
erstellen Minification von Artefakten (z.B. CSS und JavaScript)
Obfuscation zum Schutz des Quellcodes Technische Dokumentation der
Software erzeugen Alles, was man sonst noch so manuell tun müsste
Wie hängt das Build-Werkzeug mit Continuous Integration zusammen?
Ohne automatischen Build ist kein CI möglich! Welche bekannten
Build-Werkzeuge gibt es für Java, .NET, Ruby und C? Java: Ant,
Maven, Gradle .NET: MSBuild Ruby: Rake C: make Dein Unternehmen
Diese Fragen solltest du dir stellen, wenn du in deinem Unternehmen
mit einem Build-Werkzeug arbeiten willst/musst. Welche konkreten
Build-Werkzeuge setzt dein Unternehmen ein? Was musst du tun, um
dieser auf deiner Maschine nutzen zu können? Welche Konventionen
musst du ggfs. einhalten, um sie in deinem Projekt nutzen zu
können? z.B. Ordnerstruktur des Projekts, Benennung der
Komponenten. Wo findest du Vorlagen für eigene Build-Scripts?
Welche Dateien gehören zum Build-Script deines Unternehmens und was
sind ihre jeweiligen Aufgaben? Welche Ordner und Dateien deines
Projekts solltest du von der Versionierung ausschließen? Gradle Zum
Schluss kommen noch ein paar einleitende Fragen zum konkreten
Werkzeug Gradle. Was ist Gradle? Ein Build-Werkzeug für Java, das
inzwischen z.B. der Standard für Android-Projekte ist. Was sind die
Vorteile von Gradle gegenüber Maven und Ant? Gradle verwendet eine
flexible und mächtige DSL für die Build-Scripts und kann sowohl
deklarativ, als auch imperativ verwendet werden. Was ist der Gradle
Wrapper? Eine Möglichkeit, um Gradle in der passenden Version für
das aktuelle Build-Script automatisch herunterzuladen und damit den
Build durchzuführen. Mit welchem Befehl startest du einen normalen
Build mit Gradle? gradle build Mit welchem Befehl räumst du dein
Projektverzeichnis mit Gradle auf? gradle clean Mit welchem Befehl
erzeugst du ein importierbares Eclipse-Projekt mit Gradle? gradle
eclipse Literaturempfehlungen Wenn du tiefer in Gradle einsteigen
möchtest (was natürlich nur sinnvoll ist, wenn du es selbst
einsetzt), empfehle ich dir dieses Buch von Joachim Baumann. Es hat
uns beim Erstellen einer Vorlage für unsere eigenen Build-Scripts
sehr geholfen. * Links Permalink zu dieser Podcast-Episode RSS-Feed
des Podcasts Erstellungsprozess – Wikipedia Java Quickstart -
Gradle User Guide Version 3.4.1 The Gradle build system- Tutorial
Zusammenfassung Vom Quellcode zur lauffähigen Software Wenn ich
eine neue Softwareversion bereitstelle, müssen aus dem Quellcode
und den weiteren Projektdateien lauffähige Artefakte entstehen.
Alle dafür erforderlichen Schritte gehören zum Build. Das Ergebnis
soll sich auf der vorgesehenen Umgebung bereitstellen lassen,
sodass Benutzer:innen damit arbeiten können. Ein Build-Werkzeug
führt diesen Ablauf automatisch aus. Du startest ihn beispielsweise
mit einem Kommandozeilenbefehl. Anschließend laufen die
hinterlegten Schritte bis zum fertigen Ergebnis durch, ohne dass du
zwischendurch manuell eingreifen musst. Warum sich ein
automatisierter Build lohnt Bei jedem Release Dateien von Hand zu
kopieren oder Konfigurationen anzupassen, kostet Zeit und eröffnet
Möglichkeiten für Fehler. Ein automatisierter Ablauf führt die
festgelegten Schritte verlässlich aus. Während längere Vorgänge
laufen, kannst du dich anderen Aufgaben widmen. Wenn jede:r
Entwickler:in den Build starten kann, verteilt sich außerdem das
Wissen darüber, wie die Software entsteht und bereitgestellt wird.
Der Betrieb hängt dadurch weniger von einzelnen Personen ab, die
sämtliche manuellen Schritte kennen. Ein weiteres Problem begegnet
dir unter dem Namen "Works on my machine": Auf deinem Rechner
funktioniert die Software, auf dem Rechner einer anderen Person
oder in der Zielumgebung scheitert sie. Ein Build-Werkzeug hilft
dabei, benötigte Bibliotheken bereitzustellen und Abhängigkeiten
von lokalen Pfaden zu vermeiden. Dadurch lässt sich das Projekt auf
unterschiedlichen Maschinen bauen. Für Continuous Integration muss
die Software automatisch gebaut werden können. Darauf bauen auch
Continuous Delivery und Continuous Deployment auf, bei denen
weitere Schritte bis zum Bereitstellen der Software automatisiert
werden. Was ein Build-Werkzeug übernehmen kann Je nach Projekt
umfasst der Ablauf unterschiedliche Aufgaben: Abhängigkeiten
auflösen: Im Build-Skript legst du fest, welche Bibliotheken dein
Projekt in welcher Version benötigt. Das Werkzeug lädt fehlende
Pakete beispielsweise aus Maven Central oder über NuGet herunter
und stellt sie für den Build bereit. Umfangreiche Abhängigkeiten
und Konflikte zwischen Versionen können sonst viel manuelle Arbeit
verursachen, die als "Dependency Hell" bezeichnet wird. Code
kompilieren: Das Werkzeug ruft den passenden Compiler auf und
berücksichtigt die benötigten Bibliotheken. Es muss die Sprache und
Plattform deines Projekts unterstützen. Tests ausführen: Nach dem
Kompilieren können automatische Tests prüfen, ob sich die Software
wie erwartet verhält. Eine Code-Coverage-Analyse zeigt dabei,
welche Teile des Codes durch die Tests ausgeführt werden. Code
statisch analysieren: Zusätzliche Werkzeuge prüfen beispielsweise,
ob der Quellcode den vereinbarten Styleguides entspricht oder
Hinweise auf Fehler enthält. Die Ergebnisse lassen sich bei jedem
Build aufbereiten. Pakete erzeugen: Aus den Projektdaten entstehen
Artefakte wie eine JAR-Datei bei Java oder ein Gem bei Ruby.
Artefakte veröffentlichen: Das fertige Paket kann automatisch in
ein Artefakt
Kommentare (0)
Melde dich an, um einen Kommentar zu schreiben.