If I can get root access, I''ll use version control for deployment as well... It beats ftp and scp hands down for speed. Setting up a repository on a remote server means I get automatic off-site backup as part of the development cycle, and deployment/site update is as simple as a three word command line entry. Small changes on remote test sites can be made with Vim (or your *nix editor of choice), and checked back in to the project. If there is a problem caused by the difference between the development and test environments, it can be quite a little time-saver. I am curious though... Does anyone else do this? I haven''t come across any (I only started doing it recently), but can you think of any potential disadvantages? Do you have any better or alternative deployment techniques for Rails projects? Ben
On 12 May 2006, at 10:45, DJ Tequila wrote:> If I can get root access, I''ll use version control for deployment > as well... It beats ftp and scp hands down for speed. Setting up a > repository on a remote server means I get automatic off-site backup > as part of the development cycle, and deployment/site update is as > simple as a three word command line entry. Small changes on remote > test sites can be made with Vim (or your *nix editor of choice), > and checked back in to the project. If there is a problem caused by > the difference between the development and test environments, it > can be quite a little time-saver. > > I am curious though... Does anyone else do this? I haven''t come > across any (I only started doing it recently), but can you think of > any potential disadvantages? Do you have any better or alternative > deployment techniques for Rails projects?If you don''t use capistrano yet, start using it now! :) http://manuals.rubyonrails.com/read/chapter/97 Cheers, Chris
DJ Tequila wrote:> If I can get root access, I''ll use version control for deployment as > well... It beats ftp and scp hands down for speed. Setting up a > repository on a remote server means I get automatic off-site backup as > part of the development cycle, and deployment/site update is as simple > as a three word command line entry. Small changes on remote test sites > can be made with Vim (or your *nix editor of choice), and checked back > in to the project. If there is a problem caused by the difference > between the development and test environments, it can be quite a little > time-saver. > > I am curious though... Does anyone else do this? I haven''t come across > any (I only started doing it recently), but can you think of any > potential disadvantages? Do you have any better or alternative > deployment techniques for Rails projects?That''s pretty much how Capistrano works :-) -- Alex
I have to chime in and agree. Capistrano (the software formerly known as SwitchTower) is brilliant. It only took me about an hour to learn how it works, but the actual setup process only takes minutes. It basically makes deploying a new release as simple as "rake deploy". Broken release? "rake rollback". Ken Chris McGrath wrote:> On 12 May 2006, at 10:45, DJ Tequila wrote: > >> If I can get root access, I''ll use version control for deployment as >> well... It beats ftp and scp hands down for speed. Setting up a >> repository on a remote server means I get automatic off-site backup >> as part of the development cycle, and deployment/site update is as >> simple as a three word command line entry. Small changes on remote >> test sites can be made with Vim (or your *nix editor of choice), and >> checked back in to the project. If there is a problem caused by the >> difference between the development and test environments, it can be >> quite a little time-saver. >> >> I am curious though... Does anyone else do this? I haven''t come >> across any (I only started doing it recently), but can you think of >> any potential disadvantages? Do you have any better or alternative >> deployment techniques for Rails projects? > > If you don''t use capistrano yet, start using it now! :) > > http://manuals.rubyonrails.com/read/chapter/97 >
so do most of you guys use Capistrano in addition to your version control system, such as svn? I use svn for all my development, and when it comes to deployment time, I had planned on using svn on the server and just doing an svn co/update to bring the server sources in line with the development sources.. I thought Capistrano was for people who didn''t use some type of version control management software.. Mike On 5/12/06, Kenneth Liu <ken.liu.pub@gmail.com> wrote:> I have to chime in and agree. Capistrano (the software formerly known > as SwitchTower) is brilliant. It only took me about an hour to learn > how it works, but the actual setup process only takes minutes. It > basically makes deploying a new release as simple as "rake deploy". > Broken release? "rake rollback". > > Ken > > Chris McGrath wrote: > > On 12 May 2006, at 10:45, DJ Tequila wrote: > > > >> If I can get root access, I''ll use version control for deployment as > >> well... It beats ftp and scp hands down for speed. Setting up a > >> repository on a remote server means I get automatic off-site backup > >> as part of the development cycle, and deployment/site update is as > >> simple as a three word command line entry. Small changes on remote > >> test sites can be made with Vim (or your *nix editor of choice), and > >> checked back in to the project. If there is a problem caused by the > >> difference between the development and test environments, it can be > >> quite a little time-saver. > >> > >> I am curious though... Does anyone else do this? I haven''t come > >> across any (I only started doing it recently), but can you think of > >> any potential disadvantages? Do you have any better or alternative > >> deployment techniques for Rails projects? > > > > If you don''t use capistrano yet, start using it now! :) > > > > http://manuals.rubyonrails.com/read/chapter/97 > > > > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
Mike Garey wrote:> so do most of you guys use Capistrano in addition to your version > control system, such as svn? I use svn for all my development, and > when it comes to deployment time, I had planned on using svn on the > server and just doing an svn co/update to bring the server sources in > line with the development sources.. I thought Capistrano was for > people who didn''t use some type of version control management > software..Capistrano does a checkout from version control to the deployment directory on command, then HUPs the server... It essentially does precisely what you''re looking for :-) -- Alex
Thanks for the heads-up, guys! I started deploying with subversion on a PHP project, and just used the same technique when I moved over to RoR... But Capistrano looks like a nice, tight, integrated system. I''ll look into it as soon as I get a spare 5 minutes.
AFAIK, Capistrano requires some kind of version control to work at all, at least to do anything useful. (what kind of developers don''t use version control anyways?) Mike Garey wrote:> I thought Capistrano was for > people who didn''t use some type of version control management > software.. >
On 5/12/06, DJ Tequila <mail@djtequila.com> wrote:> If I can get root access, I''ll use version control for deployment as > well... It beats ftp and scp hands down for speed. Setting up a > repository on a remote server means I get automatic off-site backup as > part of the development cycle, and deployment/site update is as simple > as a three word command line entry. Small changes on remote test sites > can be made with Vim (or your *nix editor of choice), and checked back > in to the project. If there is a problem caused by the difference > between the development and test environments, it can be quite a little > time-saver. > > I am curious though... Does anyone else do this? I haven''t come across > any (I only started doing it recently), but can you think of any > potential disadvantages? Do you have any better or alternative > deployment techniques for Rails projects? > > Ben >I''m doing that with Darcs. Very simple: a one-line "darcs push" command that I''ve set as a script. So my deployment is basically: deploy_script and enter. But, reading this thread, I guess I should indeed check Capistrano (which was recommended to me several times). -- -Alder
If all Capistrano did was simply update source code on your server, then it wouldn''t be that useful compared to the approach you describe. However, it does a whole lot more. It can deploy code simultaneously across many servers in a farm. It''s also super easy to define additional actions to take as part of your deployment process (e.g. do a database dump, migrate your database, bounce your servers, copy files, rename directories, etc.) You can even define a sequence of tasks in a "transaction", so if one task fails, Capistrano will automatically execute the "rollback" task. Lots more good stuff too. Mike Clark has blogged a nice summary of it here: http://clarkware.com/cgi/blosxom/2005/12/17 Ken> > I''m doing that with Darcs. Very simple: a one-line "darcs push" > command that I''ve set as a script. So my deployment is basically: > > deploy_script > > and enter. But, reading this thread, I guess I should indeed check > Capistrano (which was recommended to me several times). >