Development Seed
You're a developer
who uses drush
and has deployment issues
a. problems
Deploying is ugly
Standard way to deploy - commit everything to a project-specific svn repos
Better than nothing, but e.g. what version of the Date module is in your repos?
But what if you've got a devel version of Date
and you're running PHP5.3
Then they're not compatible
Also
SA-CONTRIB-2010-666 !!! (not a real SA)
But you haven't SEEN this site in four months
Say you upstream-fixed the module with patches
Have to now look at svn/git logs for e.g. that directory
And check a mix of upstream fixes, custom work etc.
A lot of detective work
Patches, fixes, client site already gone live, response on the issue
queue, not appropriate to mess with client's software... what do you
do?
Demo of basic drush
drush_make is how install profiles on d.o get packaged
It's not a Drupal module
So doesn't need a site itself
Install drush_make into ~/.drush
Never deploy "just Drupal" - you'll deploy more
core = 6.x
projects[] = drupal
projects[cck][subdir] = "CCK"
projects[cck][version] = "x.x"
; As we're pulling out of CVS, drush_make can't autodetect
projects[date][type] = "module"
projects[date][download][type] = "cvs"
projects[date][download][module] = "contributions/modules/date"
projects[date][download][revision] = "DRUPAL-6--2:2010-10-06"
; Or URL-based - git, mercurial, bazaar
projects[litecal][type] = "module"
projects[litecal][download] = "git"
projects[litecal][download][url] =
"git://github.com/developmentseed/litecal.git"
Just assemble codebase
% drush make
Excluding drupal --no-core
creates a sites/all/modules
or --contrib-destination
Why can't you generate the make file automatically from Drupal?
For example, the CCK project is not cck.module, it's content.module
Drush_make does not care about "modules" so much as projects
But Drupal internally does not know about projects
Patching
projects[prepopulate][patch][] = ...URL...
Get a listing of patches applied on each project
Random Javascript libraries
libraries[jquery_ui][download][type] = "get"
[download][url] = "http://..."
[directory_name] = "jquery.ui"
[destination] = "modules/contrib/jquery_ui"
Slow downloading?
Useful purpose for squid!
Reuse snippets of make files?
Recursion
If a project has a .make file, that itself will be run
Avoid it except with install profiles. It can get really confusing.
Inclusion
Reference another file
includes[] = ...
Tag versions, don't point at HEAD
... but how do you do this?
Buildkit
Profile .make
vs
Distro .make
distinction exists
Profile .make is used to make an install profile, with no core
You'll still want a project repository. It will be an install profile,
but it needs versioning.
But you have smaller project repositories
And separate repositories for your bits of custom functionality
More likely to patch and put on the issue queue
I never want to wonder "did we apply that patch to this site?"
Patches belong upstream. Let's keep them there. I don't want to fix
this bug by myself.
"Handling patches"
Oh, this patch went in. I can delete the patch and update to the new version
"Can drush pull from private version control systems?"
Yes. Works slightly differently e.g. git ssh keys
"Drush update command that updates the codebase. What happens to makefile?"
That's almost always a terrible idea. Look at revisions and know what
you're testing. This is definitely a parallel system to that, but it's
the better way of doing it.
1. Git revisions or tags?
Possible, but didn't mention how.
2. patch/download in "document" order?
Yes - it's a sequential array.
3. Advantage of all in svn - one big tag. Local checkout is live checkout. How do you know nothing's missing with this approach when you set up a new dev instance? How about a hybrid approach for existing big-svn clients
You can diff big filesystems rapidly these days. [also, modules like schema can analyse for missing modules] hybrid not recommended. This tool can build a project for you, but not so useful augmenting existing projects.
