A Drupal Dev Workflow for everyone: git flow, or just your flow
by Dave Ingram
When it comes to building Drupal sites with a team of developers, there's perhaps nothing more important than establishing a productive workflow. Conferences are buzzing with talk of Continuous Integration, DevOps, Deployments and everything of the sort, and that's because as project sizes grow, these topics become central to the question of building great websites.
But what is the best way to turn your development team into a well oiled deployment machine? Unfortunately, I can't prescribe that for you, because your development workflow needs to fit your own needs, not mine. But what I can do, is provide you with a set of ideas and point you to the tools that will let you craft a development workflow that is ideally suited to your organization, people, and projects.
Drupal with gitflow … or just your flow
There's a popular methodology for handling code bases in git that's known as "git flow". It comes with a set of command line tools and a well thought out model. It's even well supported by some popular git GUI tools such as SourceTree.
The way it works is through a specific naming convention and branching strategy which includes a development branch, feature branches, release branches, hot fix branches, and finally the master branch which is used as the current production code. Of course you can do all of this with just git, but git flow adds a nice layer of polish to get all of your developers on the same page and ease the process of merging and branching. There's even a handy printout you can give to all of your developers to remind them the names and processes for handling your branches.
Gitflow is a great plan, but it might not be best suited to your team and your workflow. When Linus Torvalds created git, he built it because he didn't want to be locked into somebody else's workflow, and git is extremely good at being flexible. So don't be afraid to get out your whiteboard and craft the perfect flow for you. If it makes more sense to name git branches after your developers, then go for it. If you like to use your master branch for development and have a production branch for your deployed code (which happens to be my preference), then you can do that too!
A basic Continuous Integration and deployment model
When it comes to development environments, the minimum workflow that most people would want to use is a development environment, a staging environment, and a production environment. The basic idea here is to put all your latest code on the development branch, then when you're ready to make changes to your live site, you move your new code to the staging environment, while at the same time moving your database and files from your production environment. This will allow you to run tests (both automated and manual) to make sure that nothing is broken before moving any new code into production.
Every Acquia Cloud subscription comes with these three environments. The beauty is that you can customize them as you need to. For example, some developers like to just use one git branch (the master branch) and then, using the drag and drop interface in the Cloud UI, deploy code from one environment to the other. This works well as a basic workflow for smaller projects, but what if you need more flexibility, perhaps using gitflow? Simply configure each environment to use the appropriate branch, and you can do deployments just by pushing your latest code changes to your git repository. In the case of gitflow, you can just set the Dev environment to "develop" and the production environment to "master". Finally, use the staging environment to switch branches as you need to test release branches and hot fixes.
Stepping it up with more environments
So what happens when you get multiple lines of development going? The quick and easy way within cloud UI is to just switch branches in your development and staging environments as needed in order to test (and re-test) changes as they occur. That's not always convenient though if you have automated workflows or you have different people reviewing and doing QA on multiple lines of work.
Thankfully, the fine folks in the Acquia Engineering department built in a way to have more than three environments, as you can see here.
In fact, the sky is really the limit with what you can do with a set-up like this: Use Jenkins to push code through three rounds of QA; have individual development environments for each developer; multiple staging environments to test different lines of work simultaneously; yet another for integration; then finally deploy that out to production.
Please note: The ability to add additional environments is currently limited to Acquia Cloud Enterprise customers. There may also be a charge per-environment depending on your server configuration. Please contact us for more details if you're interested in taking advantage of this feature.
Go further … for free
Sometimes you might want to work with a developer but not give them full access to your environment. Well the good news there is that you can tie together everything above with completely separate environments on Acquia Cloud Free Tier. This is built especially for developers to be able to use the Cloud environment and either code directly on the server, or develop locally and test in the cloud with a dedicated development and staging environment.
If you want to pull those pieces together, a few strokes at the terminal can merge both lines of development together and push them back to the main project page, or you can even configure Jenkins to do that for you (perhaps after running some regression tests on the developer's environment to ensure nothing has broken in the process). Need separate environments for 10 developers? At a cost of 10 x free, it couldn't be easier.
Go even further with Cloud Extend
The cloud is an excellent choice for hosting sites due to all of the resilience, flexibility and agility that it has to offer. But what happens if you need to host your production environment elsewhere for legal or business reasons? You're in luck, because we have you covered there too! With our Cloud Extend functionality, you can use all the great tools of Acquia Network and the Acquia Cloud development environment that are discussed here, but your production environment can be seamlessly integrated into this experience, so when you push code from staging to production, it goes seamlessly to your alternate production environment. This isn't the best option for everyone, but for some it's ideal, and it's the freedom to do it your way.
Building up your toolset
I've already mentioned git tools like gitflow, and there are plenty of GUI interfaces for git that you might want to look at as well, but there are a lot more tools than that which you can incorporate into your workflow.
The first thing to note is that anything you can do within the Cloud UI on Acquia Cloud, you can also do through the Cloud API. What you get with this is unprecedented freedom to automate any aspect of your workflow. Want to run automated tests on every developer branch and then automatically move that code into the mainline development branch if the tests pass? That process can be easily automated using Cloud API.
This brings us to Continuous Integration tools such as Jenkins. Jenkins allows you automate every aspect of the deployment process and carry out any number of actions along the way. For example, you can monitor your git repository for changes and any time they're detected you can run a test suite or several test suites to check the quality of your code and the functionality of the site. With Cloud Hooks you can then deploy to the next environment automatically if all tests pass, or have Jenkins send emails to the appropriate developers if the tests fail.
I would be remiss not to at least give a passing mention to some of those automated testing tools. This is an invaluable addition to any workflow and can be easily automated into the process through Jenkins and through Acquia's Cloud Hooks () which allow you to run scripts on our servers as code is deployed. Common tools include PHPUnit (phpunit.de), Simpletest (which is built in to Drupal 7), Behat and Selenium. Any combination of these tools and others can be incorporated into your development workflow to catch mistakes faster, making your project even more successful.
Finally, while not exactly a deployment tool, a recent announcement earlier this week will be improving my workflow considerably. PHPStorm, my current IDE of choice, has just added a wide range of Drupal specific features to their product, so if you're considering a new IDE, or just haven't seen the announcement yet, be sure to check it out.
Do deployment your way
Here at Acquia, we believe in freedom and doing things the open source way. You chose Drupal because you didn't want to be constrained by someone else's idea of what a website should be. You chose open source because you wanted unlimited flexibility. We believe you should have the same open and flexible experience when it comes to your development workflow.
Have any further suggestions or questions on any of these things? We'd love to hear your feedback in the comments, or set up a call with us today to find out how we can help you move your development experience to the next level.