# 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! - [Microframeworks in the Admin Console](/ko/inside-asana/microframeworks-admin-console) 엔지니어링 모든 Asana 배포에는 관리 콘솔이 있습니다. 여기에서 IT 관리자는 비밀번호 요구 사항, 역할 및 권한, Dropbox에서 파일을 첨부할 수 있는지 여부, 기본 설정으로 새 프로젝트를 볼 수 있는 사용자 등 회사가 Asana를 사용하는 방식을 설정합니다.Asana가 성장함에 따라 관리 콘솔에는 수년간의 사용자 지정 ... - [사양 중심 개발: 장점과 3개월 후의 성과](/ko/inside-asana/spec-driven-development) 엔지니어링 #### 스태프 소프트웨어 엔지니어 3개월이 지난 후, 우리는 추가된 구조가 언제 도움이 되었고 언제 방해가 되었는지 더 명확하게 파악할 수 있었습니다.저희 엔지니어 중 한 명이 데이터 마이그레이션을 준비하고 있었고, 업무 계획을 세우기 위해 사양 중심 개발(SDD)을 사용하기로 했습니다. SDD는 엔지니어가 초기에 누락 사항을 파악하고, 접근 방식을 더 ... - [우리는 2주 만에 Enzyme에서 마이그레이션했습니다. 5년이 걸렸어야 했습니다.](/ko/inside-asana/migrating-off-enzyme-2-weeks) 엔지니어링 최근에 우리는 AI를 사용하여 한 번의 스프린트에서 수년간의 엔지니어링 작업을 완료했습니다. 그 방법과 이것이 가능성에 대한 우리의 생각을 변화시킨 이유를 소개합니다.5년 문제2022년에 우리는 Asana의 프런트엔드 테스트 스위트를 오래된 테스트 라이브러리인 Enzyme에서 React Testing Library(RT ... - [AI 팀원이 메모리를 구축하는 방법: 업무를 재사용 가능한 지식으로 전환](/ko/inside-asana/ai-teammates-turn-work-into-reusable-information) 인공 지능(AI) 엔지니어링 대부분의 AI 제품은 메모리를 개인적인 기능으로 취급하여 한 사용자 또는 한 대화에 대한 사실을 기억합니다. 그러나 팀 간 협업하는 AI에는 근본적으로 다른 종류의 메모리가 필요합니다. AI 시스템은 이전에 학습한 내용을 바탕으로 구축할 수 있을 때 더 유용해집니다. 그러나 엔터프라이즈 소프트웨어에서 메모리는 단순히 더 ... - [How we use Asana in our infrastructure](/ko/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)