# Updating an Application **URL:** \ **Category:** Rails\ **Created:** [May 1, 2010, 3:15am UTC](https://www.ruby-forum.com/t/updating-an-application/187896 "2010-05-01T03:15:06Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![djames](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/7ab992/32.png) [@djames](https://www.ruby-forum.com/u/djames)\ **Post date:** [May 1, 2010, 3:15am UTC](https://www.ruby-forum.com/t/updating-an-application/187896/1 "2010-05-01T03:15:06Z")
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: 1. 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. 2. 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 ``` ---
**Author:** ![djames](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/7ab992/32.png) [@djames](https://www.ruby-forum.com/u/djames)\ **Post date:** [May 1, 2010, 3:46pm UTC](https://www.ruby-forum.com/t/updating-an-application/187896/2 "2010-05-01T15:46:27Z")
On May 1, 2:13 am, doug [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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 ---
**Author:** ![djames](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/7ab992/32.png) [@djames](https://www.ruby-forum.com/u/djames)\ **Post date:** [May 1, 2010, 5:18pm UTC](https://www.ruby-forum.com/t/updating-an-application/187896/3 "2010-05-01T17:18:56Z")
On Fri, Apr 30, 2010 at 6:13 PM, doug [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > 1. 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. > 2. Files which should overwrite corresponding installed files only if > the archive file is newer than the installed file. 1. 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. ------------------------ removed\_email\_address@domain.invalid twitter: @hassan ---
**Author:** ![djames](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/7ab992/32.png) [@djames](https://www.ruby-forum.com/u/djames)\ **Post date:** [May 3, 2010, 6:04pm UTC](https://www.ruby-forum.com/t/updating-an-application/187896/4 "2010-05-03T18:04:00Z")
> 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 ``` ---
**Author:** ![djames](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/7ab992/32.png) [@djames](https://www.ruby-forum.com/u/djames)\ **Post date:** [May 3, 2010, 6:05pm UTC](https://www.ruby-forum.com/t/updating-an-application/187896/5 "2010-05-03T18:05:45Z")
> 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 ``` ---
**Author:** ![djames](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/7ab992/32.png) [@djames](https://www.ruby-forum.com/u/djames)\ **Post date:** [May 3, 2010, 6:16pm UTC](https://www.ruby-forum.com/t/updating-an-application/187896/6 "2010-05-03T18:16:53Z")
On 3 May 2010 17:02, doug [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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 ---
**Author:** ![djames](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/7ab992/32.png) [@djames](https://www.ruby-forum.com/u/djames)\ **Post date:** [May 3, 2010, 7:06pm UTC](https://www.ruby-forum.com/t/updating-an-application/187896/7 "2010-05-03T19:06:03Z")
On May 3, 5:14 pm, Michael P. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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 ---
**Author:** ![djames](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/7ab992/32.png) [@djames](https://www.ruby-forum.com/u/djames)\ **Post date:** [May 4, 2010, 8:52pm UTC](https://www.ruby-forum.com/t/updating-an-application/187896/8 "2010-05-04T20:52:39Z")
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](http://www.marnen.org) removed\_email\_address@domain.invalid