Things To Keep In Mind When Deploying Your Ruby On Rails App To Production

Irrespective of the platform your developers choose for deployment, there are some general checklists to be followed apart from the steps you’ll follow for the environment selected. From the outset, you’ll have to make the following choices:

• Where to deploy and the choice of the web server: You’ll have to make the call based on considerations of cost, sanity check regarding patches and upgrades.  For servers, you’ll find the popular choice to be Passenger or Puma. The RAM usage must be taken into consideration, and monitoring can be done with custom installed software. Run a check for metrics, automated alerts, error measurements and detailed diagnostics to identify the issues with source code. Keep in mind the Rail version you choose to use should guarantee long-term support.
• Choose a proper database and content delivery network: Your choice of database is a trade-off and can end up increasing the RAM size. The Rails function allows easy ways to fetch small sets in batch for processing and can be put to use readily.  You can enhance the magnitude by using a content delivery network. Check for image uploading since specific environments like Heroku can impose timeout constraints.  For the sake of security, it becomes necessary to revoke access to redundant employees. Also be sure to designate a competent employee to be placed in charge, with proper KEYs once the Rails goes online, considering glitches are inevitable.

The three key factors to be considered for pre-deployment are:

Basic steps:

• Make sure to run checks for maintainability, readability, faster development and for duplications.
• The name servers need to be changed and the main exchanger records corrected in order to redirect incoming mails.
• Proper database indexes are to be provided. While it can slow down insert queries, it improves your read queries performance.
• The users need to be identified and checked.

Security and backup:

• You must put in place a scheduled backup mechanism for periodic backup of production data.  The backup should include code, data, and user uploaded data.
• Clear text shouldn't be the form you store user passwords in. User submitted information should not be clubbed to database queries.
• Institute a protect from forgery in the controllers. The authenticity token must be on all form submissions.
• Protection against overwriting of user accounts ID.
• A limited roll back release for disaster management should be maintained and not across legacies.
• Validate the content type, and extension of user submitted files and secure the upload directory from running scripts
• An intimation mechanism to be instituted for notification if something bad happens to the application. Either a hosted service can be used or a notifier plugin option.
• Confidential data like Credit card information, personal data, etc. should be protected against leaks. Such classified information should not be written to log files.

Operational checks:

• Identify the slow query logs for optimization.
• The application should allow for periodic repetitive jobs like mailers and newsletters. This can be done with CRON or similar programs
• A check is to be done to ensure all processes like Mongrel, Apache, etc., required for the application are put up. This can be done with standard monitoring tools.
• Over time your log file size will keep increasing, and larger files will need more time to open and download.  Put up a log rotate setup for the application.
• A scheduled task should be included to eliminate stale sessions.
• Set up asset hosts to reduce loading time.
• The controllers should contain request handling and response related logic.
• The application needs to be internationalized from the start. This is best done along with development. Customizing for other languages should be easy.
• Make sure the version control system checks are done
• A built-in code reloading mechanisms comes along with the Rails framework comes. Whenever you reference a nonexistent class, if you've installed a hook, the same hook code will attempt to locate then load the file associated to the class. You need to check this.

Specific care regarding environment chosen will include:

Heroku:

Heroku will make it easy for your developers to configure. The checks should include package installation, encrypting and managing secrets, initialization, monitoring, Nginx configuration, SSH keys, SSL configuration, Capistrano configuration, logging, security at the least.

Passenger:

Passenger is easy to use and will make your deployment process easy and scalable. The launching of the server, installation of Ruby runtime, installation of passenger, setting up a production server, creating a UNIX user account and setting up permissions, deploying the application, ensuring updates and integration with web server are basic. Passenger may spawn multiple applications. Some of the additional considerations when deploying on passenger are:

• Performance: The more processes you run, the better the CPU core utilization, up until the hardware limit. You'll find Standalone and Nginx to be slightly faster than Apache.  
• I/O concurrency: The more processes you run, the greater the amount of available I/O concurrency. This makes your app perform better.
• Stability: See Passenger restarts the crashed process while other processes remain unaffected and can take over, in case your application process crashes.
• Keeping problems in check: A lot of problems, like getting stuck or leaking memory, can be controlled by restarting the process where the problems occurred.
• For usability: Standalone is easier during development, but Nginx and Apache are easier during production.
• Multi-tenancy: Both Nginx and Apache integration modes can at the same time, host multiple apps.
• Flexibility and control: If you need deep control over every aspect of the system or if your production cluster has an advanced architecture, then Standalone will be your best bet during production.

Ubuntu:

You would have to create a virtual private server, choose an image, select size, select region and proceed with installation of Ruby, Nginx, MySQL and PostgreSQL Database Setup, Capistrano setup, adding the Nginx host and connecting the database.

Automation on Capistrano:

Capistrano is an application release automation tool. When you release a new version of your web application, you’ll have to perform a bunch of actions, such as running a command to install your gem bundle, uploading your application code to your servers, restarting processes, etc. Capistrano lets your developers automate all these actions.

 The server Capistrano, won’t provide you HTTP transaction handling. This means it does not replace web servers or application servers. Instead, you will have to use Capistrano along with them. For instance, Capistrano scripts come with instructions to restart the application server after a new application version has been released.