문서

자동화

매번 별도의 요청 없이 일정에 따라 또는 특정 이벤트 발생 시 시작되는 작업과 그 위치.

자동화는 요청 없이도 매번 작업을 시작합니다. 일정에 따라 또는 특정 이벤트가 발생할 때 실행되는데, pull request가 열리거나 이슈가 등록되거나 검사 또는 배포가 실패하는 경우가 해당됩니다.

모든 자동화는 Factory의 'Automations' 섹션에 목록으로 표시되며, 어떤 조건에서 시작되고 어떤 작업을 수행하는지 확인할 수 있습니다. '새 작업'에서 자동화를 생성할 수 있으며, 자동화 유형과 실행 시기, 수행 내용을 직접 입력하면 됩니다.

  • 일정시간
  • 이벤트 기반 자동화무언가가 발생하면

일반적인 작업

사양, 계획, 빌드, 검증, 리뷰. 에이전트 슬롯을 사용하며 낮은 우선순위를 부여하십시오.

P2P3

A pull request

자동으로 병합하거나 기본 브랜치에 커밋할 수는 없습니다.

귀하가 승인

자동화의 차이점은 단지 트리거에 있습니다. 자동화가 시작하는 것은 일반적인 경로의 평범한 작업이며, 실제 용량을 사용하여 귀하가 승인하는 pull request로 완료됩니다.

두 가지 유형의 트리거

트리거실행예시
일정몇 시간마다, 또는 매일, 매주, 매월마다 실행됩니다.Sentry에서 매시간 새로운 오류를 요청하여 각 오류에 대해 작업을 생성합니다.
특정 이벤트가 발생할 때GitHub 또는 Coroid에서 이벤트가 전송될 때 실행됩니다.작업이 실패하면 그 원인을 파악하고 이를 수정하는 작업을 생성합니다.

트리거가 시간에 따른 것이거나, Sentry나 Jira처럼 Coroid 이벤트를 전송하지 않는 다른 시스템에 의존하는 경우에는 일정을 사용하세요. 일정 기능은 해당 시스템에 직접 요청합니다.MCP 서버를 통해 찾은 내용을 바탕으로 작업을 생성합니다. 자세한 내용은일정.

Coroid에서 이벤트가 발생하는 즉시 알려줄 수 있는 경우에는 이벤트를 사용하세요. 이 방식은 불필요한 반복 작업을 줄여줍니다.

'새 작업'에서 선택할 수 있는 이벤트

GitHub에서 제공하며, 이를 사용하려면GitHub 앱:

  • pull request가 열리거나 업데이트되거나 병합될 때
  • 이슈가 등록될 때
  • 댓글에 Coroid가 언급되며, 저장소에 대한 쓰기 권한이 있는 사용자가 작성한 경우에만 적용됩니다.

Coroid에서 제공하는 이벤트:

  • 작업, 계획, 품질 관리 검사, 배포 또는 배포 상태 검사가 실패할 때
  • 배포가 성공할 때
  • 릴리스가 롤백될 때

자체 시스템에서 발생하는 이벤트를 사용하려면 서비스 계정이 필요하며, Slack, Telegram, Jira 이벤트의 경우 필터를 설정해야 합니다. 자동화의 이벤트 설정은 편집기에서 변경할 수 있습니다. 자세한 내용은후크.

수행할 작업

에이전트는 사용자의 지시에 따라 작업합니다. 프로젝트 코드를 읽어 작업을 생성할 수 있지만 직접 변경은 하지 않습니다. 에이전트가 생성한 작업은 다른 작업과 동일한 사양, 계획, 빌드, 검증 및 리뷰 과정을 거쳐 pull request에서 승인됩니다.

일정에 따라 자동화는 테스트 환경에서 브라우저 테스트를 실행할 수도 있습니다.

Coroid가 생성한 상시 자동화는 '품질 관리' 섹션에 스위치로 표시되며, '새 작업'에서 직접 생성하는 것은 아닙니다.

  • 풀 리퀘스트 리뷰하기품질 관리의 풀 리퀘스트그룹은 각 pull request에서 프로젝트의 검사를 실행하며(Coroid 품질 관리), Coroid 리뷰 댓글을 추가합니다.
  • 메시지와 이슈를 요청으로 전환하기Slack 및 Telegram 메시지, GitHub에서 Coroid를 언급하는 댓글, 새로운 Jira 이슈는 품질 관리의 '작업 시작 전' 섹션에서 해당 기능을 활성화하면 요청으로 전환됩니다. 자세한 내용은 이슈 추적기Jira용
  • 실패 상황에 대한 후속 조치하기실패한 작업, 배포 실패, 롤백된 릴리스 각각에 대해 문제가 발생했을 때.
  • 기존 기술 부채 정리하기프로젝트의 주간 기술 부채 정리기능은 'Anti-slop' 행에 스위치로 제공됩니다.

자동화를 관리하는 스위치는 Factory 페이지에 표시되며, 해당 스위치로 연결됩니다. 여기서 일시 중지하거나 비활성화할 수 있으며, 지침을 변경하면 사용자 본인의 자동화로 전환됩니다(확인 절차 필요).

이전에 생성되어 요청을 처리하던 자동화는 계속 실행되며 'Automations' 섹션에 목록으로 표시됩니다. 풀 리퀘스트를 리뷰하던 자동화는 품질 관리가 Coroid 리뷰 기능을 담당하면서 일시 중지되었습니다.

'새 작업'의 템플릿

'새 작업'에서는 이전에 템플릿을 제공했으나, 해당 기능은 위의 스위치로 이전되었습니다. Slack에 메시지를 보내는 두 개의 템플릿은 채널 이름을 직접 지정하여 사용자 본인의 문구로 작성할 수 있습니다. 이 기능은MCP 서버를 통해 작동하며, '설정'의 '연결' 섹션에서 연결할 수 있습니다. 일정 자동화와 이벤트 자동화 모두 Factory 편집기에서 MCP 도구를 허용하면 사용할 수 있습니다. 템플릿으로 생성된 자동화는 기존대로 계속 실행됩니다. 기존 템플릿 링크는 대체된 스위치나 '새 작업' 페이지로 연결됩니다.

자동화 모니터링하기

Factory에서 자동화를 열면 각 실행 내역을 확인할 수 있습니다. 실행 시기, 소요 비용, 생성된 작업, 실행이 완료되지 않은 이유 등을 확인할 수 있습니다. 소유자와 관리자는 여기서 자동화를 일시 중지, 테스트, 편집 또는 삭제할 수 있으며, 조직 내 모든 사용자는 자동화 및 그 실행 내역을 볼 수 있습니다.

자동화의 유용성 유지하기

자동화가 생성한 작업은 다른 작업과 동일하게 에이전트 리소스를 사용합니다. 자주 실행되는 자동화는 눈에 띄지 않게 리소스를 과도하게 점유할 수 있습니다.

  1. 사람이 요청한 작업보다 낮은 우선순위를 부여하세요. P2또는P3.
  2. 트리거를 더 구체적으로 설정하세요.바쁜 저장소에서는 "검사가 실패했습니다" 경고가 지속적으로 발생합니다. 실제로 문제가 있을 때는 "기본 브랜치에서 이 검사가 실패했습니다" 경고가 발생합니다.
  3. 생성된 결과물을 확인해 보세요.자동화 프로세스가 20개의 작업을 생성하고 그중 2개만 병합된다면, 이는 가치를 창출하기보다는 불필요한 작업과 비용만 발생시킵니다.

자동화의 진정한 성과는 얼마나 많은 생성된 작업이 병합되었는지로 판단해야 하며, 경고가 얼마나 자주 발생하는지는 중요하지 않습니다.

Sentinel

이전 버전의 문서에서는 조건을 감시하는 모니터인 Sentinel에 대해 설명했습니다. 이는 별도의 기능이 아닙니다. 조건이란 자동화 프로세스가 실행할 수 있는 이벤트이거나 스케줄러가 확인하는 항목입니다.