# 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! - [Being a Female Engineer at Asana](/ja/inside-asana/female-engineer) エンジニアリング Note: This post was originally published on Quora in response to the question What are some particularly female-engineer-friendly companies to work for in San Francisco?As a femal ... - [Scaling our invalidation pipeline: Part 1](/ja/inside-asana/scaling-invalidation-pipeline-part-1) エンジニアリング #### Platform Engineer At Asana, our invalidation pipeline is a key part of implementing near-realtime reactivity in the webapp. Reactivity is how each-and-every Asana tab keeps up-to-date with the lat ... - [AI Agents Built for Teams: Shared Context and Transparency in Enterprise AI](/ja/inside-asana/ai-agents-built-for-teams-context-transparency) エンジニアリング 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 ... - [Scaling LunaDb, our in-house declarative data loading system](/ja/resources/scaling-lunadb) エンジニアリング #### Platform Engineer Here at Asana, we’ve built a data loading system called LunaDb that serves as the backbone of our webapp. Despite the name, it’s not a database. Rather, it’s a GraphQL-like system ... - [How we use Asana in our infrastructure](/ja/inside-asana/using-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 al ... - [エンジニアリング](/inside-asana/engineering-spotlight)