© saicle/Shutterstock.com
Teil 2: Konfiguration der Toolchain

Der Blick in den Werkzeugkasten


Nachdem im ersten Teil dieser Serie sowohl auf die Grundlagen eingegangen als auch der Aufbau der geplanten Toolchain vorgestellt wurde, wird in diesem Teil dargestellt, wie man nun alle Werkzeuge zusammenbringt und beginnt, das exemplarische Projekt zu entwickeln.

Artikelserie

Teil 1: Aufbau einer exemplarischen Toolchain

Teil 2: Konfiguration der Toolchain

Teil 3: Der komplette Deployment-Prozess

Im ersten Teil haben wir in JIRA die Anforderungen in einem kleinen beispielhaften Pflichtenheft niedergeschrieben und die geplanten Stories angelegt. Ein Repository wurde im Stash zur Sourcecodeversionierung angelegt und der initiale Commit mithilfe der README.MD-Datei durchgeführt. Im gleichen Schritt wurde auch der GIT-Flow-Prozess auf das Repository übertragen und initialisiert. Als organisatorische Vorgehensweise wurde die agile Entwicklungsmethode Scrum gewählt, die mithilfe von testgetriebener Softwareentwicklung umgesetzt werden soll.

In diesem Artikel werden der Jenkins-Deployment-Server eingerichtet und die ersten Komponenten der Entwicklungsumgebung erläutert. Bei der Einrichtung der Komponenten wird eine kurze theoretische Einführung in die jeweilige Komponente geboten; abgerundet wird dies mit deren praktischer Integration anhand des Beispiels einer Webapplikation.

TDD – Test-driven Development

Neben der Einrichtung der Softwarekomponenten soll dieses Projekt mithilfe von TDD (Test-driven Development) umgesetzt werden. Bei dieser Methode beginnt man schon vor der Entwicklung der Funktionalitäten mit der Planung, welche Funktionalitäten die jeweiligen Objekte tatsächlich bereitstellen müssen, damit die Applikation die gewünschten Features zur Verfügung stellt. Nachdem die Tests erstellt wurden, wird die Software entwickelt, bis die erstellten Softwaretests erfolgreich sind. Danach nimmt man noch so genannte Refactorings vor, um auch den Standards einer guten Softwareentwicklung zu folgen. Sehr gute Definitionen für qualitativ hochwertige Software findet man in den Clean-Code-Developer-Richtlinien [1].

Einen großen Vorteil der testgetriebenen Entwicklung sehe ich darin, dass man hier einen Whitebox-Test entwickelt, ohne dass man als Entwickler schon den gegebenen Quellcode kennt. Stattdessen entwickelt man den Test auf eine gedachte Funktionalität hin. Ein weiterer positiver Aspekt, der bei der Benutzung dieser Methodik entsteht, ist auch, dass in der Regel kein unnötiger Programmcode erzeugt wird, da die Klassen nur soweit ausprogrammiert werden, ...

Neugierig geworden?

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang