# 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! - [AI Agents Built for Teams: Shared Context and Transparency in Enterprise AI](/pt/inside-asana/ai-agents-built-for-teams-context-transparency) engenharia Artificial Intelligence (AI) The Accountability gap Enterprise AI agents are AI systems that can take actions inside shared workflows across teams and projects. This landscape has grown quickly as a growing l ... - [How Asana makes me a more effective engineering manager](/pt/inside-asana/asana-makes-me-effective-engineering-manager) engenharia #### Gerente de engenharia de infraestrutura de dados As an engineering manager, I need to keep track of so many things. I have my own personal to-dos that I need to prioritize, making time for focused work while also handling incomi ... - [How we use Asana in our infrastructure](/pt/inside-asana/using-asana-in-our-infrastructure) engenharia 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 ... - [engenharia](/inside-asana/engineering-spotlight)