Richa(all proper nouns changed to protect privacy), our QA, is doing the final testing of a client feature which will go live in a while. Its 4 PM and Friday Happy hour will start soon. Richa is testing a Drupal 7 site packed with tons of contrib and custom modules, and in case you are wondering, yes, we do deploy on Friday evenings at Acme Inc. Its like any other day here.
As Richa is just about done, Bhushan, our senior developer, wants to borrow the staging environment for another feature that is about to go live on Monday. We follow the gitflow model of development here at Acme Webdev shop. It is convenient for developers to work on isolated feature branches and merge them back to main branch, but not so convenient when it comes to testing, environment creation and deployment. Nivi, the new developer who joined the team that day took almost the whole day to clone the production environment on her laptop. Bhushan assured her it will be fine and she will grow on it.
Back to our Friday production deployment! Richa gets a new ticket raised from client saying that they have to do a quick fix in the UI of the feature which just went live. Hotfixes! Richa grabs Ajith, our another developer with devops chops who can recreate a production clone and patch it real quick. The thing is, Bhushan had to step aside and remove his setup from staging for the Monday feature so that Ajith can create a production setup there.
I'm sure you have had a similar kind of experience, if you are part of a Drupal development team. Brownie points to you if you are the project manager :) This installment of DIY Drupal hosting aims to fix exactly this problem.
Our mission here is to create throwaway Drupal environments without sweating blood, and be quick at that. Pantheon calls this multidev. Acquia supports this as well. Our focus is on DIY and that we be able to self host and manage it. So we will be taking about an awesome tool called OpenDevShop. OpenDevShop is an improvement on top of Aegir which caters to the multidev-style git branch/tag based workflow, as opposed to drupal features and drush makefile based development.
OpenDevShop is constructed around 2 core entities called projects and environments. A project is a single client site, indicated by name and a git repository. It constitutes different environments, like
qa-behat etc. These environments are generally equated to git branches with the same name. Files and DBs can be moved around within the project between environments. For instance, Richa can clone the production setup, call this
hotfix-1357 branch created by Ajith on this setup and run through her test cases, all without coding a single line. The project manager can demo
monday-feature-65 environment to client. The bottom line being, its easy to create new environments.
OpenDevShop tightly integrates with Github, but works with other git providers like Gitlab as well. For better results, it recommends creating a webhook, where a deployment happens automatically in an environment when code is pushed to the corresponding branch. No more "keep-your-fingers-crossed" style production deployments. Deployment generally means pushing a git tag to the production site.
To install DevShop, you can spin up a new box with your favorite VPS provider, spin up and Ubuntu server, and run these commands:
$ wget https://raw.githubusercontent.com/opendevshop/devshop/1.0.0-beta10/install.sh $ bash install.sh
It is a wrapper around an Ansible script which installs all the needed components(very similar to Aegir) on that machine. The UI is neat. Here's my trial setup with this site as one of the projects:
There are a lot of other cool stuff I like about DevShop. Its easy to import your site into DevShop. You have to get a drush alias of your environment first.
creating drush aliases in DevShop
Then, you can use to copy over the DB dump,
$ drush @lakshminp.dev sqlc < 02_08_2017_lnp.sql
$ drush rsync ~/lakshminp/lakshminp-dump/html/sites/default/files/. @lakshminp.dev:%files
You can also spin your own servers from the web interface. As a prerequisite for this, you have to add the API keys of your VPS provider, which in my case is DigitalOcean.
Spinning up a new server
Adding DO as a cloud provider
OpenDevShop comes with its own backup and restore options as well. I haven't explored if it exports backups to a service like S3, but that's something which you can build easily as a script or a module.
The biggest strength of DevShop IMO is the ability to run Behat tests(even Drupal's simpletest tests) from the web interface and getting the results realtime. This could be a starting point for Acme Inc's CI workflow. Richa could have the test cases run and results mailed to her while she's having fun in the Friday Happy Hour.
I'd personally love to see teams as a feature, where different members of the team have different levels of access across the project and environments. Jon Pugh, the project's creator said that its definitely on the cards.
If you are a Drupal agency shopping for DIY solutions, you SHOULD give OpenDevShop a try, like now. There's even commercial support. Do give it a shot and let me know how it goes :)
Next stop in the series, we are jumping into the container bandwagon!
DIY Drupal hosting series
DIY Drupal hosting using OpenDevShop - you're here