At VinSol, we have been developing and deploying Rails applications for more than four years. During this period, we have identified some best practices that we prefer to follow while deploying rails application to production server.

1. Ruby on Rails Application
11 Things to Consider Before Deploying Your Ruby on Rails
Application

2. Ruby on Rails
At VinSol, we have been developing and deploying Rails applications for more
than four years. During this period, we have identified some best practices that we
prefer to follow while deploying rails application to production server.

3. Below is the
checklist of these
practices:
1. Ensure that NS records and MX records
are changed if they need to be changed
Changing nameservers will point the domain
to the hosting server, and changing MX
records will redirect incoming mails to the
mail server. As a very first step, we should
make sure that name servers of the domain
are set to be the correct one. Changing MX
record is a must if our application is parsing
incoming mails or we wants to use other
mail services for e-mail exchange, for
example Gmail.

4. 2. Ensure some backup mechanism in place for both data as well as
user uploaded content like images/documents etc.
Since production data is very critical, we must setup backup mechanism. It
could be some type of scheduled task that takes periodic backup of all critical
data, Or it could be some type of backup service provided by hosting company.
When we talk about critical production data, it includes production DB, content
generated by application users like images, documents, etc.

5. Ensure Database indexes
We might have done development without having
proper database indexes, but we should avoid going to
production without them. Adding indexes might slow
down insert queries a bit but it increases the
performance of read queries. It applies when
application in production has percentage of read
operations much more than write operations.

6. Enable your slow
query log
This is specific to MySQL. Enabling slow
query log allows MySQL to log slow
running queries to a file. And this log
can be used to find queries that take a
long time to execute and are therefore
candidates for optimization.

7. Ensure exception is in place
We might want to be notified when something bad happens to our
application. There are several hosted services available who receive
and track exceptions, for example Hoptoadapp.com,
GetExceptional.com etc… Either we can choose one from these
hosted services or we can use “exception notifier” plugin.

8. Ensure adding
entries for
cron/scheduled
jobs
Most of the applications have some
functionality/jobs that need to be run
periodically, for example generating invoices,
sending newsletters etc. In most cases these
jobs are done by a rake task. We should make
sure that we have added such jobs to cron or
similar program.

9. Monitoring
Important
Processes
To ensure that our site is up 24×7 we need
to ensure that all processes that our
application needs are up. There can be
many processes like MySQL, Mongrel,
Apache etc.. These processes are very
important as our application directly
depends on them. For example if MySQL
process get killed accidentally, our
application would not be able to connect to
MySQL and will start throwing exceptions.
We can choose any of the available
monitoring tools like God, Monit, 24×7 etc…

10. Ensure Confidential Data
Filtering
We would never like to leak/share confidential information of our
application users. We should make sure that none of the user’s
confidential data like SSN, Credit card info, password are being written to
log files. We might not have paid much attention on this while developing
the application.

11. RotateLog
Files
Once our site is up and running, every single request write
some text in log file. And hence size of the log file keeps on
increasing. Larger log files can put us in trouble if we get it
beyond certain size. It’s difficult to manage these log files, as
larger files need more memory to open and need more time to
download. In one of the rescue project we did , the log file size
was 3GB.
We would recommend having logrotate setup for the
application.

12. Setup Asset Host
Setting up asset hosts can reduce loading time by 50%
or more. We must setup asset hosts for our application.
Once asset hosts are all set, our static files will be
delivered via asset hosts for example
asset1.hostname.com, asset2.hostname.com

13. Clearing up stale sessions
We should make sure we should not left any stale session on the server. If our
application is using DB or file system as session store, we must add a schedule
task to delete stale sessions.
These are some of the points we have identified from our past experience and we
might be missing some. Feel free to always add them as comments, and I’ll keep
this post updated.

14. Thank you
See more at - http://vinsol.com/blog/2009/11/16/11-things-
to-consider-before-deploying-your-rails-application/