Dropfort

• What is Dropfort?
  • Dropfort is a suite of tools to develop and manage Drupal applications.

On the development side, it integrates with GitHub and GitLab to track commits, issues and tags. It then packages releases based on those tags and lets you share those releases with your Drupal sites. Same way you tag and create releases on Drupal.org. The only difference is the released modules are private. Meaning a site that wants to use those modules needs to authenticate to download them.

For example, if you want to download a custom module to your site from dropfort, you can just do a “drush dl mymodule --source=https://app.dropfort.com/fserver/release-history”. Dropfort generates the same XML data for its modules as does Drupal.org for contrib modules. Meaning the Update module works with Dropfort, all your Drush commands work and Drush make works too. It’s all pretty seamless. The only difference with our XML is that it's not publicly available. Your site has to be allowed to see the update feed which is what you configure in the Dropfort web app itself.

The other half of Dropfort are the operations or “ops” tools. You connect your sites to Dropfort using the Dropfort Update module (which is available on Drupal.org) and it will start doing a few things. The most obvious is tracking the update status of your site. Being a Drupal shop, we monitor a few dozen Drupal sites at once and so logging into each site to see what modules need updating and the status of those sites is time consuming. What Dropfort let’s us do is see all those sites in one dashboard. I can login and see the update status and status report data from all the sites in one place. Dropfort then uses this data to generate some graphs about your sites. For example it can tell you how many dev modules you’re using across all your sites, it shows you a list of what sites have security updates and it does some fancy calculations to grade your site’s health as well. Lots of metrics to know what’s going on and how things are changing over time.

The last part, and this is what I’ve been working on mostly these last few months, is an Environment manager. It’s still pretty fresh and there are some rough edges but it does work. You can create a set of environments (dev, testing or production) to store machine configurations to both do your development and run your Drupal applications. You can say “I want a server running apache, with MySQL and the Commerce Kickstart distro” on it. Then you can either download a Vagrant file which will provision a vm, or you can download a docker container which will do the same. Or you can run a bash script on an existing machine to link the server to Dropfort and have that configuration deployed. It’s pretty neat stuff. Basically any server anywhere can be turned into a managed Drupal cloud.

Like I said, there’s a whole suite of stuff in here.

• Why did you create Dropfort? Where did it start?

It all really came from using Feature Server for Drupal 6. When we incorporated Coldfront in 2011 and really turned it into a full time job, we wanted a way to distribute code to all our clients (even though at the time I think we only had one). We setup FServer to deploy code to your client sites. But manually creating the releases and the pages and stuff was kind of a pain. So we came up with a special commit syntax we could add to Subversion (this was before Git was a big thing). So could make our svn commit and in the message we’d write [release:full] and some post-commit scripts would run on the svn server. They’d look at the commit message and then take the code, create a tgz file, create a tag, commit the tag and then upload the tgz file to FServer using some REST web service endpoints we create on a Drupal 6 site with Services. That would create the release page, the release notes, add the files and generate the update XML. It was pretty well a mini Drupal.org but with Subversion (instead of CVS which D.O was still using at the time). It actually worked really well. So well in fact that the University of Ottawa asked if we could install a version for them to manage their Drupal stuff (which they’re actually still using today until their git migration is done). That’s when the lightbulb went off I guess. We had built this stuff for us but as it turns out, other people want to deploy custom modules too! Who’da thunk it?

And that’s when the idea for a more “web app” version of our SVN workflow came to be. At the time I thought “Yeah we can totally rewrite this in no time, I give is 6 months and we’ll have a web app ready to go”. That was 3 years ago I think? It took a bit longer than expected. Mostly I kept adding features… Yay scope creep. But now we’ve got a pretty awesome suite of tools and we’re focusing on the polish now. I’ve been told I’m not allowed to make feature requests for at least a month. We’ll see how that goes.

• Can this be used to compete with Drupal.org? Meaning can people share public releases here instead of on d.o?

Nope. Public modules should be on Drupal.org. No module can be downloaded from Dropfort without authenticating first. We don’t want to supersede d.o in any way. We actually looked into writing a feature to automatically move a project from bieng private to a public one on d.o but since Drupal.org doesnt’ have an API we couldn’t do that. But yeah, this is for privately distributed modules only.

• Does the monitoring dashboard check both the private projects as well as public ones on d.o?

  • Yes

• What did you build it with? Is Dropfort open-source?

The original SVN workflow using Subversion, CLI PHP, Drupal 6, 2 custom modules and some REST / Services stuff.

Dropfort uses Git, Drupal 7, Services, about 20 or so custom modules, Puppet and our Drupal 7 port of FServer. So Dropfort is a Drupal application itself. We actually use Dropfort to manage Dropfort. Meaning we track it’s own updates and status using itself, and it packages releases for itself. A little inceptiony but it works.

Most of the parts which make up Dropfort are open. Some of the custom modules aren’t openly available. But that’s mostly because we don’t have the bandwidth to help and support the distro on D.o. Especially the stuff involving setting up a Puppet master. We’d spend more of our time debugging that than actually making things work. Doesn’t mean we won’t share everything eventually, just not right now.

• What’s the plan for Dropfort? Is it a paid service or is it free?

Right now it’s free to use. The main reason for that is we haven’t written the commerce component yet so we can’t actually charge for it so… yeah. But we’re looking at different ways of monetizing. It’s tricky cause we want people to use it but at the same time we don’t really know what people will use. There’s such a variety of things in there it’s tough to decide what should be charged for. For example Github is pretty straightforward in their pay structure. If the code is open, your repo is free. If your code is closed, you pay for the repo. For us, I think it’s a question of usage. We’re leaning towards all tools are free to use with any account, it’s just a question of how much storage or how many sites you’re using. But regardless, anyone who uses it now is free to use it as much as they want. And we’ll have some special plans for early adopters as a thanks for their feedback. More than likely a bunch of free stuff.

• How does this compare to other tools like Platform.sh, Pantheon, Acquia Dev Cloud?

The big difference is that they’re primarily a hosting platform. Dropfort is a management platform. You can connect a Pantheon site or an Acquia Dev cloud site to Dropfort and use most of the features no problem. You’d probably skip the release packaging stuff and environment management (for now) but the stats tracking and collaboration tools would work just fine. Dropfort doesn’t care where or how you run your Drupal site. As long as it can reach the internet, you can use Dropfort.

But you can use Dropfort with GitHub or GitLab or neither. You can use Vagrant or Docker or both. We do our best to integrate with anything which might make building Drupal application easier. It’s all about choice.

As for the hosting side of things, we give you tools to deploy your own server or cloud of servers. Meaning you can run an optimized network of Drupal web servers on whatever provider you want. It’s a philosophical difference. We let you host your code and sites wherever you want whereas with others you live on their machines. Which can have a lot of advantages and for the majority of folks out there, that’s fine with them.

But for us we’ve found it difficult for some enterprises here in Canada to get hosting on services in the US which are bound by the Patriot Act. We have FIPA, the Freedom of Information and Privacy Act which states that we can’t share information about users unless the user has explicitly allowed that agency access. The Patriot Act is pretty much the exact opposite of that. So we figured we’d bring most if not all of the advantages of a cloud solution (the optimized configuration, automated deployments / scaling, generated environments) to anyone’s infrastructure. You just supply the hardware, Dropfort does the rest.

I see it as just another option in how you can host your Drupal site. You can choose how much or how little you want to be involved in managing the hosting environment. Whichever way works best for you is the one you should go with.

• How does this handle dev/staging/live scenarios?
• How about local?

Use Cases

• Let’s talk about the current use cases for Dropfort.
  • Managing several sites in one place
  • Create custom, shareable development environments
  • Create releases of projects destined for more than one application
• Why would you use Dropfort instead of just Git to manage deployments?
  • We use Drush Make for just about everything. We control our releases using Drush make. We apply patches with Drush make. We really like Drush make. And we really don’t like merge conflicts. The number of times I’ve come into a project where the entirety of Drupal core and all the contrib modules are in a single repo with a team of people trying to all work on it at once has taught me that’s not the way to work. Treat your projects like d.o does, as self contained sets of functionality. Use make files to build your application and drush to manage updates. This is how Drupal is designed to work. Drupal is a collection of modules. When you all of a sudden lump it all together into a single repo you’re breaking how Drupal was meant to be managed.
• Can you explain a bit more about how Drush Make works?
• You just mentioned automated updates.
• What’s in the near, and far future for Dropfort?