Drupal: Making our build system better
Hooray! We have running code, and we’re about to make another release after our code exits quality assurance. This means, of course, that we’ll need some way to differentiate the inevitable bugfixes that the next production release will require, and development of new features.
What’s the best way to do this? Making a release branch seems like a good idea. Here’s how I did it:
svn copy http://subversion.example.com/myproject/trunk http://subversion.example.com/myproject/branches/release-1
Bugfixes for release-1 will be committed to the release-1 branch, while new development continues on trunk. Bugfixes will be periodically merged into trunk to make it easier to roll the next release, which will be the release-2 branch.
Next, I need to configure my local system so that it’s easy to switch back and forth. I could work with a single source tree for local.example.com, but that means switching back and forth. The best thing to do would be to have two separate source code directories: one for trunk, and one for production releases.
svn co http://subversion.example.com/myproject/branches/release-1 /var/www/example.com-prod
For each site, I’ll need
- a source code directory
- a database
- entries in /etc/hosts
- entries in my Apache configuration
- a local site directory (ex: sites/dev.local.example.com) with settings.php
- a QA site directory (ex: sites/dev.qa.example.com) with settings.php
I’ll also need to update my Makefile to make it easier to work. For example, the Makefile should connect me to the right database depending on which branch I’m on. How do I determine this? One way is to have an unversioned file that overrides some of the Makefile variables, and to include that file in my Makefile. I can do this by adding the following to my Makefile:
-include *.mk
and then creating a dev-local.mk file that changes the values of my variables.
I’ll need copies of the production database translated for the different domains, which means I need to update my deploy script and format it a little to make it easier to deal with all these options. Hmm…
This will be fun.
UPDATE: Fixed HTML tags. Thanks for pointing it out!
(No Ratings Yet)
Loading ...
You’ve got some runaway PRE in that block entry there, Sacha. PS: love the blog, but are constantly amazed that IBM are interested in this stuff (when they flog WCM etc)
Blame ScribeFire for the PRE problem.
Thanks for pointing it out! I’ll use Wordpress’ built-in interface in the future.
IBM? WCM does a lot of things, but it may not be the best fit for all problems. Me, I tend to like working with lightweight systems, open source code, and thriving open source geek communities, and I’m thrilled that I can do that AND bounce up and down about collaboration and connection, all as part of my day job.