Scaling Django Migrations on AWS Part 2

In our last post we described the steps necessary to build a Hubot-driven workflow for running Django’s migrate command in an ECS cluster.

Putting Hubot to work requires us to write some Javascript or CoffeeScript that processes commands we send it via Slack along with a response that Hubot sends back to the Slack channel.


Scaling Django Migrations on AWS

Django’s migration support provides developers with a fairly comprehensive toolset for managing and versioning schema and data changes. Writing migrations in code provides a helpful layer of abstraction and makes testing easier, while at the same time adding an extra layer of safety.

Running Django’s migrate command iterates through an application’s set of ordered migrations and runs each one, as long as it hasn’t already been executed. Fortunately, the migrate command is also idempotent – running it multiple times (but not simultaenously) has no ill effects. One particular area of contention however, is how to automate the running of the migrate command at deployment time without executing in parallel on all deployment targets in a cluster.


Email Testing in Development

Testing software that requires unique email addresses is a pain. Automated testing tools can lessen the burden by using counters or random strings to create unique email addresses, but that stops at localized testing – those email addresses can’t actually receive mail. A common method often used to resolve this is a “catch-all” email alias that accepts any email sent to it and forwards it to a specfic address. While this method can work well for the solo developer, it’s inadequate in a team environment where each member needs to see the message.