At the 2012 Bay Area Drupal Camp, I presented a session laying out a possible dev-test-live development workflow branching model using Git. This continues on from the session I presented last year, Beginning Git.
This presentation borrowed heavily from two sources: First, an article on a successful Git branching model that describes, among other things, the process for maintaining a useful dev branch, and allowing feature and bug fix branches to always branch off of that one. The second source is a class I helped develop for Chapter Three called Drupal Development Best Practices. Much of this session is covered in that class. Conveniently enough, Chapter Three is offering the class next month.
It's important to note that this is by no means the Only Way to do this. In fact, shortly following my presentation at BADCamp, I had several great discussions from other people who use other strategies. It was so neat to hear what people are doing with their own workflow. One person said that they prefer using tags for the Test and Live code pushes instead of separate branches. That's not a bad idea.
Git is so flexible that you can really make it work for you however you can work best. The most important thing, though, is to spend some time to develop (and document) a standard workflow that your whole team can follow. And then stick with it. SVN was easy: just use Trunk. Git is so exceedingly powerful that it can be ridiculously confusing if you are jumping into a team and don't know the workflow. It's too easy to screw it all up for everybody.
I made a screencast of the presentation, but I'm having trouble embedding it, so you'll have to settle for link to Vimeo for now.
Comments
Backup and Migrate
Hi Shawn,
I watched the screencast of this talk on Vimeo and found it extremely helpful. Thank you so much for making it available.
It seems at the end like you were going to discuss using Backup and Migrate but you ran out of time.
I have experimented a little with the module and it looks great, but I have a question about it and the workflow you describe in the Vimeo video.
If you are using B&M to move the database from live to test to dev, doesn't that also mean you are moving the user tables? I am working on a production site that has a bunch of users, both official contributors and public users. We won't advertise the test site address, but if someone were to find it they would be able to log in, right? How do you deal with this issue? Or if you are testing something that sends emails to all users of a certain type, and the user database is duplicated, you wouldn't have a proper testing environment.
Am I looking for trouble where none is likely to occur? Or is it just a matter of excluding the user tables when you do the backup and migrate? Or does that cause other problems?
Thanks for any help.
And thanks again for the great screencast.
Excellent screencast, Thank
Excellent screencast, Thank you!
Are you planing to do a screencast about data migration between different environments you gave as an example (dev/test/live) any time soon?