Over the past 2 years I gained some experience with GIT and DTAP and TAP environments. I will share my experience on this subject, not writing as an expert.
I experienced deployment always as a little bit of a headache, ranging from manual FTP uploads, rsync's triggered by scripts to telephone calls to hosting providers hosting providers asking for deployments. This is also due to the fact that you cant always choose your hosting platform or -provider.
The GIT era
Now GIT is mainstream and adopted by more and more enterprises and hosting providers DTAP deployment can be a very sane and pleasant exercise. Finally ;).
Besides benefits for deployment, GITFlow is a must-have for development teams anyway, it incorporates best practices in a standardized and intuitive workflow.
GIT deployment explained
There is more than one way of doing things, this is what works best in my opinion.
Test and Production (DM)
Since with GITFlow only two branches live eternally: Develop and Master, lets map them first to DTAP nodes:
- Develop goes to Test.
- Master goes to Production.
Thats easy to understand. But what about D and A? Lets focus on Development first.
Development can be more than one node, most Drupal developers work on there own, (local) development instance. Dependent on if: Development is a central node; and team conventions, Development pulls from a Feature branch or the Develop branch and may switch branches. Development is the less pre-defined, most use-case dependent node in terms of which GIT branch to pull. But it always should be the Develop- or a Feature branch.
Acceptance is simpler to define. By default Acceptance pulls from the Master branch. Only if there are changes to accept, Acceptance switches to the corresponding Release branch. When the change is accepted, the release branch is closed and merged to the Master branch. Acceptance then switches back to Master.
|DTAP Node||GIT branch|
|D||Develop or Feature|
|A||Release or Master|
Ready to roll environments
Hosting platforms like Acquia or Pagodabox and others have it all integrated for you. With an kind-of intuitive web-interface you can pick branches, deploy them to a DTAP node and drag/drop them through the deployment proces. Some platforms even provide access-control to enable certain roles to execute a deployment step.
With Jenkins you can automate the build- and distribution proces. The nicest part is the integration of JUnit testing in the build-proces. This is no out-of-the-box solution, but a very solid piece of software to build your own GIT based deployment solution.
With simple, custom scripts you can build a powerfull deployment toolset. One of the advantages is you can do environtment- specific tasks like cache-clearing on redundant nodes.
Simple example without errorhandling:
#!/bin/bash #declare vars ACTBRANCH="develop" #to repo dir cd /var/www/yourdrupalroot/sites/domain.tld #checkout active branch just to be sure echo "checkout results:" git checkout $ACTBRANCH #pull all other changes echo "pull results:" git pull #drush commands echo "Let's do Drush stuff now" drush cc all drush updb -y drush cc all drush fra -y drush cc all drush fl
Basically this snippet forces to use a branch by checkout, pulls all code changes and executes Drush commands to update the database, revert features and clear caches.
Eagir must be a nice tool for Drupal deployment. At least, thats what I read about it... ;-) don't know how Aegir aligns with G|T and DTAP though. Fill me in please!
You can match default GITFlow branches with deployment to an OTAP environment without much hassle. You can do so by executing basic commands on- or to every server. Manually or automated. With homegrown scripts or deployment tools.