[development] Workflow: staging server, source control, and the files directory

[Randy Fay]

My opinion is that nothing in the files directory should ever be in source
control - that will just cause pain. Those are transient, website-created
files. They even have the wrong permissions typically to be managed
successfully. They should be backed up, and on fancier website
configurations need to be shared or synced, but should not be in source
control.

If you have files that *are* "assets", but not user-generated (like graphics
files that don't go with the code) they might go in an "assets" directory at
the webroot or above, and be under source control there.

-Randy

On Fri, Feb 18, 2011 at 3:14 AM, Andy Fowlston <andy at pedalo.co.uk> wrote:

> Hi all,
>
> I have a question about people's practices using a staging server and
> source control. I'm keen for us to have a sensible workflow while developing
> sites, and currently we have the following setup.
>
> * Developers have local copies of the site where they develop new
> functionality, which they check in to source control (Subversion).
> * The staging server has a checked out version of the repository.
> * The repository has a post-commit hook that automatically updates the
> staging server.
> * There are some changes we make directly via the staging server (ie not in
> code) and for that there's a script that clears caches, dumps the database,
> and stores that in the repository. (We try to keep as much in code as
> possible.)
>
> Things have been working well so far, but just recently we started adding
> content to the site (on the staging server). The problem comes with
> uploading files via the wysiwyg editor, as this bypasses the normal
> mechanism of checking into source control and letting the post-commit hook
> update the staging server automatically. So the question is, what's the best
> way to keep the staging server's files directory synced with the repository?
> I'd like to keep things as automated as possible. Here's some ideas:
>
> * On some event (eg. post-commit, cron) I just do something like a simple
> svn add files/*. This won't prune nicely though.
> * Exclude the files directory from source control altogether, and change
> the local update process to just copy from the staging server's files
> directory to the local. This would work, just feels slightly wrong to me as
> the db contains content that refers to the files, and that *is* in source
> control.
> * Maybe I could treat the files directory as a vendor branch and use
> something like svn_load_dirs.pl to try and keep them in sync. I've not
> used this script before, and don't know if it would manage this simple
> situation automatically, or if it would need some manual help. I suppose I
> could also write a script to parse the output of svn st, but as always would
> prefer to keep the workload as low as possible :)
> * Nice super simple idea I've not considered?!
>
> I'd love to hear what other people in this situation do, or just any ideas
> at all.
>
> Many thanks,
>
> Andy
>
> . . . . . . .
> Andy Fowlston
> +44 (0)20 8747 5068
> andy at pedalo.co.uk
> Skype: andy.pedalo
> www.pedalo.co.uk
>
> This email is intended only for the above named addressee/s. This email may
> be confidential or legally privileged. If you have received this email and
> you are not a named addressee, you must not use, copy, distribute or
> disclose the email or any part of its contents or take any action in
> reliance on it. If you have received this email in error, please email the
> sender by replying to this message and delete it from your system. All
> reasonable precautions have been taken to ensure no viruses are present in
> this email.
>
> pedalo limited cannot accept responsibility for loss or damage arising from
> the use of this email or attachments and recommends that you subject these
> to your virus checking procedures prior to use. Any views or opinions
> presented are solely those of the author and not necessarily those of Pedalo
> Limited
>
> Please consider the environment before printing this email
>



-- 
Randy Fay
Drupal Module and Site Development
randy at randyfay.com
+1  970.462.7450
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20110218/dc6f3aad/attachment.html