In a series of blog posts I am going to present our new tool for doing drupal deploys. It is developed internally in the ops-team in Wunderkraut Sweden , and we did that because of when we started doing Drupal 8 deploys we tried to rethink how we mostly have done Drupal deploys before, because we had some issues what we already had.

In a series of blog posts I am going to present our new tool for doing drupal deploys. It is developed internally in the ops-team in Wunderkraut Sweden , and we did that because of when we started doing Drupal 8 deploys we tried to rethink how we mostly have done Drupal deploys before, because we had some issues what we already had.

What we had - Jenkins and Aegir

Since some years we have been using a combination of Jenkins and Aegir to deploy our sites. That work-flow worked, sort off, well for us. And because it was not a perfect match we tried to rethink how we should do deploys with Drupal 8 in mind. 

Research phase

We looked in many directions, like Capistrano and Appistrano, OpenDevShop, platform.sh, Aegir 3 etc. But none of them fitted our current need – we wanted to simplify things, and most of the tools just added another layer that was not a perfect fit for us. Also, it was important to us that the solution should be open source.

We went old school and built our own solution – almost.

Re-use and invent

With Drupal 8 we got to know Symfony in a better way, and Symfony has a console, that also is used by Drupal console project. The advantages in using Symfony console for a base for our deploy flow were big, based on Symfony best practice and using open source projects. Also, drush does a lot of stuff that we need in the deploy process, so that is an important part also. We did not want to re-invent stuff that already worked well.

Enter Dropcat

So we started to build Dropcat (Drop as in Drupal, and cat because… because of cats) and we slowly added more and more stuff to it, and now we have most part of the commands that we need to do a normal deploy, we are still working on one important bit – and that is the rollback – and hopefully when this series of blog posts about Dropcat is finished, we have that in place also.

In next blog post we take a look into how to install dropcat and how th configuration files works. You could check out the Dropcat project on our GitLab server.