Subject: Re: Progress! - msg#00203

Previous Message by Date: click to view message preview

Re: Progress!

On Jan 23, 2007, at 3:11 PM, Jacob Atzen wrote: > > On Tue, Jan 23, 2007 at 01:54:36PM -0700, Jamis Buck wrote: >>> Might I suggest a combination of cached_repository and copy_*? >>> Perhaps >>> implemented over rsync? >>> >>> Something along the lines of: >>> - Checkout / export into local copy - to avoid having remote repos >>> access >>> - Rsync local copy to cached repository (or cached export) - to >>> minimize >>> bandwidth usage and deployment time >>> - Copy cached repository to new release >>> >>> Does this sound like a good idea to anyone but me? >> >> If you're copying from the localhost to each server anyway, why not >> just copy directly to the new release directory? Perhaps I'm >> misunderstanding the scenario. At any rate, I think you'll find new >> deployment strategies ridiculously easy to write with the new system. >> The cached_repository strategy, for instance, is only 48 lines of >> code, including blank lines and comments. > > I'm impatient, when I hit deploy I want my new version running > asap. As > such I would prefer having a cached copy on each server which I can > push > deltas to instead of having to push the whole app including the frozen > Rails sources. I think you just described the cached_repository strategy. :) It does a complete checkout of the source code once on each server, in the shared directory. Then, subsequent deploys just do an update on each server's cached copy ("svn up", or whatever the SCM of choice supports), and then copy the cached copy to the release directory. Or are you referring to something like having an initial checkout as the first release, and subsequent deploys copying the previous release and doing an SCM sync on it? That might make an interesting strategy, too. > I'll take a hack at it when you publish the new code. Please do! - Jamis

Next Message by Date: click to view message preview

Re: Progress!

Jamis Buck wrote: > On Jan 23, 2007, at 2:42 PM, S. Robert James wrote: > > > > > I would suggest to versions of cached_repository: > > > > 1. Incremental. > > 2. Clean (rm -rf and sync everything from the beginning). > > Could you elaborate on the difference between these? Sure. #1 asks the SCM to check out whatever files have been changed since the last check out. It's much quicker than #2, since it only checks out files which have been changed. #2 erases the check out dir, and rechecks out everything. It may take a few more seconds, but it guarantees the dir is identical to the way it is supposed to be. This is especially helpful when you are doing some type of post processing after the check out (like I mentioned earlier - generating some files, compressing JavaScript, etc.). It also comes in handy when things don't seem to be working right, or when looking at a deployment you haven't touched in a while and not sure whose fiddled with what (alas, it happens more often than we'd like, once your app grows old...). Similar to make verus make clean && make.

Previous Message by Thread: click to view message preview

Re: Progress!

On Jan 23, 2007, at 3:11 PM, Jacob Atzen wrote: > > On Tue, Jan 23, 2007 at 01:54:36PM -0700, Jamis Buck wrote: >>> Might I suggest a combination of cached_repository and copy_*? >>> Perhaps >>> implemented over rsync? >>> >>> Something along the lines of: >>> - Checkout / export into local copy - to avoid having remote repos >>> access >>> - Rsync local copy to cached repository (or cached export) - to >>> minimize >>> bandwidth usage and deployment time >>> - Copy cached repository to new release >>> >>> Does this sound like a good idea to anyone but me? >> >> If you're copying from the localhost to each server anyway, why not >> just copy directly to the new release directory? Perhaps I'm >> misunderstanding the scenario. At any rate, I think you'll find new >> deployment strategies ridiculously easy to write with the new system. >> The cached_repository strategy, for instance, is only 48 lines of >> code, including blank lines and comments. > > I'm impatient, when I hit deploy I want my new version running > asap. As > such I would prefer having a cached copy on each server which I can > push > deltas to instead of having to push the whole app including the frozen > Rails sources. I think you just described the cached_repository strategy. :) It does a complete checkout of the source code once on each server, in the shared directory. Then, subsequent deploys just do an update on each server's cached copy ("svn up", or whatever the SCM of choice supports), and then copy the cached copy to the release directory. Or are you referring to something like having an initial checkout as the first release, and subsequent deploys copying the previous release and doing an SCM sync on it? That might make an interesting strategy, too. > I'll take a hack at it when you publish the new code. Please do! - Jamis

Next Message by Thread: click to view message preview

Re: Progress!

Hi Jacob, I have been using this method for little while. I just hacked at cache_svn.rb and created cache_rsync.rb. It works like this.. 1. local svn cache is updated using svn up 2. rsync sends changes (minus .svn folders, and deploy.rb) to servers cache folder 3. simple copy from the server cache to the release folder This has the following advantages. 1. Its much faster if your svn server is running on your local network. 2. No need for subversion to be installed on the live server. 3. You can exclude some files from being sent to the live server. E.g. dont send deploy.rb or your svn password. 4. Your svn server can be behind a firewall. My code could really do with some improvements and I think the SCM plugin sounds great. Is it in svn? I would be happy to help adding rsync support once the plugin is out. - Luke P.S. - Here is the important bit of code from my hacked cache_rsync.rb. cmd = 'rsync ' %w{ archive compress copy-links cvs-exclude delete-after no-blocking-io stats }.each { | opt | cmd << "--#{opt} " } cmd << " --exclude \"config/deploy*\" -e ssh #{local_rsync_cache}/ " puts "Updating each server" username = user || ENV['USER'] current_task.servers.each do |server| puts "Syncing deployment cache for #{server}" puts `#{cmd} #{username}@#{server}:#{remote_rsync_cache}/` end run "cp -r #{remote_rsync_cache} #{release_path}" On Jan 24, 5:11 am, Jacob Atzen <j...-4U2y0bnePT5NzRJJ8cAMrg@xxxxxxxxxxxxxxxx> wrote: > On Tue, Jan 23, 2007 at 01:54:36PM -0700, Jamis Buck wrote: > > > Might I suggest a combination of cached_repository and copy_*? Perhaps > > > implemented over rsync? > > > > Something along the lines of: > > > - Checkout / export into local copy - to avoid having remote repos > > > access > > > - Rsync local copy to cached repository (or cached export) - to > > > minimize > > > bandwidth usage and deployment time > > > - Copy cached repository to new release > > > > Does this sound like a good idea to anyone but me? > > > If you're copying from the localhost to each server anyway, why not > > just copy directly to the new release directory? Perhaps I'm > > misunderstanding the scenario. At any rate, I think you'll find new > > deployment strategies ridiculously easy to write with the new system. > > The cached_repository strategy, for instance, is only 48 lines of > > code, including blank lines and comments.I'm impatient, when I hit deploy I > > want my new version running asap. As > such I would prefer having a cached copy on each server which I can push > deltas to instead of having to push the whole app including the frozen > Rails sources. > > I'll take a hack at it when you publish the new code. > > -- > Cheers, > - Jacob Atzen