[support] Best way to deploy Drupal.
Seth Freach
sfreach at gmail.com
Mon Jul 13 15:10:14 UTC 2009
Unai,
Kathleen is describing two different tools that are both useful in
trying to achieve the results you are after. To expand a bit on the
"putting everything in code" approach: a view created by the views
module GUI interface might present some page or block to your liking,
that view is basically inside that environment's db. If you install
enable the views exporter module, you will have access to then export
that view as code, which will basically mean you can copy+paste it
somewhere. But where? ...Into your module's hook_views_default_views()
function. (http://drupal.org/node/99568). You've now taken your views
"settings" out of the db, and placed them into code that you can manage
and deploy from your svn repo.
For larger applications with many views, we find it cleaner and helpful
to place each coded view in its own view_name.views.inc.php file in a
views/ sub-directory in our module's main directory. At the bottom of
each individual view file, we add a necessary line that doesn't get
exported with the the view. This line populates the initially empty
$views array when the file is included in the hook:
<code>
$views[$view->name] = $view;
</code>
Then, our hook_views_default_views() function looks like follows:
<code>
function my_module_views_default_views() {
$view_files = file_scan_directory(drupal_get_path('module',
'my_module') . '/views', '.*\.views\.inc\.php');
$views = array();
foreach ($view_files as $file => $data) {
include $file;
}
return $views;
}
</code>
This export feature is key to getting different modules "settings" out
of the db and into a deployable form of code.
Seth
Unai Rodriguez wrote:
> Dear Kathleen,
>
> If we want to go for the second method (i.e. "put everything in code
> and update functions"), how do we do it? Is all this about using "Hook
> Update" (http://api.drupal.org/api/function/hook_update)?
>
> Thank you,
> unai
>
> On Mon, 13 Jul 2009 09:52:13 -0400, Kathleen Murtagh wrote:
>
>> 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/ ]
>>>
>> --
>> [ 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/cadd78d5/attachment-0001.htm>
More information about the support
mailing list