July 20th 2010

By Corey Donohoe

TAGS:
Technology
News
Ruby

Engine Yard AppCloud CLI

At Engine Yard we’ve been helping developers ship Ruby applications for almost four years. Our approach to deployment has changed a few times but at its core our focus has always been helping people deploy and scale Ruby on Rails applications on virtualized hardware. Almost two years ago, we started experimenting with Amazon’s AWS service and realized that people wanted more of a self service setup. For the first time, we decided to take a stab at providing the same kind of service on other people’s hardware instead of our own. This has grown into our AppCloud offering. Today, we’re happy to announce an awesome new addition to AppCloud that enables developers to ship code faster, easier, and straight from the command line.

A Bit of EY History

In our early days, we provided our customers with customized capistrano recipes to deploy their ruby applications to our clusters. A problem quickly arose because we also needed to help them maintain this recipe as we helped them scale their applications. We learned that keeping our customers’ capistrano recipes up to date was a truly painful exercise, so when we built AppCloud we went with a more centralized approach.

Early AppCloud Direction

We thought that solving the problem of keeping most of the deployment related information in sync was so painful that we built a web based deployment strategy. It wasn’t the worst idea ever, but the disconnect between leaving your shell and going to a web browser isn’t really what developers want. In addition, we were so excited about the idempotency that chef offered at a configuration level that we felt it was imperative to “verify” the state of the system with a chef run each time we shipped code. This made pushing code slower than necessary and occasionally created panic situations if the chef run failed for some strange reason. People could still use capistrano with AppCloud, but it required them to re-download their deployment recipes every time their environment changed. There also wasn’t an easy way to maintain customizations if customers kept having to re-download the capistrano recipe. Over and over again, we kept hearing the same complaints from customers. Customers liked the provisioning flexibility on AWS but shipping code on AppCloud was suboptimal. A few months ago, we finally admitted that our intentions were correct but we hadn’t been doing the best things for our customers. We started working on a way to help our customers ship code more effectively.

Customer Feedback is Awesome

We accepted that idempotency is extremely important when it comes to system configuration but that doesn’t mean you need to re-run chef each time you ship application code. We realized that people want to see their code running on their servers ASAP. Finally, we embraced the idea that people want to ship code with a command line tool similar to the way most people use rake to run their test suite. We’re happy to introduce a more pleasant way to ship code to AppCloud, the engineyard gem.

A Better Workflow

The old way of deploying with chef works, but it forces you to reconfigure your servers every single time you deploy. The workflow looked like this:

Boot some instances (provision, configure, deploy)
Ship code (run configuration, deploy code)
Ship code (run configuration, deploy code)
Ship code (run configuration, deploy code)
Tweak system configuration (configure)
Ship code (configure, deploy)
Ship code (configure, deploy)
…

With the Engine Yard CLI, you can deploy without verifying your system’s configuration, so it’s quite a bit faster to ship new code.

The new workflow looks like this:

Boot some instances (provision, configure)
Ship code (deploy)
Ship code (deploy)
Ship code (deploy)
Tweak system configuration (configure)
Ship code (deploy)
Ship code (deploy)
…

We really think our customers are going to prefer this approach because, let’s face it, we ship code way more often than we reconfigure systems.

Get Started

gem install engineyard
cd ~/myapp
ey deploy

One of the things we like most about the new CLI is that it shows you, in real time, what’s going on with your deploy. If something goes wrong, you don’t have to scroll through a huge log in your browser; the error messages are right there in your terminal. When it succeeds, the process exits, so you know immediately that it’s done. No more staring at the dashboard waiting for a spinning dot to turn into a green one. How about ey deploy && mpg123 woohoo.mp3 || mpg123 sad-trombone.mp3? That’s immediate, unmistakable, annoying, audible feedback. You can’t get that from a green dot.