engineyard gem version 2.0

Today we’re proud to release version 2.0 of the engineyard gem, Engine Yard’s command line deploy interface. We didn’t call it 2.0 because it has some great new social location friend spamming features or “crowd sourcing”. No, anything but that. This is release 2.0 because…

engineyard 2.0 is not strictly backwards compatible.

First off, let’s discuss changes in behavior that you need to know about before upgrading. Though unlikely to break anything, please keep these in mind. As always, please try this in a staging environment before you deploy to production, especially this time.

  1. `ey.yml` is now loaded during deploy on the server. __ACTION REQUIRED__: Commit your `ey.yml` file into your repository. If you don't have one, don't worry about it. If you do, some options that worked previously will only work when committed.
  2. No default migration behavior. Many people were surprised by the migration settings trying to be too smart, so we're keeping it simple. __ACTION REQUIRED__: Add `migrate: true/false` and `migration_command: rake db:migrate` to your ey.yml file. An interactive prompt will assist you and create an `ey.yml` file during your next deploy. The `--migrate` switch can be used to override your settings.
  3. Deploy order of precompile assets and the hooks that go with it. 'compile_assets' now runs before the maintenance page is installed. Don't get caught with your maintenance down. __ACTION REQUIRED__: Probably none, but if you expected the maintenance page to be up during the hooks around asset precompilation, move them to the migrate hooks instead and check that everything is happening as you expect in a staging environment.

I’ve checked everything above, now what?

Good job. Now that you made it through the “action required” onslaught, install the new engineyard gem. Just in case this is your first railway rodeo:

gem install engineyard -v '~>2.0'

Now you have the command line ey with which you can ey deploy your application. So exciting!

CLI Only

IMPORTANT: The web dashboard deploy does not yet use engineyard 2.0. We’re only releasing the CLI now until we upgrade the web dashboard. The new features discussed here will not work in the web deploy until the upgrade.

Staging, Staging, Staging

Did I mention that you need to do a full deploy to a staging environment before you use the new gem in production? I’m sure I did. Go do that. Who knows what your deploy hooks do? Not me.

If you have trouble with this new version, uninstall the gem from your ruby gems and open a ticket with us. Your CLI deploys will use whatever older version of the engineyard gem you use to deploy.

New Features (yay!)

Speed. The first thing you’ll notice is speed. Engineyard gem 2 uses a new set of APIs for faster application lookup and it’s the feature I’m most proud of. On my EY Cloud account, preloading data went from ~56 seconds to ~1 second. That’s a barrel full of seconds! If you only have 1 environment, you probably never noticed this issue. For our bigger customers, I will gratefully accept hugs and happy emails (cash will have to go to my private account in the Cayman Islands, which doesn’t exist).

Better deploy output. I really like the new deploy output. I hope you do too. Using --verbose should be much easier to understand. I won’t spoil it here with a screenshot. Go try ey deploy -v for yourself.

New ey.yml options. Use these options to customize your deployment.

maintenance_on_restart Show the maintenance page during every restart (true) or never show it (false). Default: false except for glassfish and mongrel.

maintenance_on_migrate Show the maintenance page during migrations (true, default) or never show it (false) Please be careful if you turn off maintenance_on_migrate or you will cause some downtime every migration, or worse, corrupt your data if a migration is destructive. NB: If the two options above are false, when you manually install the maintenance page with ey web disable, ey deploy will no longer remove the maintenance page during the deploy.

precompile_assets Try to compile assets and abort deployment if they fail (true) or never compile assets (false). Default setting is inferred using app/assets and config/application.rb settings in your application.

ignore_database_adapter_warning This warning is here to help people who don’t have a database adapter in their Gemfile by accident. If you did that on purpose, good for you. Now you can silence that incessant warning.

Restart web servers without deploying. Use the command ey web restart to restart all the application servers on your instances without changing the code. Your ey.yml maintenance_on_restart setting will be respected during the restart.

Lastly, but not leastly, you will now also have access to account_name and environment_name in deploy hooks. No one requested this, but we needed it internally, so go wild!

A Personal Note

With this version of the engineyard gem we are now able to run our complex main application deployment through the CLI. Before this, all but one of our applications deployed through the CLI. This most interconnected application was our last holdout. I’m very proud of my team for making this happen and I’m happy to be a part of it. Thanks to all of you that made this happen!