Bicking, David (HHoldings, IT) wrote:
> 1. checkout code to a local workspace known by a local web server
> 2. make whatever changes are necessary.
> 3. test until blue in the face.
> 4. commit changes.
> 5. backup the live site. Clear the live site.
> 6. Export the workspace to the live site.
> 7. Smoke test the live site.
Argh. That is so needlessly complicated and prone to human error
(especially step #5 in my experience). Install my modules
SVN::Notify::Mirror[1] and SVN::Notify::Config[2] and use something like
the following post-commit file:
#!/usr/bin/perl -MSVN::Notify::Config=$0
--- #YAML:1.0
'':
PATH: "/usr/bin:/usr/local/bin"
'/project/trunk':
handler: Mirror
to: "/path/to/www/htdocs"
'/project/tags':
handler: Mirror
to: '/path/to/remote/www/dir'
tag-regex: "RELEASE_"
ssh-host: "remote_host"
ssh-user: "remote_user"
ssh-tunnel: "10.0.0.2"
ssh-identity: "/home/user/.ssh/id_rsa"
That is your *entire* post-commit script and it does the following:
1) Keeps the test server (local to the Subversion repository) up to date
with the project trunk; developers commit changes to the repo for any
change they make. Note the test server does not need to be local to the
subversion server. There are so many times when a developer will make
"one more change before committing" and break what was working, then
they can't [easily] get back to a work state. Just commit *any*
proposed change to the repo and if it breaks the test server, big whoop...
2) Any time you wish to make a production release, create a tag that
matches the regex /RELEASE_/ and the post-commit will update (via
switch) a working copy on the remote_host box, via SSH, over a tunneled
connection (so the production server in the DMZ doesn't even need to a
route to the Subversion server), using a named ssh user and SSH cert
file. You can also choose to update the production server via Rsync or
a normal working copy update if you so choose. The tool is completely
flexible. I could even write an FTP update subclass if enough people
wanted it (though with the SSH and Rsync, I can't imagine why).
3) If you want commit e-mails to go out, you can add another stanza to
use the other functionality of SVN::Notify[3] to send [HTML-formatted
colorized] diff messages to a list or individuals of your choice.
HTH
John
1. http://search.cpan.org/dist/SVN-Notify-Mirror/
2. http://search.cpan.org/dist/SVN-Notify-Config/
3. http://search.cpan.org/dist/SVN-Notify/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Oct 12 15:16:48 2007