Deployment Best Practices

Not on a Friday

The team has been focused. This set of features has been worked on all week. This is going to make the app faster, leaner, better looking. The test coverage is looking good. Sure, some things may have been missed, but everything should be okay. The clock says it’s 3:00 PM and it’s Friday. Time to deploy?

No. While the common workflow is to establish goals at the start of the week and see them through to completion at the end of the week, we sometimes overlook the obvious when we close our week out and try to push new code to production on a Friday. The sense of completion is there, though sometimes the emergency resources are not. Developers may have headed out for the weekend, QA may be having a team lunch. Essentially everyone in your organization has in some way checked out for the weekend.

What happens if something goes wrong? While Engine Yard App Support is always standing by to help, if there is something awry with a rake task or some other part of the code, even the best of the best can only help in tracking it down and passing that knowledge on to your team.

So what’s the alternative?

A better technique, more beneficial to any team environment, is to wait until the following Monday. Sleep on that code and if anything occurs to you or your team over the weekend, meet about it Monday morning before the deploy to iron out any secondary thoughts.

This allows a better work flow, less chance of getting that dreaded weekend disaster call, and some peace of mind. Taking into consider all the benefits, there are few negative things letting a deploy sit for weekend. Maybe that new “killer feature” waits a bit longer. But if waiting until Monday keeps your app cleaner and running more efficiently, it is beyond worth the wait.

Testing the Upgrades with a Clone

The latest gem/stack/module has come out and you would love to have this up and running immediately in your application. That awesome podcast just hyped how this particular thing will be the end all be all of development and your application will be the best in the industry. Everything looks like it will work, no problem out of the box. LET’S DO THIS!!!

No.

Bringing unknown quantities into your production application is always a risk. Even if it has been tested locally, a change such as this in your production environment can be hazardous and could bring the application to a standstill. Again, you are suddenly having customers call saying they can’t get in! How can this be avoided?

Luckily, in your Engine Yard environment you have the option of cloning a production environment. Cloning gives you a sandbox with all the features, setup, and data of the production application without the publicly facing portion of it. Once the environment is cloned, all kinds of changes can be made to ensure any “gotchas” are found before unleashing this new and improved application on the unsuspecting public. For more information on cloning, we have documentation that can be viewed here: ey.io/HAZjCQ

By eliminating any unknown issues before upgrading, you can deploy with confidence and ensure all is well with your balanced and up-to-date application.

Utility Instances

Cron jobs, background jobs, extemporaneous work the application needs to do should be on the same server, right? Why spread it out, right?

No.

Any job that is crucial to the application but might actually only occur at certain times of the day (or once a month) are likely things that can be conveniently offloaded to a utility instance. The utility instance frees up the resources of the application instance and makes it so, when a job is run, the application is not affected.

Many times, when cron jobs or background jobs are run on the same instance as the application, we see swap alerts or similar issues, some going as far as to take the application down briefly until the job is complete. Utility instances are the best way to avoid any such issues and get the performance you are looking for.

Deployments and application performance can be hampered by many things. The key is to be proactive and ensure you aren’t defeating yourself. These techniques outline a few simple methods amongst many that will help ensure better application uptime and happier end users.