Posted by Chris Graham on November 10, 2011 at 11:49am
Hi all,
I'm looking at (finally) getting around to using GIT, mainly to keep a history of theme changes.
Just wondering if people could share their opinions on what should be stored in the repositories. I've seen everything from people just storing the theme they are working on to the entire Drupal install (minus the settings.php file).
I was considering just the sites folder, but I'm wondering if maybe I should go for the entire Drupal install?
What are people's views?
Cheers,
Chris
Comments
Matter of Preference
I used to store just the site - so whatever was under sites/default only.
But now I store a complete copy of the project - all of drupal.
This makes it easier to share - just clone the repo - and you're good to go.
I clone all of Drupal from Drupal.org and branch from there.
Updating Drupal is as simple as
git fetchgit merge 7.x [where x is the newest release tag]
Modules are downloaded and updated using drush, and then stored in the repo.
Future plans include looking at
http://drupal.org/project/dog
as it matures further.
I may go back to drush make files again - but not just yet.
I never got a good workflow for rebuilding a project in-place going.
Like Alan I also put the
Like Alan I also put the whole site into Git, though I don't carry around the whole history of core and instead do point upgrades. It's not as easy as git merge 7.9, but I prefer keeping my git log cleaner, as I don't want to see all the core commits in there. There might be a way to trim these down actually, maybe with some rebase magic, but for now I've been using Drush and regular tarball downloads.
Believe it or not, I also keep my db in the same repo! I use the Drush dgb command to make the database dump Version Control Friendly and strip all the useless data like the cache tables, search index, etc... I store the database dump outside the Drupal root, and same for the 'files' directory which is symlinked from sites/default/files. So here is the file structure of a typical project repo:
.git.gitignore
drupal
databases
files
Maybe in the future I will keep the 'sites' directory at the root of the git repo as well, so that 'drupal' only contains core and is easy to upgrade, provided you maintain the right symlinks.
Note the .gitignore in the git root, where I can put my own rules without having to fork the core .gitignore, which is one level lower in the drupal directory. Here is its content, which allows to only backup the uploaded files you only care about, and ignore the various js/ccs/image caches which can be regenerated when needed, etc.:
drupal/sites/default/settings.phpfiles/css/
files/ctools/
files/js/
files/styles/
This setup works for both the development workflow (made it easy with branches and cherry-pick for hotfixes). But most importantly, this also takes care of my back up, which can be easily made redundant with git fetch!
I've tried several approaches
I've tried several approaches - I started off storing everything in vc (minus settings.php), was using svn:externals on the modules, libraries, and themes directories for a while to pull in separate repositories from local vendor branches. Now, I think I've hit on the best that there is out there at the moment, with the possible exception of dog, which doesn't seem like its ready for the prime time yet...
We use a drush make file to describe the platform (actually, several drush make files usually - usually a platform make file which includes the drupal core, references to installation profiles specific to the site(s), and a base make file which contains stuff common to most sites that will run on the platform). We have separate git repositories for any custom modules and themes, which are included in either the base make file (if they are common) or the site(s) specific installation profile make files. We also have a git repository to hold the platform make files, and a git repository for each installation profile.
A lot of git repositories - but it makes for a very good level of control, reduces duplication, and its really easy to work with using drush and drush make. Because this way, all you are really versioning (in terms of the platform) is a couple of text files that detail everything in the platform (core, modules, patches, libraries etc), and we can build up a new copy of the platform in a matter of minutes by running drush make on the platform.make file. The make file is really easy to read, so you can very easily see exactly what modules and patches are in use. Commenting the make files really helps to, so that others who work with it know why specific patches have been used.
For deployment, we have an aegir master server that hosts shared staging and development sites, and we also use this to manage and push code out to live environments on remote servers. For upgrading, new a new version of a platform is built from an updated drush make file, imported into aegir, and then the live site is migrated onto it (aegir handles this). Developers use drush sql-sync and drush-rsync to move database and files between instances of the site. So getting a local environment is as simple as:
Check out the platform git repo
Run drush make on the make file to build the platform
Create a database
Create Settings.php
drush sql-sync the database
drush rsync the files
drush cc clear the cache
Here are a few good good resources on Aegir and Drupal installation profiles.
mig5's aegir overview article:
http://greenbeedigital.com.au/content/introduction-aegir-hosting-system
A more in-depth discussion with some useful diagrams:
http://greenbeedigital.com.au/content/drupal-deployments-workflows-versi...
Discussion on installation profiles and Aegir deployment scripts:
http://greenbeedigital.com.au/content/developing-aegir-extending-aegir-a...
The Aegir documentation project:
http://community.aegirproject.org/notebook
The Aegir discussion group:
http://community.aegirproject.org/discussion
The only real issue I have with this at the moment, is the time it takes to build a platform (passive time, whilst everything is downloaded from all over the internet) - but setting squid up as a proxy cache, you can reduce the time a lot.
--
Tom
www.systemseed.com - drupal development. drupal training. drupal support.
Drush Make and git bisect
Hi Tom,
This is probably a more general question for Drush make,
but how do you combine Drush make with git bisect.
Git bisect is a great way to comb through your git history to find a bug, and has even helped a core miantainer.
But using Drush make would mean you'd have to 'rebuild' each time you checked out a commit, right?
Which would be too slow, right?
Git bisect has proven its worth to me lately.
One bizare bug crept into a site in development and wasn't noticed for weeks [real edge case stuff].
I knew it was working in the past, so by using git bisect, I was able to find the commit that broke it.