SwitchTower to skip config/ directory

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

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.

On 2/20/06, Tom M. [email protected] 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

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.

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 :slight_smile:

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

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

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/environments-in-rails-0-13-1


– Tom M.

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.

On 2/20/06, Tom M. [email protected] 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/environments-in-rails-0-13-1

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