I have deployed several instances of a Rails application. I am now
considering how I might apply application updates to each of the
various instances. I would like the updates to be contained in some
sort of an archive like a tar archive. There are two types of files
to be included in the archive:
- Files which should only be written if there is no corresponding
file in the installation. These would typically be new files that are
being added from the archive.
- Files which should overwrite corresponding installed files only if
the archive file is newer than the installed file.
The problem is that the tar archive does not allow me to specify the
overwriting rule to be applied on a file by file basis. Thus unless
there is some way to do this that I don’t know about, I would really
need 2 tar archives for each update. I see this as being unacceptably
cumbersome. I reason that there must be a better way. Does anyone
know what that better way is (possibly a different archiving tool)?
Thanks for any input.
... doug
On May 1, 2:13 am, doug [email protected] wrote:
the archive file is newer than the installed file.
The problem is that the tar archive does not allow me to specify the
overwriting rule to be applied on a file by file basis. Thus unless
there is some way to do this that I don’t know about, I would really
need 2 tar archives for each update. I see this as being unacceptably
cumbersome. I reason that there must be a better way. Does anyone
know what that better way is (possibly a different archiving tool)?
Thanks for any input.
Why do you need this system rather than just pulling down the latest
version from source control ?
Fred
On Fri, Apr 30, 2010 at 6:13 PM, doug [email protected] wrote:
- Files which should only be written if there is no corresponding
file in the installation. These would typically be new files that are
being added from the archive.
- Files which should overwrite corresponding installed files only if
the archive file is newer than the installed file.
- What about files that need to be removed?
As Fred said, you’re almost certainly better off to just deploy from
your source repository (using e.g. Capistrano).
But if you must do something like the above, it’s called rsync and
it handles case #3 as well.
HTH,
Hassan S. ------------------------ [email protected]
twitter: @hassan
Why do you need this system rather than just pulling down the latest
version from source control ?
Because there are some files that may have been modified with customer-
specific code. We never want to overwrite these files. However, if a
file in this group doesn’t exist on the system being updated (as in
the case where the update adds the file) we want to write the file.
Thanks for the input.
... doug
But if you must do something like the above, it’s called rsync and
it handles case #3 as well.
I’m going to look into this. Thanks for the suggestion.
... doug
On 3 May 2010 17:02, doug [email protected] wrote:
Why do you need this system rather than just pulling down the latest
version from source control ?
Because there are some files that may have been modified with customer-
specific code. We never want to overwrite these files. However, if a
file in this group doesn’t exist on the system being updated (as in
the case where the update adds the file) we want to write the file.
So you don’t have a SCR-managed version of your different client
sites differences?
Well… that’s not the most unusual situation, but it’s not exactly
great practice.
I’d suggest a review of your internal processes with all the
developers, PMs and other stakeholders to discuss how to manage code
deployment. As a suggestion, I’d recommend a branch of your code for
each of your deployed client sites. Using Git/Mercurial it’s not a
huge nightmare to manage merging core changes while keeping
client-specific code in the respective branches (although I’d
recommend that was a task delegated to one “change manager” who can
keep on top of it, and be responsible for all changes - and banging
the heads of anyone who “breaks the build”
Approaching the problem this way, you can deal with any updates in
source control long before deployment, ensuring the client is going to
get the right stuff (and with a staging server, that everything is
going to continue working). Approaching it from the angle you’re
musing about, you’ll be constantly walking a tightrope that you
accidentally apply the wrong tar file to the wrong site - and that’s
on the live site too.
HTH
On May 3, 5:14 pm, Michael P. [email protected] wrote:
I’d suggest a review of your internal processes with all the
developers, PMs and other stakeholders to discuss how to manage code
deployment. As a suggestion, I’d recommend a branch of your code for
each of your deployed client sites. Using Git/Mercurial it’s not a
huge nightmare to manage merging core changes while keeping
client-specific code in the respective branches (although I’d
recommend that was a task delegated to one “change manager” who can
keep on top of it, and be responsible for all changes - and banging
the heads of anyone who “breaks the build”
or depending on how different the various versions are (and in
addition to what Michael has said) you could make the code support
what all of your customers want and make the choice between the
variants a configuration option. If you absolutely do have to make
code changes to different deployments you could deploy those changes
as plugins which re-open / monkey patch application classes (or
toggles configuration options). You can set rails to load plugins from
a directory other than vendor/plugins. Like that the app deploy would
be the same across all deployments and it would load plugins in (for
example) ~/site_customizations/ that would patch in per deployment
stuff
Fred
Doug J. wrote:
Why do you need this system rather than just pulling down the latest
version from source control ?
Because there are some files that may have been modified with customer-
specific code. We never want to overwrite these files. However, if a
file in this group doesn’t exist on the system being updated (as in
the case where the update adds the file) we want to write the file.
You can make your Cap deploy scripts do this.
Thanks for the input.
... doug
Best,
Marnen Laibow-Koser
http://www.marnen.org
[email protected]