© Excellent backgrounds/Shutterstock.com
Java Magazin
Mit Puppet und RPM

Mit Puppet und RPM

„It works on my machine“ hat sicher jeder schon einmal gehört. In der Entwicklung verhält sich die Software wie erwartet. Bis diese in der Produktion ist, dauert es lange. Einmal live, treten dann unerwartete Fehler auf, während die Softwareentwicklung längst an einer ganz anderen Stelle ist. Wie kann dieser Spagat umgangen werden? Dieser Artikel reflektiert, wie wir mit diesem Problem auf Basis einer paketorientierten Deployment Pipeline umgehen.

André von Deetzen, Oliver Wehrens


Im Juli 2012 standen wir vor der Herausforderung, ein neues Produkt zu entwickeln. Da die Entwicklung nach einem agilen iterativen Vorgehensmodell stattfindet, wollten wir das Produkt auch nach Abschluss einer oder weniger User-Storys regelmäßig unseren Kunden zur Verfügung stellen können. Unsere Plattform ist zwar bereits modularisiert, wird jedoch nur im Verbund getestet und ausgerollt. Die Auslieferungszeit von vier bis sechs Wochen war uns jedoch nicht schnell genug. Daher mussten wir das Verfahren für unser Produkt anpassen. Eine weitere Herausforderung war der gleichzeitige Umbau auf ein geändertes Paradigma in unserer Softwarearchitektur. Wir wollen unsere Architektur auf einen Micro-Service-basierten Ansatz umstellen. Dazu werden Funktionalitäten in fachliche Säulen aufgeteilt. Jeder dieser Säulen wird in der Produktion ein Servertyp zugewiesen, sodass auf jedem Server genau ein Service für die Plattform bereitgestellt wird. Um bei Bedarf diese Micro Services zu aktualisieren und einen gefundenen Fehler zu korrigieren, benötigen wir auch für jeden Dienst eine eigene unabhängige Deployment Pipeline. Da einer unserer Architekturgrundsätze die Pflege von abwärtskompatiblen Schnittstellen ist, können wir unsere Dienste jederzeit aktualisieren.

Softwarestack

Unser Produkt basiert auf einer in Java geschriebenen Webanwendung. Als Frameworks nutzen wir Spring [1] und Jersey [2]. Da wir jedoch auch Produkte haben, die auf Grails-Basis entwickelt werden, sollen die Komponenten unseres Ansatzes jedoch untereinander kompatibel sein. Betrieben werden die Applikationen unter Linux in einem Apache Tomcat 7. Da wir in der Produktion und in der Entwicklung jeweils die gleiche Linux-Distribution einsetzen und diese auch nicht so schnell ändern, haben wir uns dazu entschlossen, die spezifischen Aspekte unserer Linux-Distribution zu nutzen. Wir nutzen das gleiche Paketformat und halten uns an die Konventionen, wie z. B. Init-Skripte für den Start unserer Anwendung. Aus Sicht der Linux-Distribution sollen sich unsere Anwendungen genauso einfügen wie z. B. ein SSH- oder HTTPD-Dienst. Durch diese Entscheidung können wir auf alle bereits implementierten Funktionen unseres Konfigurationsmanagementwerkzeugs zurückgreifen. Es besteht keine Notwendigkeit, eine angepasste Implementierung für die Installation oder die Verwaltung von Diensten bereitzustellen.

Deployment Pipeline

Im Vorfeld haben wir uns überlegt, welche Stages wir für die Auslieferung unserer Software benötigen...

Java Magazin
Mit Puppet und RPM

Mit Puppet und RPM

„It works on my machine“ hat sicher jeder schon einmal gehört. In der Entwicklung verhält sich die Software wie erwartet. Bis diese in der Produktion ist, dauert es lange. Einmal live, treten dann unerwartete Fehler auf, während die Softwareentwicklung längst an einer ganz anderen Stelle ist. Wie kann dieser Spagat umgangen werden? Dieser Artikel reflektiert, wie wir mit diesem Problem auf Basis einer paketorientierten Deployment Pipeline umgehen.

André von Deetzen, Oliver Wehrens


Im Juli 2012 standen wir vor der Herausforderung, ein neues Produkt zu entwickeln. Da die Entwicklung nach einem agilen iterativen Vorgehensmodell stattfindet, wollten wir das Produkt auch nach Abschluss einer oder weniger User-Storys regelmäßig unseren Kunden zur Verfügung stellen können. Unsere Plattform ist zwar bereits modularisiert, wird jedoch nur im Verbund getestet und ausgerollt. Die Auslieferungszeit von vier bis sechs Wochen war uns jedoch nicht schnell genug. Daher mussten wir das Verfahren für unser Produkt anpassen. Eine weitere Herausforderung war der gleichzeitige Umbau auf ein geändertes Paradigma in unserer Softwarearchitektur. Wir wollen unsere Architektur auf einen Micro-Service-basierten Ansatz umstellen. Dazu werden Funktionalitäten in fachliche Säulen aufgeteilt. Jeder dieser Säulen wird in der Produktion ein Servertyp zugewiesen, sodass auf jedem Server genau ein Service für die Plattform bereitgestellt wird. Um bei Bedarf diese Micro Services zu aktualisieren und einen gefundenen Fehler zu korrigieren, benötigen wir auch für jeden Dienst eine eigene unabhängige Deployment Pipeline. Da einer unserer Architekturgrundsätze die Pflege von abwärtskompatiblen Schnittstellen ist, können wir unsere Dienste jederzeit aktualisieren.

Softwarestack

Unser Produkt basiert auf einer in Java geschriebenen Webanwendung. Als Frameworks nutzen wir Spring [1] und Jersey [2]. Da wir jedoch auch Produkte haben, die auf Grails-Basis entwickelt werden, sollen die Komponenten unseres Ansatzes jedoch untereinander kompatibel sein. Betrieben werden die Applikationen unter Linux in einem Apache Tomcat 7. Da wir in der Produktion und in der Entwicklung jeweils die gleiche Linux-Distribution einsetzen und diese auch nicht so schnell ändern, haben wir uns dazu entschlossen, die spezifischen Aspekte unserer Linux-Distribution zu nutzen. Wir nutzen das gleiche Paketformat und halten uns an die Konventionen, wie z. B. Init-Skripte für den Start unserer Anwendung. Aus Sicht der Linux-Distribution sollen sich unsere Anwendungen genauso einfügen wie z. B. ein SSH- oder HTTPD-Dienst. Durch diese Entscheidung können wir auf alle bereits implementierten Funktionen unseres Konfigurationsmanagementwerkzeugs zurückgreifen. Es besteht keine Notwendigkeit, eine angepasste Implementierung für die Installation oder die Verwaltung von Diensten bereitzustellen.

Deployment Pipeline

Im Vorfeld haben wir uns überlegt, welche Stages wir für die Auslieferung unserer Software benötigen...

Neugierig geworden?


   
Loading...

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