Forum: Ruby on Rails SwitchTower to skip config/ directory

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Vivek K. (Guest)
on 2006-02-19 10:16
(Received via mailing list)
Hello,
  I am  trying to figure out how to use switch tower.I have a local copy
of
source code and I want to put it on the host.Now I dont want to put
directories like config/ because the settings on the host and the one on
my
machine are different.
Any way to do this?

Also is svn necessary to use SwitchTower?

Vivek
Tom M. (Guest)
on 2006-02-19 21:10
(Received via mailing list)
On Feb 19, 2006, at 12:13 AM, Vivek K. wrote:

>   I am  trying to figure out how to use switch tower.I have a local
> copy of source code and I want to put it on the host.Now I dont
> want to put directories like config/ because the settings on the
> host and the one on my machine are different.

Vivek, Rails allows for 3 different configs, development, test and
production.

Are you saying that you have a need to deploy two "production"
environments
for some reason, like staging (final QA) and real live production?

If it's just development and production, there's no reason you
couldn't use the
same configs.

That said, if you really need it, I'd recommend committing BOTH
versions into
your change management system, and using switchtower to deploy both,
then
symlinking or moving the correct versions into place with each
deployment.

--
-- Tom M.
Vivek K. (Guest)
on 2006-02-20 05:44
(Received via mailing list)
On 2/20/06, Tom M. <removed_email_address@domain.invalid> wrote:
>
> Are you saying that you have a need to deploy two "production"
> environments
> for some reason, like staging (final QA) and real live production?


No, I need only 1 production environment but which is on the host.On my
local machine its a development environment.But I see in the recipes
file
that it includes the config directory too.Thats what I want to avoid
because
things like database.yml are different on the host.


If it's just development and production, there's no reason you
> couldn't use the
> same configs.
>
> That said, if you really need it, I'd recommend committing BOTH
> versions into
> your change management system, and using switchtower to deploy both,
> then
> symlinking or moving the correct versions into place with each
> deployment.


I think so.but I am wondering if this isnt a common problem which
everyone
faces.So that means I need to set up a svn repository on my local
machine?
Vivek
Jim M. (Guest)
on 2006-02-20 05:47
(Received via mailing list)
Here is a task I just hacked up to use switchtower to deploy to my
servers by copying a local directory to the servers, rather than have
the servers use svn. I actually create my local directory using an svn
export, but you can do whatever you like here, and also exclude whatever
directories you want. You may have to use the after_update_code as I
have to patch up files for the production version...
This needs some work to make it "nice" (get rid of hard coded temp names
etc, and the cleanup doesn't get run if it fails). YMMV :)

desc "fix up database and .htaccess"
task :after_update_code do
  run "cp #{release_path}/config/database.yml.templ
#{release_path}/config/database.yml"
  run "cp #{release_path}/public/dot.htaccess.deploy
#{release_path}/public/.htaccess"
end

desc <<DESC
Update all servers with the latest release of the source code.
This is a modified version that copies a local copy to the remote site
DESC

task :update_code, :roles => [:app, :db, :web] do
    on_rollback { delete release_path, :recursive => true }

    #puts "doing my update_code"
    temp_dest= "tmp_code"

    #puts "...get a local copy of the code into #{temp_dest} from local
svn"
    # but this could also just be your local development folder
    system("svn export -q #{configuration.repository} #{temp_dest}")

    #puts "...tar the folder"
    # you could exclude files here that you don't want on your
production server
    system("tar -C #{temp_dest} -c -z -f code_update.tar.gz .")

    #puts "...Sending tar file to remote server"
    put(File.read("code_update.tar.gz"), "code_update.tar.gz")

    #puts "...detar code on server"
    run <<-CMD
        mkdir -p #{release_path} &&
        tar -C #{release_path} -x -z -f code_update.tar.gz &&
        rm -rf code_update.tar.gz &&
        rm -rf #{release_path}/log #{release_path}/public/system &&
        ln -nfs #{shared_path}/log #{release_path}/log &&
        ln -nfs #{shared_path}/system #{release_path}/public/system
    CMD

    #puts "...cleanup"
    system("rm -rf #{temp_dest} code_update.tar.gz")
end
Tom M. (Guest)
on 2006-02-20 08:55
(Received via mailing list)
On Feb 19, 2006, at 7:42 PM, Vivek K. wrote:

> Are you saying that you have a need to deploy two "production"
> environments for some reason, like staging (final QA) and real
> live production?
>
> No, I need only 1 production environment but which is on the
> host.On my local machine its a development environment.But I see in
> the recipes file that it includes the config directory too.Thats
> what I want to avoid because things like database.yml are different
> on the host.

Vivek, I don't understand.

Rails is designed to handle this without problem.

A single application can have three entirely different
environments with the default core set of files.

There's absolutely zero need for trickery in your case.

--
-- Tom M.
Tom M. (Guest)
on 2006-02-20 09:28
(Received via mailing list)
On Feb 19, 2006, at 10:54 PM, Tom M. wrote:

>> are different on the host.
>
> Vivek, I don't understand.
>
> Rails is designed to handle this without problem.
>
> A single application can have three entirely different
> environments with the default core set of files.
>
> There's absolutely zero need for trickery in your case.

Here's a URL that explains why there's zero need:

http://glu.ttono.us/articles/2005/09/05/environmen...

--
-- Tom M.
Jeroen H. (Guest)
on 2006-02-20 10:35
(Received via mailing list)
Vivek K. wrote:
>     Vivek, Rails allows for 3 different configs, development, test and
> avoid because things like database.yml are different on the host.
Maybe there's a smarter way to do it, but I have just removed
database.yml from my SVN repository. I now do this manually, but I guess
you can setup a deployment task that copies the existing database.yml to
a temp directory, checks out the latest version from SVN and then copies
the version from temp back into the config directory.

Jeroen
Vivek K. (Guest)
on 2006-02-21 05:40
(Received via mailing list)
On 2/20/06, Tom M. <removed_email_address@domain.invalid> wrote:
> >> host.On my local machine its a development environment.But I see
> >
> > There's absolutely zero need for trickery in your case.
>
> Here's a URL that explains why there's zero need:
>
> http://glu.ttono.us/articles/2005/09/05/environmen...


Hi,
 Ok I get it now..you suggest that I use the development mode settings
on my
local m/c and the the production mode on the server.Both can be in the
same
yml file and can be interchanged between server and local m/c. The only
hitch is that I run script/console on my host and that needs a devp
environment.
Vivek
Tom M. (Guest)
on 2006-02-21 08:12
(Received via mailing list)
On Feb 20, 2006, at 7:38 PM, Vivek K. wrote:

> The only hitch is that I run script/console on my host and that
> needs a devp environment.

No, that's not a hitch at all!

script/console production

I do it all the time.

--
-- Tom M.
This topic is locked and can not be replied to.