agile coding

Viele sehen bei Continious Integration nur eines dieser Buzzwords mit denen man in der IT überall konfrontiert wird. Wenn man aber mal ein wenig genauer hinsieht und etwas recherchiert, findet man schnell Firmen die einem ihre Produkte anpreisen und immer wieder Verweise auf die Continous Integration Server Jenkins und Hudson. Hier und da wird mal ein wenig erklärt was man unter Kontinuierlicher Softwareentwicklung eigentlich versteht und wieder….soll man dazu ein Produkt am besten Kaufen.

Aus meiner Erfahrung habe ich unterschiedliche Ansätze und auch Produkte im Bereich Continous Integration kennengelernt und kann für mich klar feststellen, dass der Prozess wichtiger ist, als die Werkzeuge, die man nutzt um den Prozess letztendlich umzusetzen. Wenn jeder im Team das gleiche Verständnis für die Abfolgen hat, gibt es weniger Abstimmungspotenzial und damit schlicht weg weniger „Reibungspunkte“. Wenn man obendrauf Werkzeuge nutzt, um Arbeitsschritte zu automatisieren, hat man einen klaren Vorteil für sich nutzbar gemacht und sicherlich einen Mehrwert für das Unternehmen generiert.

Kontinuierliche Softwareentwicklung ist kein Thema was ausschließlich die Entwickler betrifft. Alle Beteiligten wie z.B. Softwaretester, Projektmanager und sogar der Kunde ist können davon betroffen sein. Unternehmen die sich mit agilen Projektmethoden beschäftigen, sollten das Thema nicht an sich vorbei ziehen lassen. Ein klarer Prozess kann allen Projektbeteiligten helfen um sich auf ihre Arbeit zu konzentrieren und weniger darum kümmern was jetzt wo installiert ist und kann man das dem Kunden überhaupt so präsentieren.

In dieser Reihe von Artikeln möchte ich einen Continous Integration Prozess aufzeigen, der Scrum als Methode für die Softwareentwicklung nutzt. Es werden ausschließlich Open Source Software Werkzeuge benannt, mit denen der Prozess umgesetzt wird. Ich bitte hierbei nicht zu vergessen, dass jedes Unternehmen unterschiedlich ist, jede Entwicklungssprache andere Umgebungen und Werkzeuge erfordert. Dieser Prozess ist keine Blaupause, die man nimmt und übermorgen im Unternehmen einführt. Es ist eine Anregung um den Prozess und damit verbundene Werkzeuge zu begreifen und für sich zu bewerten. Jeder Continous Integration Prozess muss von Menschen schlussendlich gelebt werden und muss daher speziell auf die vorhandene Situation im Unternehmen angepasst werden!

Schaffen wir uns im ersten Schritt einen groben Überblick über den gesamten Prozess und gehen anschließend in die Details:

Projektvorhaben entstehen in den meisten Fällen beim Kunden, Stakeholdern oder dem Product Owner. In dieser schematischen Darstellung bringt der Product Owner die Anforderungen für das Softwareprodukt in das Product Backlog ein. Der Entwickler übernimmt, im Rahmen eines Sprints, die User Story und setzt diese in einer Lokalen Entwicklungsumgebung (IDE) um. Die Ausstattung einer Lokalen Entwicklungsumgebung hängt im Regelfall stark von der genutzten Programmiersprache und der Betriebssystemplattform ab. Hier mal eine kleine Liste für die möglichen Open Source IDE Systeme, zugeordnet zur jeweiligen Programmiersprachen:

Damit das Ergebnis eine Entwicklers nicht auf einem Lokalen System „versauert“, checkt der Entwickler das Artefakt in ein Code Verwaltungssystem (Subversion, Git, Cvc, etc.) ein. Im Falle, dass eines der vorgenannten IDE´s verwendet, haben die meisten IDE´s eine integrierte Anbindung an ein Code Verwaltungssystem. Falls das nicht der Fall ist, kann man auf einen vielen Externen Client Programme zurückgreifen. Hierfür habe ich ebenfalls eine schmale Liste der Client Programme und dem zugehörigen Code Verwaltungssystem aufgestellt:

Es gibt noch weitere Open Source Code Verwaltungssystem, die vorstehenden Listen erheben nicht den Anspruch vollständig zu sein!

Gehen wird davon aus, dass sich nun die Artefakte in einem Code Verwaltungssystem befinden. Die Arbeit des Entwicklers an den bearbeiteten User Stories ist aber noch nicht beendet. Nun muss er noch den Status der bearbeiteten User Stories im Product (oder Sprint) Backlog aktualisieren. Bei einigen Product Backlog Systemen besteht die Möglichkeit die Informationen aus dem Code Verwaltungssystem und dem Jenkins Server an der betreffenden User Story zusammenzuführen. Somit erhält man über innerhalb des Product Backlog System zusätzlich die Information ob eine User Story eingecheckt und auf einem Testserver bereitgesellt wurde. Hierdurch erhält der nachgelagerte Qualitätssicher die Information welche User Stories zum Testen überhaupt freigegeben sind.

Die Bereitstellung der Softwareversion erledigt in diesem Continous Integration Prozess der Jenkins Server. In vielen Fällen wird der Jenkins Server primär verwendet, um eine eingecheckte Softwareversion auf einem Testsystem den Qualitätssicheren zur Verfügung zu stellen. Auf den zweiten Blick könnte der Jenkins Server noch viel mehr Funktionen übernehmen, wie z.B. automatisierte Softwaretests. Hierfür muss der Entwickler oder der Qualitätssicherer entsprechende Tests schreiben und ebenfalls innerhalb des Jenkins einrichten. Hierzu aber in einem anderen Artikel mehr Informationen. Im Grunde geht es bei der jetzt um die Bereitstellung auf einem Internen Testsystem. Hierzu muss man natürlich ein Internes Testsystem einrichten und einen Deployment Job innerhalb des Jenkins Servers anlegen.

Wenn das Deployment durch den Jenkins Server erfolgreich durchgeführt wurde, muss der Qualitätssicherer die Information erhalten welche Stories zum Testen freigegeben wurde, hierfür dient im Regelfall das Daily im Scrum oder ein Blick in das Product Backlog System. Der Qualitätssicher führt seine Tests aus und dokumentiert wiederum die Testergebnisse im Product (oder Sprint) Backlog. Jenach Testergebnis werden einige User Stories an den Entwickler zurückgegeben oder als erledigt markiert.

Und somit schliesst sich der Kreis wieder und das Spiel kann von vorne beginnen.