How we use Asana in our infrastructure

At Asana, we dogfood our own product heavily. We use it as most of our customers would—to track all our work from start to finish with tasks, conversations, and projects—but we also have some unexpected uses like housing our internal library, suggesting new product opportunities, and collecting favorite quotes by teammates. Using an internal beta of the Track Anything feature launching later this year, and our Wufoo integration, we’re also able to leverage Asana as an applicant tracker, a tool for customer feedback, and bug tracking system. It also integrates with our own alerts framework to help us track production issues.

And in addition to tracking everything, Asana is a critical part of our production infrastructure. It’s a convenient place to store, view, and modify high-level state about our deployment process.

Deployment Scripts and Asana

Our deployment scripts use the publicly-available python client to interact with projects and tasks in Asana, and essentially turns these projects into an extremely easy-to-build UI for our deployment infrastructure. Because they are part of Asana as a whole, it opens up some very interesting possibilities versus, say, a simple web interface.

At Asana, we currently run the app on two main clusters: prod and beta. The prod cluster, to which we push code twice a day, serves the app externally to our users. We use the beta cluster internally, pushing code every 15 minutes and “freezing” 90 minutes before each production push. This allows us to catch any bugs or crashes that have made it past tests.

The pushes are run by cron jobs on our large “bastion” servers, which build the code and rsync it to all the other machines in the cluster. We control and observe these scripts using four Asana projects: Lock Beta Release, Lock Production Release, Beta Push Tasks, and Prod Push Tasks.

Beta/Prod Push Tasks are Asana projects which store the output and success of all of our pushes. When a push starts, the script creates a task; when the push finishes successfully, the task is marked complete. Of course, we also store this information in machine logs, but since we all have Asana open all the time, it’s especially convenient when we’re having build or deployment issues.

Lock Projects

Even more interesting, and interactive, is how we use the Lock Beta/Production Release projects. These projects are for human- or machine-generated locks, which we can use to stop the pushes. When our push script runs, the first thing it will do is use the API to check its respective Lock project, and only run if the project is empty.

This is especially convenient because locks, being Asana tasks, can be “assigned” to people, so we know who is responsible for which lock, and why they’ve put it in. We use the comments section of the task to discuss when the task can be “completed” and the lock removed.

This also integrates nicely with our homegrown error-reporting system, which we call Airpedal (an homage to Airbrake). Airpedal generates an Asana task for serious crashes. Engineers can then tell Airpedal which commit a given error was resolved in; Airpedal will both ignore any further occurrences of the error until the commit with the fix is deployed, and complete the corresponding Asana task when the fix reaches beta.

If the error task is also added to the Lock Production Release project, then we will push to production only when the commit fixing the error will be part of the push.

Why we like this

We have all the Asana features (followers, comments, projects) associated with actual controls on our infrastructure, which makes tracking and operating on the state of our pushes as efficient as any other process we use the product for.

The idea of scripts interacting with Asana tasks is a powerful pattern, from something as simple and small as assigning graders for our coding challenges, to managing our whole deployment infrastructure. We’re always experimenting to find new ways the product can be used to improve our own efficiency. We hope it will inspire our users to do the same.

If you’re using your own scripts with the Asana API, we’d love to hear about them!