If your application has special deployment requirements, read this page about methods to customize the deployment process.
The following methods can help you customize your deployment:
- Using ey.yml to customize your deployment
- Bundle install private repository gems
- Advanced customization with override files
- Deploy Hooks
Using ey.yml to customize your deployment
ey.yml
is a YAML file that lives in your application’s config/
directory. It allows you to customize the deploy process to a limited, but still useful, extent.
ey.yml
contains a single top-level hash named environments. Its keys are environment names, and its values are themselves hashes of settings for that particular environment.
Examples
All these examples assume your environment is myapp_staging. Replace that with your environment’s actual name.
-
Don’t copy .git directory to each release
environments:
myapp_staging:
copy_exclude:
- .git -
Set a default branch
environments:
myapp_staging:
branch: master -
Use thor to run migrations, but only run them when –migrate is specified
environments:
myapp_staging:
migrate: false
migration_command: thor db:migrate
Fields to note
The engineyard gem pays attention to many keys in the per-environment hash. They are:
-
copy_exclude (array)
items that are excluded when copying from your repository to each release. See rsync(1), in particular the--exclude
option, for more details. Default is empty. See copy_exclude example above for YAML array syntax. -
branch (string)
the branch to deploy by default. Default ismaster
. -
migration_command (string)
the command to invoke in order to run migrations. Default israke db:migrate
. -
migrate (boolean)
whether or not to run migrations during deploy. -
bundle_without (string)
the argument passed tobundle install --without ''
during deploy. Default istest development
. -
maintenance_on_restart (boolean)
shows maintenance page during app restart. Default istrue
for glassfish and mongrel andfalse
for all other application servers. -
maintenance_on_migrate (boolean)
shows maintenance page during migrations. Default istrue
. -
precompile_assets (boolean)
enables rails assets precompilation. Default is inferred using app/assets and config/application.rb.The precompile assets setting in the
ey.yml
and the contents of the repository need to be in agreement on the expected asset compile method. If assets are compiled locally and committed to the repository, theney.yml
precompiled assets should be set to false. If assets are compiled at deploy time, then theey.yml
precompiled assets should be true and the repository should not contain a public/assets folder. -
ignore_database_adapter_warning (boolean)
hides database adapter warning if you don't use MySQL or PostgreSQL. Default isfalse
.
Bundle install private gem repositories
To install gems in your Gemfile that are referenced by private git repository URI, like the following:
gem 'privategem', :git => 'git@github.com:yourname/privategem.git'
Now you can follow these steps:
1. Create a machine user account in Github
https://developer.github.com/guides/managing-deploy-keys/#machine-users
2.a. Add the machine user as a collaborator to the application repository an the private gem repositories
https://help.github.com/articles/how-do-i-add-a-collaborator
or
2.b. Add the machine user to a team that has access to the application repository and the private gem repositories
https://help.github.com/articles/adding-organization-members-to-a-team
3. Finally, Copy the deployment key and add it as an SSH key of the machine user. As the machine user, go to https://github.com/settings/ssh then press the New SSH key button and add the deployment key.
When you've finished these steps, your private repository will be accessible to bundler when you deploy.
Advanced customization with override files
Deploy overrides offer an advanced level of customization via overrides file. This file is instance_eval’d into the main deploy class so that you can over ride core functionality of the deploy. You should not use this for simple modifications around a deploy (deploy hooks are a better choice for those tasks).
Using deploy overrides
To use deploy overrides, create a file in your code repository at either config/eydeploy.rb
or eydeploy.rb
. This file should contain a list of methods, and is instance_eval’d into the main EY::Deploy
class. You can super into any of the methods that you override. You can see the source of the class that your customization will be instance_eval’d into on GitHub at https://github.com/engineyard/engineyard-serverside/blob/master/lib/engineyard-serverside/deploy.rb. We guarantee the top level tasks (bundle, symlink_configs, enable_maintenance_page, migrate, symlink, restart, disable_maintenance_page, and cleanup_old_releases) will remain consistent and in a consistent order. All other methods in the class are subject (but unlikely) to change.
Using the eydeploy.rb Files
Engine Yard does not typically recommend using the eydeploy.rb
files to make changes to your application because maintaining version compatibility can be cumbersome. However, some situations warrant their usage. Use the eydeploy.rb
files under the following conditions only:
- If you have application changes that are too specific to add to an
ey.yml
configuration option. - The application changes are only temporarily needed. For example, you need a temporary fix while you are migrating your application.
- You want to maintain the deploy consistency yourself.
eydeploy.rb Example
Below is an example of how you might use the eydeploy.rb
files.
requirement = Gem::Requirement.create("~>2.3.0") unless requirement.satisfied_by?(About.version) raise "engineyard-serverside version change detected. Make sure this patch works before deploying to production"end
# In this example, the command below is not altered.
# Here is where you would make your modification to the chown command.
# Methods in the kernel scope here are eval'd into the Deploy object.
# This will then override all calls to ensure_ownership.
def ensure_ownership(*targets)
sudo %|find #{targets.join(' ')} \\( -not -user #{config.user} -or -not -group
#{config.group} \\) -exec chown #{config.user}:#{config.group} "{}" +|
end
Deploy Hooks
Deploy hooks are Ruby scripts that you write which are executed at designated points in the deployment process. This allows you to customize the deployment of your application to meet its particular needs. We discuss deploy hooks in Use deploy hooks.
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
Article is closed for comments.