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
--
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.
On May 1, 2:13 am, doug <ddjol...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> 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. >Why do you need this system rather than just pulling down the latest version from source control ? Fred> ... doug > > -- > You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. > To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org > To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com. > For more options, visit this group athttp://groups.google.com/group/rubyonrails-talk?hl=en.-- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
On Fri, Apr 30, 2010 at 6:13 PM, doug <ddjolley-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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.3) 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 Schroeder ------------------------ hassan.schroeder-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org twitter: @hassan -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
> 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 -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
> 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 -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
On 3 May 2010 17:02, doug <ddjolley-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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 -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
On May 3, 5:14 pm, Michael Pavling <pavl...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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 -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
Doug Jolley 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. > > ... dougBest, -- Marnen Laibow-Koser http://www.marnen.org marnen-sbuyVjPbboAdnm+yROfE0A@public.gmane.org -- Posted via http://www.ruby-forum.com/. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.