DevOps at Marktplaats

The journey

How did we get from this:



….to this?




We’re deploying to production multiple times per week, running tests after every commit, pushing only to master, not working on branches, you should do it too, it’s awesome.




The DevOps story

When we started on the big Migration project, there was not a lot of communication between developers and system administrators (SiteOps). It kind of looked like this:



It didn’t work, lots of confusion and miscommunication.


The next step was to put system administrators in the development teams. The developers really liked it, they could ask (stupid) questions whenever they wanted.

How did the SiteOps guys like it, you ask?

Not so much.


Where we are now:

We have a Sysadmin Support team which does releases and picks up the smaller tasks like environment configuration changes.

Next to this, there is a Sysadmin Solutions team for longer running, more architectural issues (e.g. configuring a Hadoop cluster).


As developers, we are pretty happy with the current situation, since the tickets we create are being picked up quickly.


How to release?

A big question in the DevOps movement is: how can we make it easier to do a release?


Here’s how we solved it:

  1. We have a service-oriented architecture.
  2. Developers push code to different services, to the master branch.
  3. The different services each have their own git repo, which is polled by Jenkins.
  4. Jenkins compiles, runs tests and deploys to the test environment (called ‘integration).
  5. Acceptance tests (e.g. Selenium tests) run against the full test environment.
  6. When these tests are green, a deployable tarball is created (with a specific version)*.
  7. The tarball is being deployed to the next environment (called ‘demo’).
  8. On demo, the integration with other platforms is checked. This is also where QA manually checks the stories that have just been implemented.
  9. The (versioned) tarball is deployed to the Load & Performance test environment.
  10. Load & Performance tests are run against the L&P environment.
  11. If all is green, it can be deployed to the production environment (this is a manual step).


* This is how the tarball is created:

  1. All services deployed to the test environment are checked for their version.
  2. Such a version consists of a git commit hash and a timestamp.
  3. The services are then copied from the test environment and packaged into a tarball.
  4. The tarball is versioned using a timestamp.
  5. The tarball is archived for later use.


This is our overview screen, to easily see what version of the application is deployed on which environment:



Doing DevOps as a developer

Doing DevOps will not work if developers don’t change. Luckily, we did change.

These are some things that we’re doing differently than before:

Devs are making puppet changes (reviewed through gerrit)

Our local development environment is managed by puppet and configured to be as much as Production as possible (using boxenvagrant and homebrew (to name a few))



#1 Tip

Tip #1 for a developer to become more DevOps-savvy: setup a new environment. Some benefits include, but are not limited too:

  • direct communication and tight integration with sysadmins
  • learning the conventions and consistencies in naming
  • improve your knowledge of the communication flows within the application (hosts, ports, using proxies, db access, access to messaging system, firewall, etc.)
  •  beer more recognition from your SiteOps colleagues




“Release It!” by Michael Nygard

Awesome colleagues 😉

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s