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.

Release-Management mit Scrum

Wir schreiben Software, die in einem ordentlichen Release Zyklus ausgeliefert werden muss. Um das zu gewährleisten, wurde die Entwicklung so aufgebaut, dass man trunk, branch und tag Stränge hat.

Wenn man mit Scrum iterativ arbeitet und ein ordentlichen Release Zyklus sicherstellen will, stellt sich die Frage, wo/wann werden Features entwickelt und wo/wann Bugs gefixt?

Das Team hat diese Fragen genau untersucht und folgende Alterantiven erarbeitet:

• Es gibt eine Feature Sprint, gefolgt von einem Bug Sprint - immer im Wechsel
• In jedem Sprint werden Features entwickelt und Bug's gefixt

Da der Product Owner nach jedem Sprint Funktionalität geliefert haben möchte, hat das Team die 2. Variante bevorzugt.

Da die Code Basis bereits mit dem Release 2.0 in Produktion ist, hat man beschlossen, dass Features im Trunk entwickelt werden. Bugs werden im Branch gefixed und auf Trunk gemerged.