Knowledge Base/Engine Yard Cloud Documentation/Deploy your Application

How Your Ruby Code is Deployed on Engine Yard Cloud

Engine Yard
posted this on February 16, 2012 10:02 AM

General concepts

There are two components that facilitate code deployment:

  • Client-side component. This component connects (via SSH) to the application master of your environment and ensures that the server-side component is installed and is the correct version. The client-side component then invokes the server-side component on the application master to coordinate code deployment.
  • Server-side component. This component ensures that it is installed on all other instances in the environment. Server-side then manages and coordinates the code deployment process whenever the client-side component requests a deployment.

1. Code fetch

  • On the application master, the source code is fetched from the git repository, then the chosen branch is checked out into /data/<appname>/shared/cached-copy. The application master then copies this (via rsync) to all the other instances in your environment.
  • On each instance, the contents of /data/<appname>/shared/cached-copy are copied to /data/<appname>/releases/<timestamp>.

2. Gem bundling

After your code is copied to all instances in your environment, the server-side component checks for the existence of a Gemfile.

  • If a Gemfile is found, the bundler gem is installed and the command bundle install is run on each application instance.
  • If you need a specific version of bundler, specify it in your Gemfile.
  • We suggest you generate a Gemfile.lock to ensure consistency across deployment environments.

3. Default configuration

After your application gems are installed, the server-side component generates and symlinks configuration files and directories for your application.

  • Configuration files and directories necessary for your application are generated or symlinked and put into place. Examples of these files include: config/database.yml, config/mongrel_cluster.yml, config/newrelic.yml, the log directory and more.

4. Database migration

After default configuration has been setup, your database migrations are run with appropriate deploy hooks.

  • The deploy hook deploy/before_migrate.rb is run.
  • The migration command specific to your application is run (see the --migrate option).
  • Finally, the deploy hook deploy/after_migrate.rb is run.

After migrations and their deploy hooks have been executed, your application symlink is created.

  • The deploy hook deploy/before_symlink.rb is run.
  • Your application symlink is created.
    /data/<appname>/current points to /data/<appname>/releases/<timestamp>
  • Finally, the deploy hook deploy/after_symlink.rb is run.

6. Restart application servers

After your application code is in place and has been appropriately symlinked, restart your application servers.

  • The deploy hook deploy/before_restart.rb is run.
  • Your application servers in your environment are now restarted. For example, if your environment is using Passenger, the server-side component will touch the file /data/<appname>/current/tmp/restart.txt to tell Passenger to restart.
  • Finally, the deploy hook deploy/after_restart.rb is run.

7. Final cleanup

If there are more than three previous releases in /data/<appname>/releases, all but the most recent three are removed. Your deployment is now finished.


If you have feedback or questions about this page, add a comment below. If you need help, submit a ticket with Engine Yard Support.

 

Comments

User photo
Alan Hogan
ifttt-LLC

This document says it was posted "Feb 16 10:02". Of what year? Obviously this is a worthless date format, because it neglects year — though helpfully provides time, though if I actually cared, I’d be left guessing whether that’s 10AM or 10PM.

April 17, 2012 10:04 PM
User photo
Alan Hogan
ifttt-LLC

Can’t seem to edit the previous comment, but anyway, let’s pretend I used a friendly tone to suggest a better date format.

April 17, 2012 10:05 PM
User photo
Keri Meredith
Engine Yard Inc.
Hi Alan, OK sure, we'll go with friendly. :) Thank you for the feedback on the date format. We are currently working with our help desk vendor to get the last edited time stamp added, and we will look into adding the year as well.
FYI - Most of the docs were loaded into the help desk in February 2012, so you can consider that date as a baseline. The time format is 24:00 hours, so you can tell it was a.m. thanks, kjm
April 18, 2012 11:50 AM
User photo
Alan Hogan
ifttt-LLC

Thanks, Keri. I appreciate the prompt response and am looking forward to those changes.

April 18, 2012 11:52 AM
User photo
Jamie Miller
Engine Yard Inc.

Hi Alan - I just wanted to update you to, again thank you for your feedback, and let you know that I changed the timestamps from a 24:00 format to a 12 hour clock. This makes the timestamp more obvious when looking at it. This will also be reflected in timestamps in the ticket comments.  Regarding the year, I have passed this feedback on to Zendesk, and they are going to look into it.  They did confirm that anything posted within the current calendar year will not show the year, but anything posted in past years will show the year (ie, anything added in 2011 or earlier).   Thanks!  Jamie

 

April 18, 2012 04:15 PM
User photo
James Stephenson
jhstephenson

How do changes from Github get implemented? Let's say I have my application up and running, but then make a change to a screen; what do I need to do to get that change into the live application?

Thanks,

Jim

May 16, 2012 08:19 PM
User photo
J. Austin Hughey
Engine Yard Inc.

Hi Jim,

Generally the workflow is like this:

  1. Make changes in your code; run tests locally, make sure it's working
  2. Run a git add <filenames changed> and git commit -m "your commit message here" followed by a git push to whatever branch you're using (e.g. 'git push origin master')
  3. Once the code has been pushed to GitHub, you can deploy from the dashboard or from the Engine Yard CLI. 

Once code is on GitHub, it can be deployed to your application by our deployment process, so it's generally a two-phase process (including support steps for each phase as above). The deploy will bring down the new code, put it in a new directory, do some symlinking and restart the application (as well as run database migrations if necessary), just as this document describes.

More information on deploying can be found here:

Deploy From Your Dashboard

Deploy From the CLI

Hope this helps!

May 17, 2012 07:04 PM
User photo
Keri Meredith
Engine Yard Inc.

Hi, I liked this Q&A so added it to the FAQ forum. thanks! kjm

May 22, 2012 11:14 AM
User photo
Reid Parham
TeamCFA

Regarding step 7, is it possible to configure how many releases are kept?

September 05, 2013 03:18 PM
User photo
Jes Sherborne
team-everywhere

Is there a corresponding document that covers how this works for node.js applications? Not all of these steps apply (or they apply but are presumably being done in a different way).

October 03, 2013 10:13 AM
User photo
Keri Meredith
Engine Yard Inc.

Hi Jes, No, I don't think we have that doc. A very good suggestion though. Will see what we can do ... thanks! kjm

[DOC-1039]

October 03, 2013 11:45 AM