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-copyare 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 installis run on each application instance. - If you need a specific version of bundler, specify it in your Gemfile.
- We suggest you generate a
Gemfile.lockto 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, thelogdirectory 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.rbis run. - The migration command specific to your application is run (see the
--migrateoption). - Finally, the deploy hook
deploy/after_migrate.rbis run.
5. Application Symlink
After migrations and their deploy hooks have been executed, your application symlink is created.
- The deploy hook
deploy/before_symlink.rbis run. - Your application symlink is created.
/data/<appname>/currentpoints to/data/<appname>/releases/<timestamp> - Finally, the deploy hook
deploy/after_symlink.rbis 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.rbis 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.txtto tell Passenger to restart. - Finally, the deploy hook
deploy/after_restart.rbis 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.
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.
Can’t seem to edit the previous comment, but anyway, let’s pretend I used a friendly tone to suggest a better date format.
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
Thanks, Keri. I appreciate the prompt response and am looking forward to those changes.
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
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
Hi Jim,
Generally the workflow is like this:
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!
Hi, I liked this Q&A so added it to the FAQ forum. thanks! kjm
Regarding step 7, is it possible to configure how many releases are kept?
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).
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]
Hi, I would like to know if it is possible to increase the number of release kept after deploying? I cannot find it in the documentation.
Thanks in advance.
Stephanie
Could you include some information about asset compilation?
At what point are the chef recipes run?
Brent deploying code does not run chef recipes and is taken care of through the Apply mechanism. It is separate from the chef recipes.
Is there a way to customize any of the deployment steps? What I mean in particular is that step `bundle install` in reality does smith like `ruby -S bundle _1.7.9_ install`. That command uses very old version of bundle. I wonder how do I change it to `ruby -S bundle _1.17.2_ install`? Is it maybe controlled by some env_variable or recipe?
Hello Konstantin,
The internal EY backend is not recommend to be customized. However, you can utilize the versioning of your Gemfile and Gemfile.lock in order to perform necessary versioning for gems to be utilized in the applications.
Pasan