Automatisierter Build und Deployment III

Um automatisch den letzten Stand auf dem Trunk und Release zu bauen und zu deployen verwende ich ein Shell Script, dass auf einer Linux Maschine mit Hilfe von crontab automatisiert wird. Ich richte auf der Linux Maschine jeweils ein User pro Projekt ein, somit ist es einfacher die Projekte sauber voneinander zu trennen.

Beispiel crontab:
[myproject@linux ~]$ crontab -l
45 5,12 * * * /home/myproject/build.sh all

Wenn man es noch ganz schön machen möchte, dann man mit maven eine Site generieren lassen, die man dann auf dem www-Root ablegt. Diese Site liefert dann Informationen zum Projekt, dem Team und der Source-Code Anbindung.

Automatisierter Build und Deployment II

Um auf einem Apache und einem Tomcat den trunk, release und tag parallel laufen lassen zu können, empfielt es sicht, mit viruellen Host zu arbeiten. Dafür sollte man den Apache per DNS auf die Staging Maschine zeigen lassen, z.B.

nslookup staging.myproject.company.com

Server:  dns.company.home

Address:  192.168.1.12

Non-authoritative answer:

Name:    linux.company.com

Address:  192.168.1.2

Aliases:  staging.myproject.company.com

Im Apache werden dann 3 virtuelle Hosts definiert: trunk, release und tag, z.B.:

VirtualHost  trunk.myproject.company.com:80 trunk.myproject.company.com:443>

 ServerAlias trunk.myproject.company.com

 ServerName trunk.myproject.company.com

 ServerAdmin sysadmin@company.com

 DocumentRoot /var/www/myproject/trunk

 ...

>

Analog wird das gleiche noch für release und tag definiert.

Der Tomcat bekommt pro Entwicklungsstand einen eigenen CATALINA_HOME. Dort wird die jeweilige Version deployed, z.B. das WAR file für Release 3.

Per Apache Rewrite Regeln kann man Requests auf ein einen Applikationskontext vom Apache an den Tomcat weiterleiten. 

Fertig! Jetzt kann man auf der gleichen Maschine drei unterschiedliche Entwicklungsstände zeigen. 

Im kommenden Post beschreibe ich, wie man das automatisiseren kann.

Automatisierter Build und Deployment

Bei agiler Vorgehensweise ist es sehr wichtig, dass sowohl der Kunde als auch das Team immer eine lauffähige Version der Software in einer dedizierten Umgebung einsehen kann, wobei ich mich hier auf Web Applikationen beziehe. Oft kommt noch hinzu, dass man nicht nur den aktuellen Entwicklungsstand, sondern auch den aktuellen und manchmal parallel auch den vorherigen Release plus Tag Version einsehen möchte. 

Wie macht man das?

Es gibt Tools, die einen unterstützten, z.B. Buildix - was allerdings gleich mit dem gesamten Projektmanagement auffährt. Neben Buildix gibt es noch andere Tools, auf die ich hier nicht weiter eingehen möchte.

Es geht auch ohne Tools ganz einfach. Ich bevorzuge für die Staging Umgebung eine Linux Maschine, z.B. CentOS. Hier werden folgende Infrastruktur Tools installiert:

- subversion/cvs client

- maven/ant

Um den Build das Deployment zu automatisieren, schreit man ein Shell-script, z.B.:

#!/bin/bash

REPO="https://svn.company.com/myproject"

ARTIFACTID="webapplication_xyz"

CURRENT_RELEASE=branches/release_1

CURRENT_TAG=tags/release_1-0-0

source $HOME/.bashrc

function deploy_static {

 rm -rf /var/www/myproject

 svn co ${REPO}/${ARTIFACTID}/${CURRENT_RELEASE} /var/www/myproject/release

 svn co ${REPO}/${ARTIFACTID}/${CURRENT_TAG} /var/www/myproject/tag

 svn co ${REPO}/${ARTIFACTID}/trunk /var/www/myproject/trunk

}

if [ "$1" = "" ]; then

 echo "$0 [deploy_static ]"

else

$1 $2

fi

Dieses Script can dann je nach Bedürfnissen so angepasst werden, dass z.B. der JAVA Code compiliert wird und ein WAR file auf dem Tomcat deployed wird. In meinem Beispiel wird lediglich statischer Content auf den Apache deployed.

Im nächsten Post beschreibe ich, wie man das ganze noch automatisiert.

Konstanzer Linie 908 für den iPod

Mal wieder mit dem Bus unterwegs durch Konstanz stellte sich heute bei mir erneut die Frage: "Mit welchem Bus muss ich fahren?" und "Wann fährt ein Bus zurück?"...

Dank des Online-Auftritts der Stadtwerke Konstanz kann man sich gut auf die Reise vorbereiten und alles rund um den "Roten Arnold" erfahren und sogar als PDF runterladen, OK.
Da ich unterwegs nicht immer einen Internetzugang habe, kein Papier ausdrucken und rumtragen möchte und meinen iPod eh immer bei mir trage und gern mit nützlichen Daten füttere, habe ich mal wieder Fahrpläne digitalisiert und aufbereitet - Linie 908.

Einfach runterladen, entpacken und als Photo's auf den iPod G5 synchronisien.

Wer gern noch andere Linien abbilden möchte, hier die Anleitung und Vorlage ...

Viel Spass

TargetProcess 2.5 released

TargetProcess kommt bei der neuen Version 2.5 mit einem sehr guten HelpDesk Adapter daher.

Oft gibt es während der Iterationen Anfragen, neue Requirements, Verbesserungen und sonstigen Feedback (auch von nicht Scrum Mitgliedern), die aber nicht klar als User Story identifizierbar sind, dennoch aber im System verwaltet werden sollten - HelpDesk. Man kann den HelpDesk Adapter per Excel, Email oder einem externen HelpDesk Portal verwenden - nicht schlecht. Wir werden das mal probieren, denn die Zusammenarbeit mit Excel ist immer noch üblich, auch wenn es unschön ist.

Wie viel ist zu viel?

Welchen Ansatz wählt man, um das Business Problem des Kunden zu lösen? Nicht unbedingt eine Frage der agile Vorgehensweise, aber dennoch - immer wieder interessant, welche Weg es gibt und wie die Argumente lauten ...

Momentan arbeite ich gerade an einem grösseren IT Projekt mit einem Partnerunternehmen zusammen. Dieses Unternehmen wurde vor Jahren outgesourced und ist heute der alleinige IT Dienstleister für den Kunden. Mein Aufgabe besteht darin, Know-How in das Projekt zu bringen, damit eine optimale Lösung für die Bedürfnisse des Kunden gefunden wird - technisches Consulting, quasi.

In der Analyse-Phase fallen nun die letzten Vorhänge und die Vorgehensweisen liegen auf dem Tisch - kurzer Eindruck:

- Architektur braucht man nicht zu Beginn, die "findet" sich dann auf dem Weg zum Ziel
- egal was man macht, es muss "jeder" Entwickler verstehen können
- wir machen alles selbst, keine "fremden", externen Abhängigkeiten - Stichwort: open-source
- der Betrieb und das Integrationsteam stellen 80% der Anforderungen an das Entwicklerteam
..... und, wir machen das so, wie wir das immer machen!

Yeah, Right! Wer ist noch mal der Kunde und was sollten wir Lösen?

Die IT - reiner Selbstzweck! Der Kunde legitimiert uns, uns unabkömmlich zu machen.

I'm out ...

Wann sollte man "Nein" sagen? - Teil III

Oft gewinnt man ein Projekt, hat aber nicht gerade die richtigen Resourcen beisammen. Sie, als erfahrener Scrum Master, sollen das Projekt übernehmen und bekommen ein Team zusammengestellt ...

"If we get the right people on the bus, the right people in the right seats, and the wrong people off the bus, then we’ll figure out how to take it someplace great."
Jim Collins, Unternehmensberater

Sagen Sie "Nein"

Wann sollte man "Nein" sagen? - Teil II

Sie haben ein scrum Projekt, bei dem ein Team firmenübergreifend zusammenarbeitet, weil der Kunde da so wünsch?

Der Kunde A möchte, dass Sie als IT Dienstleister B mit der internen IT von A zusammenarbeitet, um ein gemeinsames Projekt zum Erfolg zu bringen...

Sie haben das Gefühl, der Partner im Projekt spricht nicht die gleiche Sprache, komplett andere Vorgehensweise hat, eigentlich nicht mit Ihnen zusammenarbeiten möchte , künstliche Hürden aufbaut, bla, bla, bla

"The team will make or break the project"

Sagen Sie "Nein"

Wann sollte man "Nein" sagen? - Teil 1

Aus gegebenem Anlass schnell ein gutes Argument, wenn man vor der Entscheidung steht, einem agilen Projekt zu- oder abzusagen:

" Good trial lawyers don't take bad cases"

Akutell arbeite ich gerade an einem agilen Projekt mit einem Partner-Unternehmen, wo man ausdrücklich agile arbeiten möchte - die Knwo-how-, Methodik und Erfahrungsunterschiede aber so gross sind, dass man besser "Nein" sagt ...

10 Gründe, warum agile Projekte schief gehen

Wenn ein agiles Softwarentwicklungsprojekt schief geht, ist in erster Line immer die Methode schuld, nicht die Personen, die die agile Methode eingeführt bzw. umgesetzt haben. Oft eine falsche Annahme. 10 Gründe, warum agile Projekte scheitern:

#10 Gerüchten glauben, z.B.

• agile ist besonders gut für kleine Projekte
• totale Kostenkontrolle
• Dokumentation ist nicht notwendig
• agile Vorgehensweise braucht keine Analysten und Tester
• "jeder" kann "alles" Grundsatz
  
• wir machen Scrum, wir sind agile!
  

#9 Widersprüchliche Terminologie

Wir sagen - der Kunde versteht/interpretiert:

• extreme - riskant
• agile - ungenau, unbestimmt, locker
• pair programming - doppelte Kosten
• refactor - unnötiger Code
• unit testing - extra Code
  

Wenn man es nicht erwähnt, hat man es nicht gehört - jetzt ist man agile!

# 8 Keine Schlüsselfiguren

man fokussiert auf die Entwicklung von Features, ABER es braucht einen

• Sprint Manger
• (Business) Analysten
• Tester
• Designer
• WAI Experten
  

#7 Übertreibung

Beispiele:

• Sicherstellen, das Dokumente für jemanden bestimmt sind
• Sicherstellen, dass jede Implementierung ein Problem löst
• Alles weglassen, was keinen Business-Value hat
• Kein Micromanagement
• Keine Statusdiagramme oder ähnliches

#6 Spitzfindigkeiten

• Man braucht ne Menge Erfahrung
  
• Entscheidungsträger sind nur involvierte Personen
• "Nach Lehrbuch" Vorgehensweise
• Alles mindestens 3 Interationen ausprobieren
• Jede Änderung min. 3 Interationen verifizieren
• Keine Angst, Änderungen rückgängig zu machen

#5 Mangelnde Disziplin & Schleifen lassen

• Angst Dinge zu ändern oder Änderungen einzufordern
• Tun und Handeln wird unterschieden - ist man wirklich agile?
• Rituale vernachlässigen

#4 Nicht das richtige Team

• es braucht erfahrene Führungspersonen
• es braucht ein erfahrenes Team
  
• es braucht erfahrene Mentoren für jede Rolle
• man braucht mehr als einen "Plan"
• Externe Epertentips einholen - und zuhören!

#3 Zu lange Interationen

• nicht länger als 2 Wochen
• klarer Rythmus ist erwünscht -> Dienstag -> Dienstag
• Schneller Teams sollten kürzere Zyklen haben
• Keine Zeit verliehren

#2 Kein guter "Sponsor"

• der Kunde muss zum agilen Prozess passen
• man braucht jemanden, der genug politischen Einfluss ausüben kann, um agile ein Chance zu geben
• Überzeugung und Begeisterung für agile schaffen
• Aus Fehlern lernen

#1 Dem Team keine Erholen lassen

• das Team gewinnt oder verliehrt das Projekt
• die Führungsperson ist ein wunder Punkt
  
• die Umgebung/Arbeitsumfeld ist ein wunder Punkt
• die (externe) Unterstütztung ist ein wunder Punkt
• Personalfluktion ist ein wunder Punkt
  

Stub vs. Mock

In einem anderen Post habe ich die vier Test Doubles beschrieben und deren Verwendung abgegrenzt. Da Mocks und Stubs immer wieder verwechselt werden, hier ein Beispiel, um deren unterschiedliche Verwendung aufzuzeigen:

Nehmen wir an, es gibt eine Funktion um das Password zu ändern. Wenn man diese aufruft, soll automatisch ein re-login mit den neuen Credentials durchgeführt werden.


public interface LoginService {
   public boolean login (String login, String password);
}


public class LoginServiceStub implements LoginService {
   private Map currentSessions = new HashMap();
   public boolean login (String login, String password) {
      currentSessions.put(login, password);
      return true;
   }
   public int numberOfCurrentSessions() {
      return currentSessions.size();
   }
}


Beim ChangePassword kann man wie folgt testen, ob login aufgerufen wird (state verification):

class ChangePasswordStateTester...
   public void testReLoginAfterPasswordChanged() {
      LoginService loginService = new LoginServiceStub();
      ChangePasswordService systemUnderTest = new ChangePasswordServiceImpl(loginService);
      systemUnderTest.changePassword("accountId", "oldPassword", "newPassword");
      assertEquals(1, loginService.numberOfCurrentSessions());
   }


Der Mock Test dazu sieht folgendermassen aus:

class ChangePasswordInteractionTester...
   public void testReLoginAfterPasswordChanged() {
      Mock loginService = mock(LoginService.class);
      ChangePasswordService systemUnderTest = new ChangePasswordServiceImpl(
         (LoginService) loginService.proxy());

      loginService.expects(once()).method("login")
         .withAnyArguments()
         .will(returnValue(true));

      systemUnderTest.changePassword("accountId",
         "oldPassword", "newPassword");
   }
}


Bei beiden Beispielen wurden Test Doubles verwendet, nicht der "echte" Login Service, wobei der Stub ein state verfication und der Mock eine behaviour verfication durchführt.

Man muss sich bewusst sein, dass man bei Stubs in aller Regel zusätzliche Methoden hinzufügen muss, um den Status zu prüfen. Das bedeutet, dass die Code Basis wächst und dieser Code wird zunehmens anfälliger und muss gewartet werden. Nicht zuletzt eine Frage der Kosten.

Was sind Test Doubles?

Oft fällt im Zusammenhang mit agiler Software Entwicklung der Begriff Test Driven Development (TDD). Möchte man TDD einsetzten, sollte man wissen, was mit Test Doubles gemeint ist. Dieser Term wird immer wieder in der Literatur im Zusammenhang mit TDD verwendet.

Als Test Doubles bezeichnet man bestimmte Objekte, die beim Testen einen Systems eingesetzt werden, um Zustand und Verhalten zu verfizieren. Es gibt vier unterschiedliche Typen, die jeweils für ein anderes Bedürfniss beim Testen verwendet werden:

Dummy
Ein Dummy Objekt wird nur durch das Sytem gereicht und niemals wirklich verwendet. Dummies werden oft nur zum Füllen von Parameterlisten verwendet.

Fake
Ein Fake Objekt hat eine echte, funktionierende Implementierung, die aber meistens ein abgekürztes Verfahren darstellt. Eine in-memory-database ist ein gutes Beispiel dafür.

Stub
Ein Stub gibt vorgespeicherte Antworten bei Aufrufen während eine Testlaufs, die in keinem Zusammenhang mit dem geschriebenen Test und damit mit dem Caller stehen. Stubs können zusätzlich Informationen über den Aufruf aufzeichnen, z.B. ein Email Gateway, wie viele Emails er verschickt hat und was deren Inhalt war.

Mock
Mock Objekte haben einen definierten Satz von vorprogrammierten Erwartungen (expectations) über die genaue Abfolge von Aufrufen, die erwartet werden, wenn das Mock Objekt verwendet wird.

Wichtig!
Nur Mocks dienem dem Testen von Verhalten (behaviour verfication) eines "System Under Test" (SUT). Alle anderen können nur beim Testen von Zuständen (state verification) verwendet werden.

Ich werde später noch genauer auf Mocks und Stubs eingehen und ein Beipspiel zeigen, da Mocks und Stubs immer wieder verwechselt werden.