Christian Trabold

blogging about work, stuff …and Durian

Continuous Delivery Workshop Vorbereitungen


Diese Anleitung führt Sie durch die Installation für das Beispielprojekt zum ‘Continuous Delivery’ Workshop.

Während des Workshops deployen Sie eine Website über folgende Stages:

dev -> ci -> qa -> prod


Für den Praxisteil des Workshops benötigen Sie einen Laptop und folgende Software:

  • VirtualBox installieren:
  • Vagrant installieren:
  • Sorgen Sie für ausreichend Platz auf Ihrer Festplatte. Wir empfehlen für den Workshop mindestens 2.5GB freien Festplattenspeicher.
  • Stellen Sie sicher, dass Ihr USB-Port funktioniert. Wir bieten das VM-Image auf einem USB-Stick an.
  • Stellen Sie sicher, dass die Ports 8181 und 8153 frei sind. Wir benötigen diese Ports zum Aufrufen der Beispiel-Applikation auf der Virtuellen Maschine


├──                     Allgemeine Anleitungen
├── Vagrantfile                   Konfiguration zum Starten der VM
├── app                           Beispiel-Applikation für den Workshop
└── vendor                        Externe Dateien von Drittherstellern
    ├── Vagrant-1.4.3.dmg
    ├── Vagrant_1.4.3.msi
    ├── vagrant_1.4.3_i686.deb
    ├── vagrant_1.4.3_i686.rpm
    ├── vagrant_1.4.3_x86_64.deb
    ├── vagrant_1.4.3_x86_64.rpm
    ├── VirtualBox-4.3.2-90405-Win.exe
    ├── VirtualBox-4.3.2-90405-OSX.dmg

Das Beispielprojekt verwenden

  • Verzeichnis cd_workshop vom USB Stick auf die lokale Festplatte kopieren
  • USB Stick auswerfen und an den nächsten Teilnehmer geben
  • VirtualBox und Vagrant installieren (falls noch nicht vorhanden)
  • Terminal öffnen und in den Workshop Ordner wechseln
  • Den Befehl vagrant up auf dem Terminal ausführen
    Nun startet die Virtuelle Maschine.
  • Öffnen Sie http://localhost:8153/ im Browser um den CI-Server zu sehen
  • Öffnen Sie http://localhost:8181/, um eine Übersicht des Beispiel-Projektes zu sehen:
http://localhost:8181/workshop-dev  - Current status in `app`
http://localhost:8181/workshop-ci   - Stage after build
http://localhost:8181/workshop-qa   - Stage after tests
http://localhost:8181/workshop-prod - Production
  • Verbinden Sie sich per SSH auf die Virtuelle Maschine mit vagrant ssh.
    Sie sind nun mit dem Benutzer vagrant angemeldet und sollten sämtliche für den Workshop relevanten Befehle ausführen können.
    Falls Sie sudo benötigen, können Sie ohne Passwort root Benutzer werden.
  • Für den Fall, dass Sie einmal nach dem Passwort gefragt werden:
Benutzer: vagrant
Passwort: vagrant
  • Wechseln Sie in das Verzeichnis /vagrant/app, führen Sie die Änderungen aus und pushen Sie diese in das Git-Repository:
cd /vagrant/app

git add .
git commit -m "Update content"
git push origin master
  • Ihre Änderungen aktivieren den CI-Server. Wechseln Sie auf die Web-Oberfläche und schauen Sie dabei zu, wie das erste Paket gebaut wird: http://localhost:8153/view/CD-Pipeline/
  • Bauen Sie die Applikation weiter aus und wiederholen Sie den Schritt, wenn Sie mit den Änderungen zufrieden sind.
    Sie können die Applikation über Ihren gewohnten Editor oder Ihre IDE auf dem Host bearbeiten und die Änderungen dann auf der Maschine pushen.
  • Sobald Sie mit dem Ergebnis zufrieden sind, stoßen Sie das Deployment auf die weiteren Stages an.

Häufige Fragen

F: Ist die VirtualBox zwingend notwendig oder kann man das auch mit VMWare Workstation arbeiten?
A: Wir benutzen für den Workshop das kostenfreie VirtualBox. VMWare Workstation unterstützen wir nicht.

Continuous Delivery Workshop Preparations


These instructions will guide you through an example project for the ‘Continuous Delivery’ workshop.

You will deploy the website through several stages:

dev -> ci -> qa -> prod


To start the workshop right away we ask you to bring a laptop and prepare it as follows:

  • Install VirtualBox:
  • Install Vagrant
  • Ensure that you have at least 2.5GB of free space on your hard disk
  • Ensure that your USB port is working so that we can provide the image via a portable Hard Drive/Stick.
  • Make sure you don’t use local ports like 8181 and 8153. We need these ports for accessing the apps on the VirtualMachine

File structure of the example project

├──                     General instructions
├── Vagrantfile                   Config for starting the VM
├── app                           Example app for the workshop
└── vendor                        External files from vendors
    ├── Vagrant-1.4.3.dmg
    ├── Vagrant_1.4.3.msi
    ├── vagrant_1.4.3_i686.deb
    ├── vagrant_1.4.3_i686.rpm
    ├── vagrant_1.4.3_x86_64.deb
    ├── vagrant_1.4.3_x86_64.rpm
    ├── VirtualBox-4.3.2-90405-Win.exe
    ├── VirtualBox-4.3.2-90405-OSX.dmg

How to use the example project

  • Insert USB Stick
  • Copy folder cd_workshop to local disk
  • Eject the USB stick and pass it to the next student
  • Install VirtualBox and Vagrant from vendor (if not installed already)
  • Open the terminal and go to the folder on your local disk
  • Run vagrant up on the terminal
    Now the virtual machine starts up and consumes the local ports. It fetches the .box file from ./vendor to create the VM
  • Open http://localhost:8153/ in your browser to see the CI-Server working
  • Open http://localhost:8181/ to see the umbrella page for our web project we will working on
http://localhost:8181/workshop-dev  - Current status in `app`
http://localhost:8181/workshop-ci   - Stage after build
http://localhost:8181/workshop-qa   - Stage after tests
http://localhost:8181/workshop-prod - Production
  • SSH into the machine with vagrant ssh.
    You should be able to run every command that is needed for the workshop as user vagrant.
    You can use sudo without a password.
  • In case you need the username and password:
Username: vagrant
Password: vagrant
  • Go to the folder /vagrant/app, make changes and push them
cd /vagrant/app

git add .
git commit -m "Update content"
git push origin master
  • See the CI-Server in action while fetching the changes and running the tests: http://localhost:8153/view/CD-Pipeline/
  • Improve the application and push the updates, when you are satisfied with your results.
    You can edit the code directly on the host in your favourite editor / IDE.
  • Approve the changes by starting the deployment to the next stage


F: Do I really need VirtualBox or may I use VMWare Workstation as well?
A: We are using VirtualBox for our workshop. VMWare Workstation is currently not supported.

Spring Cleaning

Hi there and welcome to my GitHub blog!

I moved away from Posterous to GitHub pages because Posterous closes down end of April 2013.

I decided against migrating old content to my new blog, because I felt like having a fresh start.

While working on GitHub I also removed the following repos and forks from my GitHub space:

javascript_testsuite → ctrabold/javascript-testsuite

These repos were inactive, orphaned, outdated and rather confusing than useful.

Please update your forks and .git/config in order to use their original repos if you like to contribute.

Librarian-chef vs. Berkshelf

This is a brief comparison between librarian-chef an berkshelf to point out the main differences in managing cookbooks. Please refer to the offical announcement for berkshelf for a in-depth introduction / comparison for all features.


I’m a big fan of librarian-chef and I currently use it in every chef-driven project.

It helped my a lot taking back control when I got -confused- overwhelmed by cookbooks. Thanks to librarian-chef I finally could seperate my patched cookbooks, get rid of git-submodules in a sensible way with an easy to manage Cheffile that can be stored in version control. Everything was wunderbar!

When I first heard of berkshelf via this blog post I got slightly confused: Is someone re-inventing the wheel here? It turned out that I should have read the offical announcement for berkshelf before posting my Tweet :) Hope this post helps you as well.

What is the difference?

Both berkshelf and librarian-chef download cookbooks from various locations. If that sounds totally new to you I highly encourage you to adopt either one of thoses tools to your workflow. The main difference is where and how the cookbook files are stored in the current repository / project:


librarian-chef will load all cookbooks defined in a Cheffile to a cookbooksfolder within the current directory.

It also helps you keeping the cookbooks folder in shape by providing commands to show you outdated cookbooks etc. To do so it caches the checksums of theses files in a tmp folder within the current folder.

I did not find a way to change the default “cookbooks” folder which can be a bit painful if you want a different folder strucuture.


berkshelf (by default) loads all cookbooks from the Berksfile into one centralized repository in ~/.berkshelf (customize via BERKSHELF_PATH) and NOT into the current directory.

After downloading all the cookbooks and their dependencies you can link those into whatever folder you like with berks install --shims your_desired_path. Default is cookbooks. Berkshelf creates hard links to cookbooks in the repository. You have to take care of outdated cookbooks etc.

Final thoughts

I’m very new to Berkshelf (just installed the gem, run the examples provided on their website) and yes it looks very promising.

Berkshelf’s aproach with ONE repository that builds “the single source of truth” for all your chef-repos makes sense to me because these cookbooks should never change and kept away from your modifications. And Berkshelf does not spoil the repo with an “tmp” folder which confused some of my colleagues. Also the other features like “metadata” sound cool.

Again: Please refer to the offical announcement for berkshelf for a in-depth introduction for all features. Although I found the installation of berkshelf a bit more complicated than librarian-chef (because of gecode) I will definitly dig deeper into Berkshelf.

The only thing I don’t really get is the name “Berkshelf” / “Berksfile” and I could’t find a proper translation. Yeah call me picky :)

Maybe a native speaker can give me a hint on that one :)

I’m very interested in your experiences with either of these tools.

– Cheers Christian

How I Switched From Bash to (Oh-my) Zsh

I switched from bash to zsh lately. After announcing it on Twitter I got lots of reactions, mostly questions, how I did get started.

So here’s how I got started:

  1. I decided to change my shell. Why? Actually I was like why not? Seeing a lovely bunch of hackers at the Vagrant Usergroup Berlin getting excited with tig (a Git browser on the shell) can have quite an influence - so I though: there’s got to be more than my standard shell!
  2. I did brew install zsh to get the latest version
  3. I added /usr/local/bin/zsh to /etc/shells Otherwise you won’t be able to activate the shell.
  4. Finally I switched the shell to zsh: chsh -s /usr/local/bin/zsh

After that I removed ~/.bash-it, followed the instructions and customized my ~/.zshrc.

That’s it.

Since then I do not regret it. I feel very comfortable with my new shell and I love the tiny little features it provides like auto-completion and correction.

I didn’t dig into scripting yet though, so I can’t provide any feedback here but would love to hear your optinion on this.