development workflow

"practical advice for avoiding [delivering broken software with Scrum] – whether you’re an Organizer or you’re an Activist Developer"

The key problem identified is that incentive to abandon code quality to meet time/budget and feature goals.

The solution is to, first, not allow tests, in code, automated, or human, and other issues of code quality to be cut off from the features that are being built. Hide the time in the task estimates if absolutely necessary.

But also:

Update: Just set it up to be automatic.

For all new projects:

git config --global branch.autosetuprebase always

For existing projects:

git config branch.master.rebase true

Courtesy Randy Fay's blog post, "Simpler Rebasing (avoiding unintentional merge commits)"

git pull --rebase
rebasing applies your changes on top of the fetched commits.

Inherit local-only options with 'parent'

Parent is not working across files. Filed support request: http://drupal.org/node/1262230

In an aliases file that lives with your project, so for our SDL project, sdl.aliases.drushrc.php, put in all settings that are true no matter who is using Drush and from where. This is the settings for an externally hosted development collaboration site.

http://grayside.org/node/93

To consider for Agaric. We don't have one big project so i'm not sure how useful per-project configuration will be...

When you run drush sql-sync @example.prod @example.dev you do not have exactly what is on your example production site. Tables that do not exist on production but do exist on your local development site will still exist.

You need to drop all tables in the database, or simply drop and re-create the database, first.

Based on Greg Anderson's chapter in the Definitive Guide to Drupal 7.

drush sql-sync @dgd7.prod @dgd7.local

Prerequisites

A dgd7.aliases.drushrc.php file in a ~/.drush directory (that's a .drush folder in your home directory) that contains something like:

Working on a site (DefinitiveDrupal.org) which is in its own big Git repository. But when working on a module that's custom to the site but probably will become generalized and contributed back, we simply git init in that module's directory to make it a repository too. No git submodules or other voodoo. In addition to getting us an independent commit history for that module, it gives us the ability to throw that module into other situations and work on it there.

Create a custom module that will display special upgrade instructions right on the Update Status report page. This custom module can have a directory of includes for each module with custom instructions.

Some modules have libraries (RDF, WYSIWYG) that would be wiped during a typical upgrade. Some projects require patching a module. Sometimes a module is purposely left not-upgraded because the upgrade causes bugs (either due to dependency on custom code, or because the upgrade path is broken).