So, there you are. You have your production site in Drupal. You have the database tables and code stored in the version control software of choice (cvs, svn, git, mercurial, whatever).
But, of course, you are constantly developing new modules, testing new configurations, etc. on your dev site.
1. What processes have worked for capturing versioning info in your version control software? 2. What processes have worked to support sane workflow from qa or dev to production? 2a. How on earth do you sanely capture configuration data for each module?
ari
On 27/05/10 16:38 -0400, Ari Davidow wrote:
So, there you are. You have your production site in Drupal. You have the database tables and code stored in the version control software of choice (cvs, svn, git, mercurial, whatever).
But, of course, you are constantly developing new modules, testing new configurations, etc. on your dev site.
- What processes have worked for capturing versioning info in your
version control software? 2. What processes have worked to support sane workflow from qa or dev to production? 2a. How on earth do you sanely capture configuration data for each module?
I found this guide very helpful.
regards Rolf
On Fri, May 28, 2010 at 4:52 AM, Rolf Kutz rk@vzsze.de wrote:
On 27/05/10 16:38 -0400, Ari Davidow wrote:
So, there you are. You have your production site in Drupal. You have the database tables and code stored in the version control software of choice (cvs, svn, git, mercurial, whatever).
But, of course, you are constantly developing new modules, testing new configurations, etc. on your dev site.
- What processes have worked for capturing versioning info in your
version control software? 2. What processes have worked to support sane workflow from qa or dev to production? 2a. How on earth do you sanely capture configuration data for each module?
I found this guide very helpful.
regards Rolf
Yes, that is a beautiful explanation of git. I am still trying to think about the best way to deal with drupal configuration issues, to note module dependencies, and to deal with the fact that in a cms database, because of all of the auto-numbering dependencies, we have a model where we have successfully merged content and code--exactly where we didn't mean to be ;-). This may all clarify as I move forward.
ari
On 28/05/10 09:50 -0400, Ari Davidow wrote:
Yes, that is a beautiful explanation of git. I am still trying to think about the best way to deal with drupal configuration issues, to note module dependencies, and to deal with the fact that in a cms database, because of all of the auto-numbering dependencies, we have a model where we have successfully merged content and code--exactly where we didn't mean to be ;-). This may all clarify as I move forward.
I haven't found a perfect solution for that, yet, especially for the problem of switching between production and development version on a development server. Syncing the configuration (aka the database) between the two is kind of lossy, so you end up using two different installations and databases. This should be simple to manage with git.
regards Rolf
I'm a proponent of packaging settings into code (out of the DB) with the Features module, along with sharing content changes between development and production (either way) with Deploy and Services. And then you have your settings to check-in to Git repositories for tracking and "easier" deployment.
However, each project needs its own customized plan, and there's currently no ultimate method. It's also going to take time for the DB vs. Code argument to resolve in the Drupal community. Drupal 8 or 9?
On May 28, 2010, at 08:02 AM, Rolf Kutz wrote:
On 28/05/10 09:50 -0400, Ari Davidow wrote:
Yes, that is a beautiful explanation of git. I am still trying to think about the best way to deal with drupal configuration issues, to note module dependencies, and to deal with the fact that in a cms database, because of all of the auto-numbering dependencies, we have a model where we have successfully merged content and code--exactly where we didn't mean to be ;-). This may all clarify as I move forward.
I haven't found a perfect solution for that, yet, especially for the problem of switching between production and development version on a development server. Syncing the configuration (aka the database) between the two is kind of lossy, so you end up using two different installations and databases. This should be simple to manage with git.
regards Rolf -- ... Expediency asks the question, 'Is it politic?' ... -- [ Drupal support list | http://lists.drupal.org/ ]
On 2010-05-28 12:24 , Kevin Davison wrote:
I'm a proponent of packaging settings into code (out of the DB) with the Features module, along with sharing content changes between development and production (either way) with Deploy and Services. And then you have your settings to check-in to Git repositories for tracking and "easier" deployment.
i have used Features for configuration; it's got a learning curve, but one that tends to enforce a discipline, and then you can use your preference of source control to manage versioned updates to your configuration; it's a great solution, though it has limitations; you can use custom modules with install hooks to capture other configuration that Features can't handle
i know of Deployment as a solution for content, but haven't used it; i think managing content is a much harder problem
[apologies if my reply from a different address also comes through; from past experience, i'm assuming that mailserver is on a blacklist]
There are several ways to implement the dev-staging-production but I guess the question here is to create a standard version practice, GIT is good, so is Features, I'm yet to know a way by which I can use them together and come to a point where I can revert to a revision and all my database changes are made accordingly. It has to be something that works with my versioning system. I do not have a solution with me yet, but have been waiting to get time to research/work on the same.
PS: I've worked with Migraine for dev-staging-production and it works fine for me but I aint very fond of the solution (http://bit.ly/c4IMUc)
Cheers, Mukesh
On Sat, May 29, 2010 at 12:45 AM, steve@mirapod.com wrote:
On 2010-05-28 12:24 , Kevin Davison wrote:
I'm a proponent of packaging settings into code (out of the DB) with the
Features module, along with sharing content changes between development and production (either way) with Deploy and Services. And then you have your settings to check-in to Git repositories for tracking and "easier" deployment.
i have used Features for configuration; it's got a learning curve, but one that tends to enforce a discipline, and then you can use your preference of source control to manage versioned updates to your configuration; it's a great solution, though it has limitations; you can use custom modules with install hooks to capture other configuration that Features can't handle
i know of Deployment as a solution for content, but haven't used it; i think managing content is a much harder problem
[apologies if my reply from a different address also comes through; from past experience, i'm assuming that mailserver is on a blacklist] -- [ Drupal support list | http://lists.drupal.org/ ]
On 2010-05-28 07:50 , Ari Davidow wrote:
I am still trying to think about the best way to deal with drupal configuration issues, to note module dependencies, and to deal with the fact that in a cms database, because of all of the auto-numbering dependencies, we have a model where we have successfully merged content and code--exactly where we didn't mean to be ;-).
configuration can be managed with Features and related modules which create a system to write out configuration as a module which can be versioned, updated and managed via the Features UI; there has been quite a bit of work to make this a robust solution, but it takes some work to get used to it; the project page is a good starting point:
http://drupal.org/project/features
content is harder, but there are tools like Deployment that attempt to tackle the problem; haven't used it, so maybe someone else can elaborate on that or other methods
Ari Davidow wrote:
Yes, that is a beautiful explanation of git. I am still trying to think about the best way to deal with drupal configuration issues, to note module dependencies, and to deal with the fact that in a cms database, because of all of the auto-numbering dependencies, we have a model where we have successfully merged content and code--exactly where we didn't mean to be ;-). This may all clarify as I move forward.
I couldn't figure out a good answer to the question either -- "How do you do version control and concurrent operation/ development/ testing on a Drupal site?".
I became acutely aware of Drupal's version control/ concurrent development problems when I migrated from 5.x to 6.x. After several attempts, I ended up with the following process: back-up and check-in the production site, check-out and restore on a development server, figure out how to upgrade on the development server (uninstall modules, upgrade code and data to latest 5.x, fix database issues I likely created, back-up code and data, do a fresh install of 6.x, restore and upgrade data, back-up code and data, and forget about additional modules and their data), take the production site off-line (via htdocs link), repeat all the upgrade work on the production site, test, back-up, check-in, and put the production site online. It was tedious and time-consuming. I had to sacrifice functionality and associated data to succeed. (Fortunately, I didn't have much non-Core content in the first place.)
I view these version control/ concurrent development problems as a fundamental architectural flaw in Drupal. I suspect that the solution will require a utility for merging concurrent edits to the database, preserving referential integrity and accounting for code/ data structure/ schema versions. It's a non-trivial task, to say the least. Until this problem is solved, I will continue to run Drupal 6.x pretty much OOTB (with only the Core and Backup and Migrate modules).
I would be curious to learn of other CMS's that get it right.
HTH,
David
On 28/05/10 10:18 -0700, David Christensen wrote:
Ari Davidow wrote:
Yes, that is a beautiful explanation of git. I am still trying to think about the best way to deal with drupal configuration issues, to note module dependencies, and to deal with the fact that in a cms database, because of all of the auto-numbering dependencies, we have a model where we have successfully merged content and code--exactly where we didn't mean to be ;-). This may all clarify as I move forward.
I couldn't figure out a good answer to the question either -- "How do you do version control and concurrent operation/ development/ testing on a Drupal site?".
Does anybody have experience with this:
http://drupal.org/project/dbscripts
regards Rolf
-
Ari Davidow -
David Christensen -
dsupport＠paper-ape.com -
Kevin Davison -
Mukesh Agarwal -
Rolf Kutz -
steve＠mirapod.com