문제

CI에는 Cruisecontrol.rb를 사용하고 버그 추적에는 FogBugz를 사용하지만 답변이 더 일반적일수록 좋습니다.

첫 번째는 기술적인 문제입니다.FogBugz용 API가 있나요?좋은 튜토리얼이나 미리 작성된 코드가 있나요?

두 번째는 절차상의 문제입니다.빌드가 중단될 때 CI가 버그 추적기에 정확히 무엇을 넣어야 합니까?아마도:

제목:"#{마지막 커미터}가 빌드를 깨뜨렸습니다!"

몸:"#{ 오류 추적 }"

나는 이것이 이 질문에 대한 대답을 전제로 한다고 생각합니다.버그 추적에 CI 중단을 포함해야 합니까?

도움이 되었습니까?

해결책

제가 작업한 모든 CI 설정은 (목록으로) 이메일을 보내지만, 특히 팀에서 FogBugz를 할 일 시스템으로 많이 사용하는 경우 FogBugz 6에서 사례를 열 수 있습니다. API가 있습니다 그러면 케이스를 열 수 있습니다.그 문제에 대해서는 FogBugz의 이메일 제출 주소로 이메일을 보내도록 구성할 수 있지만 API를 사용하면 마지막 커미터에게 사례를 할당하는 등 더 많은 작업을 수행할 수 있습니다.

브라이언님의 답변에 따르면 CI가 케이스 번호가 있는 커밋에서 실패를 발견하면 기존 케이스를 다시 열 수도 있습니다.하지만 모든 작은 일에 대한 사례 필드를 코드화하는 것과 마찬가지로 CI 자동화가 "너무 똑똑"하여 잘못 판단하고 짜증스러울 수 있는 지점이 있습니다.새로운 케이스를 여는 것만으로도 충분할 수 있습니다.

그리고 감사합니다:이로 인해 우리의 침팬지 FogBugz로 설정하세요!

다른 팁

우리 회사에서는 최근 문제 추적을 위한 JIRA와 빌드를 위한 Bamboo를 포함하여 (상용) Atlassian 스택을 채택했습니다.Microsoft 세계와 매우 유사합니다(아마도 우리는 Java 상점입니다). 모든 제품을 단일 공급업체로부터 구입한다면 긴밀한 통합이라는 보너스를 얻게 됩니다.

상호 운용성을 구현한 방법에 대한 예를 보려면 상호 운용성 페이지.

실링이면 충분해요.일반적으로 그들의 일반적인 접근 방식을 다음과 같이 요약할 수 있습니다.

  • 버그 추적기에서 문제를 생성합니다(예:PROJ-123의 이슈 키).
  • 코드를 커밋할 때 커밋 주석에 "PROJ-123"을 추가하여 이 코드 변경으로 수정되는 버그를 표시하세요.
  • CI 서버가 코드를 체크아웃할 때 diff의 커밋 주석을 스캔하세요.문제 키의 정규식과 일치하는 문자열을 기록하세요.
  • 빌드가 완료되면 발견된 문제 키에 대한 보고서를 생성합니다.

특히 두 번째 문제에 대해서는 다음과 같습니다.

CI는 버그 추적기에 아무것도 넣을 필요가 없습니다.Bamboo는 JIRA에 아무것도 넣지 않습니다.대신 Atlassian 사람들은 Bamboo에 대한 원격 API 호출을 수행하는 플러그인을 JIRA에 제공하여 "Bamboo, 나는 어떤 빌드(JIRA 문제)와 관련되어 있습니까?"라는 질문을 했습니다.이것은 아마도 다음으로 가장 잘 설명될 것입니다. 스크린샷.

CC에는 빌드가 실패할 때 경고하는 유틸리티가 함께 제공됩니다. 이는 아마도 FogBugz에 실패한 빌드를 기록할 가치가 없을 것입니다. 즉시 해결되는 문제를 추적할 필요는 없습니다(대부분의 손상된 빌드가 그렇듯이).

다른 방향으로 가려면(FogBugz가 문제를 해결한 체크인을 표시함) 웹 기반 저장소 브라우저가 필요합니다. FogBugz는 올바른 변경 사항을 표시하도록 구성하기 쉽습니다.

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top