Build Systems & Change Management

For the Drupal sites I am working on I have a setup using three different stages:

1. R&D site - This one is for both testing contributed modules and my own development.
2. Staging - A virtual copy of the live site to make sure that the things from the R&D site will work. Also used for testing updates/upgrades to core and contributed modules before they go live.
3. Live site - Simply the live public site where all ends up after passing the two above.

This is a long post, grab a cup of tea... (or better still a beer)

I manage a small team (currently 3 soon 5) of grographically distributed developers developing and maintaining a few (currently 4) projects in different stages of the lifecycle. I am familiar with managing teams developing web applications but up until now my Drupal experience has been largely solo. Developing large Drupal projects and working in a team is relatively new to all the other devs so I see this as an opportunity to encourage a sound development process using the appropriate tools.

Release Management Engineer (Woodland Hills, CA)

I'm using Drupal on Fedora. Specifically, I'm using an RPM installation of Drupal 6.9 that I backported to Fedora 8. As it's way too easy to screw up an RPM-based installation of pretty much anything by mixing in code outside of the pkg mgmt system (I don't suppose anyone can guess how I found that out), when the need arose to use the admin_menu, FCKEditor and IMCE packages arose here, I wrote .spec files and turned the tarballs on the drupal.org site for the aforementioned modules into SRPMs and RPMs.

Hi folks,

it seems this group stalled a little bit, so lets try to give it some activity :-) I was wondering if this group has already collected some best practices around Drupal deployment and change management. So far, I have only found best practices for managing the source code of a drupal site, but I have not found anything how to transport configuration changes (done in the DB) from a devel environment to a production environment. As far as I can see there are no stable modules or scripts for that, at least not for D6. Any ideas where to look?

Regards,

Sebastian

I'm investigating Drupal as an internal Sourceforge alternative. I'm having trouble understanding how the Project Manager works with issues and subversion repositories. Is there any GOOD documentation that explains how to the PM module/Drupal interact with repositories?

I'm familiar with Trac or GForge, where a project is directly tied to a specific repository and any commits you make against a specific issue are added to that ticket.

This is easy and quick, nothing fancy, no voting - just post your session idea (title) and your name/contact info and show up to present that day! We have sessions open from 10am-2pm each day (Saturday and Sunday) and each session should plan for 45 minutes each.

http://groups.drupal.org/node/12528 (edit wiki page)

If you can't see or edit the wiki page, be sure to join our group which may be required for editing the wiki page.

If you are interested in participating in a panel on Drupal infrastructure, development environments, deployment, and best practices please indicate what you are interested in presenting. I am hoping to get some experts in best practices to do a tutorial.

First, for those that don't want to read the full post, here's the "30-second elevator speech":
This post to to discuss using Seleinum with Drupal. Specifically using Maven to run the selenium tests and writing the Selenium tests in Java.
The example code be downloaded from the Workhabit Inc. public repository here: https://svn.workhabit.com/svn/public/drupal/selenium/trunk
One must have the following installed to run:
1. Firefox
2. Java 1.5+
3. Maven
All 3 are easy to install and aquire. Once you download the code from the repository, you can just navigate to the directory and run:

If you are interested in seeing Drupal, and in particular a specific profile be included in OpenSolaris, Friday is the deadline for the next meeting.

Submit your comments here:

http://www.opensolaris.org/jive/thread.jspa;jsessionid=2A66929A74E346D56...

If you are interested in seeing Drupal, and in particular a specific profile be included in OpenSolaris, Friday is the deadline for the next meeting.

Submit your comments here:

http://www.opensolaris.org/jive/thread.jspa;jsessionid=2A66929A74E346D56...

Hey folks,

I've worked on a number of Drupal sites where we needed to keep multiple sites in synch, and Drupal has been a challenge to keep that way because so many options are changed through the UI - this tends to show its weakness when we want to keep the settings across all sites (don't even mention content). Moving content types and views is easy with the import/export tools, but blocks are another story. The visibility rules, Roles, and input formats all require your time and attention to detail - time you could be spending working on other features.

Hey folks,

I've worked on a number of Drupal sites where we needed to keep multiple sites in synch, and Drupal has been a challenge to keep that way because so many options are changed through the UI - this tends to show its weakness when we want to keep the settings across all sites (don't even mention content). Moving content types and views is easy with the import/export tools, but blocks are another story. The visibility rules, Roles, and input formats all require your time and attention to detail - time you could be spending working on other features.

I have been working on a framework that attempts to address some of the issues of deploying code and data in Drupal. It is outlined here:

http://heyrocker.com/drupal/content/deployment-and-change-management-fra...

I'd love to hear people's thoughts on this.

I have been working on a framework that attempts to address some of the issues of deploying code and data in Drupal. It is outlined here:

http://heyrocker.com/drupal/content/deployment-and-change-management-fra...

I'd love to hear people's thoughts on this.

Written by Heyrocker.

I had been hoping to get together with people at Drupalcon this year to discuss issues surrounding deployment and change management. Unfortunately I will not be able to go. So this will have to act as my contribution to that discussion, which will hopefully carry on well beyond Boston. There are three parts - The Problem, Things That Help Now, and Some Ideas For The Future.

Written by Heyrocker.

I had been hoping to get together with people at Drupalcon this year to discuss issues surrounding deployment and change management. Unfortunately I will not be able to go. So this will have to act as my contribution to that discussion, which will hopefully carry on well beyond Boston. There are three parts - The Problem, Things That Help Now, and Some Ideas For The Future.

Tutorial Panel, 90 minutes:

Presenters (Panelists)

• Narayan Newton (OSUOSL)
• Milind Parikh (IBM)
• Sam Tresler (Advomatic)
• Eric Mandel (BlackMesh)
• Neil Giarratana (Lucidus Corporation)
  (Note that I have only included panelists who have been involved in the conversation for this presentation. There may be others interested or with whom I have not personally interacted with; this is not meant to be a slight...just giving the list as I knew it. NG)

Track

Site Building

Session Description

Is anyone interesting in having a brainstorming session on deployment and change/build management at Drupalcon Boston? This could either be an officially submitted proposal with an open agenda, or an unofficial get together in a side room at the conference center. It seems like a lot of us are struggling with enterprise-level deployment issues, and getting a bunch of smart and interested people in a room talking about their own solutions and brainstorming new ones would be useful for everyone. We all have our own ways of handling it and I'd love to hear other people's ideas.

Is anyone interesting in having a brainstorming session on deployment and change/build management at Drupalcon Boston? This could either be an officially submitted proposal with an open agenda, or an unofficial get together in a side room at the conference center. It seems like a lot of us are struggling with enterprise-level deployment issues, and getting a bunch of smart and interested people in a room talking about their own solutions and brainstorming new ones would be useful for everyone. We all have our own ways of handling it and I'd love to hear other people's ideas.

Now that Dries has concocted a business model that leverages core, I wonder if this is a good time to begin talking in earnest about making D7 into a manageable, upgradeable system with built-in change management features? Dries is one of only a few people with core commit privs in CVS, and as such, he's now perfectly positioned to listen and act on revisions to core that would make everyone's lives easier, but especially his new company's options or desires.

There's a need for small changes to Drupal that allow big business to leverage it to create and manage a system while being able to upgrade that system in a live setting.

Now that Dries has concocted a business model that leverages core, I wonder if this is a good time to begin talking in earnest about making D7 into a manageable, upgradeable system with built-in change management features? Dries is one of only a few people with core commit privs in CVS, and as such, he's now perfectly positioned to listen and act on revisions to core that would make everyone's lives easier, but especially his new company's options or desires.

There's a need for small changes to Drupal that allow big business to leverage it to create and manage a system while being able to upgrade that system in a live setting.

We're all building sites that have functionality based upon the nid, right? Why can't we break out of that mold of doing nodeapi adjustments to certain nodes based upon a sequentially incrementing number, and try to use something like auto_nodetitle.module to trigger from?

I'm envisioning a scenario like the one posed by jmburnz on http://drupal.org/node/140430#comment-227293 where he says:

A fair amount of content was added to the dev site before it was branched and went live (enough to populate each site section). At times I've needed some additional test content - that is no problem as I can just create it without worrying about what is going over on the live site.
We have used vids, tids & nids as you describe, but these were all set in stone before the site went live.

Well, kidlets, what happens when your node->nid isn't the same on both the live and dev server?

We're all building sites that have functionality based upon the nid, right? Why can't we break out of that mold of doing nodeapi adjustments to certain nodes based upon a sequentially incrementing number, and try to use something like auto_nodetitle.module to trigger from?

I'm envisioning a scenario like the one posed by jmburnz on http://drupal.org/node/140430#comment-227293 where he says:

A fair amount of content was added to the dev site before it was branched and went live (enough to populate each site section). At times I've needed some additional test content - that is no problem as I can just create it without worrying about what is going over on the live site.
We have used vids, tids & nids as you describe, but these were all set in stone before the site went live.

Well, kidlets, what happens when your node->nid isn't the same on both the live and dev server?

http://www.bryght.com/blog/roland-tanglao/10-minutes-on-drupal-deploymen... has an excerpt from a really great discussion that ensued at DrupalCampLA during Firebright's dissertation on how hard it really is to properly upgrade the featureset on a Drupal site that's live and active.

http://www.bryght.com/blog/roland-tanglao/10-minutes-on-drupal-deploymen... has an excerpt from a really great discussion that ensued at DrupalCampLA during Firebright's dissertation on how hard it really is to properly upgrade the featureset on a Drupal site that's live and active.