<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Unai,<br>
<br>
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. (<a
href="http://drupal.org/node/99568">http://drupal.org/node/99568</a>).
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.<br>
<br>
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:<br>
<br>
<tt><code> <br>
$views[$view->name] = $view; <br>
</code></tt><br>
<br>
Then, our hook_views_default_views() function looks like follows:<br>
<tt><br>
<code><br>
</tt><tt>function my_module_views_default_views() {<br>
$view_files = file_scan_directory(drupal_get_path('module',
'my_module') . '/views', '.*\.views\.inc\.php');<br>
$views = array();<br>
foreach ($view_files as $file => $data) {<br>
include $file;<br>
}<br>
return $views;<br>
}<br>
</code></tt><br>
<br>
This export feature is key to getting different modules "settings" out
of the db and into a deployable form of code.<br>
<br>
Seth<br>
<br>
Unai Rodriguez wrote:
<blockquote cite="mid:20090713221050920861.f7b473a5@u-journal.org"
type="cite">
<pre wrap="">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" (<a class="moz-txt-link-freetext" href="http://api.drupal.org/api/function/hook_update">http://api.drupal.org/api/function/hook_update</a>)?
Thank you,
unai
On Mon, 13 Jul 2009 09:52:13 -0400, Kathleen Murtagh wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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 <a class="moz-txt-link-rfc2396E" href="mailto:me@u-journal.org"><me@u-journal.org></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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:
</pre>
<blockquote type="cite">
<pre wrap="">"Automating" deployment? To what degree do you expect this to be
</pre>
</blockquote>
<pre wrap="">automated?
</pre>
<blockquote type="cite">
<pre wrap="">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 <a class="moz-txt-link-rfc2396E" href="mailto:me@u-journal.org"><me@u-journal.org></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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
</pre>
</blockquote>
</blockquote>
<pre wrap="">with 12
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">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:
<a class="moz-txt-link-freetext" href="http://lists.drupal.org/pipermail/support/2007-May/004711.html">http://lists.drupal.org/pipermail/support/2007-May/004711.html</a>
I have not been able to understand from that how other people out
</pre>
</blockquote>
</blockquote>
<pre wrap="">there are
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">implementing automated deployment.
I found a number of links outside drupal.org:
</pre>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
<pre wrap=""><!----><a class="moz-txt-link-freetext" href="http://stackoverflow.com/questions/377629/drupal-deployment-testing-dont-how-to-call-it-tool">http://stackoverflow.com/questions/377629/drupal-deployment-testing-dont-how-to-call-it-tool</a>
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap=""><a class="moz-txt-link-freetext" href="http://stackoverflow.com/questions/282858/drupal-source-control-strategy">http://stackoverflow.com/questions/282858/drupal-source-control-strategy</a>
</pre>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
<pre wrap=""><!----><a class="moz-txt-link-freetext" href="http://nicksergeant.com/blog/drupal/painless-drupal-revision-control-cvs-and-subversion-shared-host">http://nicksergeant.com/blog/drupal/painless-drupal-revision-control-cvs-and-subversion-shared-host</a>
</pre>
<pre wrap=""><!----><a class="moz-txt-link-freetext" href="http://nicksergeant.com/blog/drupal/my-thoughts-small-scale-drupal-development-production-environments-cvs-and-subversion">http://nicksergeant.com/blog/drupal/my-thoughts-small-scale-drupal-development-production-environments-cvs-and-subversion</a>
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap=""><a class="moz-txt-link-freetext" href="http://www.workhabit.com/labs/autopilot">http://www.workhabit.com/labs/autopilot</a>
<a class="moz-txt-link-freetext" href="http://www.dave-cohen.com/node/1066">http://www.dave-cohen.com/node/1066</a>
<a class="moz-txt-link-freetext" href="http://www.garfieldtech.com/blog/drupal-dev-server">http://www.garfieldtech.com/blog/drupal-dev-server</a>
I have been working with Drupal's DEPLOY Module
(<a class="moz-txt-link-freetext" href="http://drupal.org/project/deploy">http://drupal.org/project/deploy</a>). Also I am trying to contact
</pre>
</blockquote>
</blockquote>
<pre wrap="">Workhabit
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">(i.e. Autopilot guys).
I have not found yet a solid approach to automate deployment.
</pre>
</blockquote>
</blockquote>
<pre wrap="">Would anyone
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">through me some pointers on how to do it? How are you guys doing this?
Thank you so much,
unai
--
[ Drupal support list | <a class="moz-txt-link-freetext" href="http://lists.drupal.org/">http://lists.drupal.org/</a> ]
</pre>
</blockquote>
<pre wrap="">
--
[ Drupal support list | <a class="moz-txt-link-freetext" href="http://lists.drupal.org/">http://lists.drupal.org/</a> ]
</pre>
</blockquote>
<pre wrap="">--
[ Drupal support list | <a class="moz-txt-link-freetext" href="http://lists.drupal.org/">http://lists.drupal.org/</a> ]
</pre>
</blockquote>
<pre wrap="">
--
[ Drupal support list | <a class="moz-txt-link-freetext" href="http://lists.drupal.org/">http://lists.drupal.org/</a> ]
</pre>
</blockquote>
<pre wrap=""><!---->--
[ Drupal support list | <a class="moz-txt-link-freetext" href="http://lists.drupal.org/">http://lists.drupal.org/</a> ]
</pre>
</blockquote>
</body>
</html>