# How we use Asana in our infrastructure > Asana is a critical part of our infrastructure--here's how and why we use it to manage our deployment process. Source: https://asana.com/inside-asana/using-asana-in-our-infrastructure ## 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](https://vimeo.com/141968362) feature launching later this year, and our [Wufoo integration](https://asana.com/apps/wufoo), 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](https://blog.asana.com/2014/08/use-asana-track-production-issues-can/). 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](https://github.com/Asana/python-asana) 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! - [Improving Asana’s Pageload Performance](/inside-asana/improving-asanas-pageload-performance) Engineering #### Senior Engineering Manager Asana serves 2.5 million pageloads a day, peaking at 3.5 million. Each one is a user's first impression of the product — the moment between intent and action — and for a tool team ... - [How Asana Built A Resilient ID Allocation System](/inside-asana/how-asana-built-resilient-id-allocation) Engineering Every object in Asana—every task, project, comment, and attachment—needs a unique identifier. At Asana, these IDs are sequentially incrementing integers, allocated in blocks from ... - [The Athletic Position](/inside-asana/the-athletic-position) Engineering I. Before the Ball Leaves their StringsThere is a moment from the 1988 French Open final that most people who talk about tennis haven’t had to think about carefully.Steffi Graf pl ... - [How Asana leverages AWS Inspector for total visibility over infrastructure vulnerabilities](/inside-asana/asana-leverages-aws-inspector-visibility-infrastructure-vulnerabilities) Engineering #### Software Engineer Scanning for vulnerabilities across multiple AWS accounts, eliminating noise, and turning vulnerability findings into actionable work is a challenging but important undertaking. A ... - [How we use Asana in our infrastructure](/inside-asana/using-asana-in-our-infrastructure) Engineering 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 al ... - [Engineering](/inside-asana/engineering-spotlight)