Room:
Colorado
Time slot:
March 10th, 10:00 AM - 11:00 AM ** This BOF is not about using Git for module development on drupal.org **
Git is such a powerful tool, and really opens the door for managing our projects, code, and builds more effectively. So let's figure out how to do so!
* How can we effectively use Git to manage a Drupal project?
* How do we keep multiple developers and features separate, yet co-existing?
* What strategies exist for Git-based development?
* What Git tools are most useful?
I'll share the workflow I've been using pretty effectively, but I'd love to know what others are doing.
Diamond Sponsors
|
|
|
Download the Mobile App
View maps, schedule information, speaker bios and more all from the palm of your hand with the DrupalCon mobile app for What's Happening
Sunday, March 6
- Badge Pickup and On-Site Registration
Monday, March 7
- Pre-Conference Training
- Exhibit Hall Opening Reception
- Badge Pickup and On-Site Registration
Tuesday, March 8
- Dries Buytaert Keynote
- Sessions, Core Conversations, Birds of a Feather, and Day Stage
- Opening Night Party at the Field Museum
Wednesday, March 9
- Clay Shirky Keynote
- Sessions, Core Conversations, Birds of a Feather, and Day Stage
Thursday, March 10
- Jared Spool Keynote
- Drupal Means Business
- Sessions, Core Conversations, Birds of a Feather, and Day Stage
- Drupal Trivia Night
Friday, March 11
- Sprints
Comments
FANTASTIC session
Really enjoyed this session. Fantastic information.
Thanks everyone
Thanks everyone for coming out… should have reserved a bigger room! Here's a couple of the resources I demonstrated:
* Git branching model
* Drupal Git development model
* Sample .gitconfig
* .profile additions
Templates
Great BOF!
In your branching documentation, the first section titled "Setup" mentions cloning with a template. Could you post a link to an example template, or to some good documentation/tutorials that explain how to use templates?
I presume these templates setup the safe guards for the prod branch so only you may merge into it?
Technical vs. Conceptual
One thing I wanted to reiterate is that none of what I presented and/or discussed is meant to be taken as a technical solution. Rather, I presented the conceptual model I feel should be adopted. Namely, separate feature branches that can be independently developed, tested, and deployed.
The tools to do this effectively do not currently exist, so I created my own. They are not robust enough for everyone, and ones I do not want to maintain. But they are the easiest way I could come up with using the tools we have available now.
As Sam pointed out, submodules are theoretically the solution, but are a PITA to use effectively in their current form. So I've written them off until we can build the tools to use them better. Maybe if anyone's interested we can start working on this tomorrow in the sprint?
It's my hope we can create drush commands to help with this process, and have the general concepts built into build tools like Pantheon. Let's keep this conversation going.
The feature branch testing
The feature branch testing and deployment process being key IMO. Developing on branches is pretty easy to learn and do, but if you can't actually test your work independently of it being merged into the mainline, then it's still just a hope and a prayer that your work is good.
site
http://nvie.com/posts/a-successful-git-branching-model/
non-source site elements
I hope I can make it to this. My departure time Thursday morning is in flux.
Whether I can or can't, I hope you can find some time to discuss what I consider to be the primary issue with replicating and deploying complete sites from any repository: that important elements of a Drupal site are in the database, not code.
Those elements include all the data created through the admin interface: blocks, menus, views. While each has a code analogue (hook_menu, hook_block, etc.), the reality of site design is that most site builders use the admin interface to manage stuff like this. So many site definitions are in the database, which is not easily poured into a repository short of cloning the database itself and which operation also clones the content.
Let us know what you're thinking. I'm all for having consistent, reasonable ways to manage and distribute code. But this stopped being a code-based design tool a long time ago.
My feeling is that this,
My feeling is that this, while a very important question, is out of scope for this discussion. The config/content deployment problem is an exceedingly well-known problem space, but aren't particularly affected by the particular VCS you're using to manage your sites. If folks are more interested in talking about this, well of course - it's a BoF! - but I think it makes more sense to focus on things that are actually different now that we're on Git.
I'll be there! and...
I would (kinda strongly) suggest retitling this to "Git workflow for Site Builders." That'll bring it in line with what we've got on the docs page:
http://drupal.org/documentation/git
This is a REALLY important topic. I've already duked it out over the dev list a bit - see http://lists.drupal.org/pipermail/development/2011-March/037615.html and the follow-ups in that thread. I'm pretty strongly of the belief that while there is and always will be more than one way to do it, we actually can come up with a couple very clearly *right* ways to do it when it comes to deploying Drupal sites. Period. Hopefully we can make some progress on that idea here :)
OK, renamed the session with
OK, renamed the session with your suggestion as inspiration (though altered because it's not just site builders I have in mind).
Looking forward to this discussion!
Fair nuff :) Lookin forward
Fair nuff :) Lookin forward to it, as well!