User login

development workflow

Preventing Agile Scrum methodology from degrading code quality

"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:

Git rebase workflow and git ahead and behind messages

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.

Settings for sets of sites: Putting Drush configuration into your project repository

Inherit local-only options with 'parent'

Parent is not working across files. Filed support request:

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.

Tell Drush to Check your Git Repository for Configuration

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

Gotcha: drush sql-sync does not drop existing tables

When you run drush sql-sync 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.

Use Drush to sync the database from one site to another

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

drush sql-sync @dgd7.local


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

Cloning git locally to test a Drupal module in development on multiple sites

Working on a site ( 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.

Hook into Update Status report to list special upgrade instructions

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).

Syndicate content