[support] Best way to deploy Drupal.

Mon Jul 13 13:52:13 UTC 2009

There are three main methods for managing the database when deploying from
one workspace to another.

The most common is "write down, or script your database configuration
settings and repeat them in the next workspace."  This is where people
generally start out as it is the easiest, conceptually, to understand.  It
is both prone to human error and tedious, though.

The second method is "put everything in code and update functions."  This is
the most recommended method because it is scalable both for very small and
very large projects.  It is also the most complicated because it requires
adept programmers and takes away all the nice gui tools that makes Drupal
development so accessible.  There is progress towards this front, though.
There is a movement to provide more "exportables" that will allow a
developer to use the web gui to configure something, export the settings,
and place it into code.  Views currently supports this method out of the
box.  The "features" module is starting to give exportable support to other
areas.

The last, and rarely used, method is "put the database in version control,
and merge databases."  This is probably the most difficult to understand
conceptually, but fairly scriptable allowing non-programmer developers to
use the web gui and contribute to a project.  It is great for small
projects, and becomes increasingly more difficult the larger and larger the
database (the restriction is your developer's computing power, but a
production database exceeding 500mb would start to require extra finesse to
manage).  The "dbscripts" module provides an extensive amount of scripts in
order to use this method.

I use my version control system to deploy to a workspace from the primary
repository.  I don't need to worry about settings.php because I do not
include that in version control.  I set the database configuration settings
once, and then never erase that file again.  If you do have other settings
being used in settings.php, you could put the database connection settings,
and any other workspace-specific settings in a separate file and include
that file in settings.php.  Manually updating the workspace-specific
settings would then only be required when they change  (e.g.: adding Google
Analytics to production, while keeping it disabled in development and
testing).

I don't use a "one click" deploy, however, I generally just have to run "svn
update" or "svn switch".

If you use the "put everything in code and update functions" method, you can
install drush and have drush run update.php for you.  Your script would then
just say something like, "svn update && drush updatedb" or "svn switch &&
drush updatedb".

If you use the "put the database in version control, and merge databases"
method, then you would restore the appropriate database for the given
workspace.  For development and testing, your script would just say
something like, "svn update && ./dbscripts/restore.php none".  For
production, you would first  merge the development and production databases,
commit the merged databases and then deploy.  The final deploy script would
be something like, "svn switch <release branch> && ./dbscripts/restore.php
production min".

--
Kathleen Murtagh

On Mon, Jul 13, 2009 at 9:04 AM, Unai Rodriguez <me at u-journal.org> wrote:

> Dear Kathleen,
>
> Thank you so much for your reply.
>
> I guess we would like our deployment process to be somewhat similar to
> what we use in other projects; a number of developers are writing code
> while testing on their local machine first (aka developer sandbox).
> Each developer's machine has a web server and database server with a
> copy of the code. Once a developer is sure that her stuff is working
> fine on her sandbox that is the time when she will commit it into our
> version control system (i.e. we use subversion).
>
> We have a server that takes care of the automated deployments. That is,
> any developer can access a web-based interface, input her user/password
> and click one button. This button will deploy the build which is
> currently on the trunk in subversion and put it into the development
> server; also some other things will take place like copying the proper
> settings.php file (in drupal's case) to the proper server(s).
>
> >From the web-based interface a developer can deploy to any of the 3
> environments: development, staging or production. Usually development
> is where developers test (plus their sandboxes). Our Quality Assurance
> team takes care of testing the staging and production servers. That
> means deployments to these two environments are more controlled.
>
> The deployment process is automated, meaning, you can push the code to
> any environment upon clicking one button. The process takes care of
> deploying the right code in the right place plus the configuration
> files (in this case settings.php).
>
> We have been doing this for a while, I think is pretty standard.
>
> Now, for Drupal is different since part of the "settings" are stored in
> the database, right? We are having a hard time getting the database
> settings to be applied over to the next environment (i.e. development
> to staging or staging to production).
>
> I have been testing the deploy module which is able to do something
> like this... My question is more along the lines of... What do you guys
> do? Do you just deploy manually (i.e. reproduce the settings from your
> sandboxes to development, then to staging then to production) or you
> found a way of having this automated?
>
> Thank you so much :-)
> unai
>
> On Mon, 13 Jul 2009 08:40:48 -0400, Kathleen Murtagh wrote:
> > "Automating" deployment?  To what degree do you expect this to be
> automated?
> >
> > I can't think of any situation in which you'd want deployment to be
> > done without observation and testing during the process.
> >
> > Can you elaborate on what sort of process you are expecting?
> >
> > --
> > Kathleen Murtagh
> >
> >
> > On Mon, Jul 13, 2009 at 4:53 AM, Unai Rodriguez <me at u-journal.org>
> wrote:
> >> Dear All,
> >>
> >> We are building a somewhat complex site based on Drupal which features
> >> redundant servers at all levels of the system. We are starting of with
> 12
> >> machines. We currently have three environments: development, staging and
> >> production.
> >>
> >> We are having a hard time setting an automated deployment mechanism.
> >>
> >> I have searched on the archives but was able to find this thread only:
> >> http://lists.drupal.org/pipermail/support/2007-May/004711.html
> >>
> >> I have not been able to understand from that how other people out there
> are
> >> implementing automated deployment.
> >>
> >> I found a number of links outside drupal.org:
> >>
> >>
>
> http://stackoverflow.com/questions/377629/drupal-deployment-testing-dont-how-to-call-it-tool
> >>
> http://stackoverflow.com/questions/282858/drupal-source-control-strategy
> >>
>
> http://nicksergeant.com/blog/drupal/painless-drupal-revision-control-cvs-and-subversion-shared-host
> >>
>
> http://nicksergeant.com/blog/drupal/my-thoughts-small-scale-drupal-development-production-environments-cvs-and-subversion
> >> http://www.workhabit.com/labs/autopilot
> >> http://www.dave-cohen.com/node/1066
> >> http://www.garfieldtech.com/blog/drupal-dev-server
> >>
> >> I have been working with Drupal's DEPLOY Module
> >> (http://drupal.org/project/deploy). Also I am trying to contact
> Workhabit
> >> (i.e. Autopilot guys).
> >>
> >> I have not found yet a solid approach to automate deployment. Would
> anyone
> >> through me some pointers on how to do it? How are you guys doing this?
> >>
> >> Thank you so much,
> >> unai
> >> --
> >> [ Drupal support list | http://lists.drupal.org/ ]
> >
> >
> > --
> > [ Drupal support list | http://lists.drupal.org/ ]
> --
> [ Drupal support list | http://lists.drupal.org/ ]
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.drupal.org/pipermail/support/attachments/20090713/7b4c8afe/attachment.htm>