Rails%203%20In%20Action

Summary
the root account on this machine, as everything can be managed by your user or the
application’s user.
Then we had you set up a database server using PostgreSQL, one of the most popular
relational datastores today. You discovered that giving your system user the same
name as your database came in handy; PostgreSQL supports a kind of authentication
that automatically grants a system user access to a database with the same name. That
is of course provided a PostgreSQL user and database exist with that name. Very
handy!
Second-to-last, you got down to the meat of the chapter: the first deployment of
your application to your server using Capistrano. You saw that the config/deploy.rb file
comes in handy, allowing you to specify the configuration of your deployment environment
simply. With Capistrano, you distill everything you need to get your application’s
latest code onto the server down to one command: cap deploy:migrations.
Every time you need to deploy, run this command, and Capistrano (along with your
configuration) will take care of the rest.
Finally, you set up nginx and Passenger to serve your application’s requests, as well
as the static assets of your application. Generally, this is the setup preferred by Rails
developers, and so there’s a lot of useful knowledge out there. An alternative to this
setup would be to use the Apache web server instead of nginx. Both work suitably.
That’s your application done, really. From the first time you ran a test all the way
up to deployment, you’ve covered a lot of important things within Rails. There’s still
much more to learn (which is why there are more chapters after this one), but right
now you should have a firm grasp of what the process of developing and deploying a
Rails application is. In the next chapter, we show you how you can let people authenticate
to your application through either Facebook or Twitter.
411