CI 추적에는 cruisecontrol.rb를 사용하고 버그 추적에는 FogBugz를 사용하지만 일반적으로 대답이 많을수록 좋습니다.지속적인 통합 시스템과 버그 추적 시스템을 어떻게 통합합니까?
첫 번째는 기술적 인 문제입니다. FogBugz 용 API가 있습니까? 좋은 자습서 또는 더 나은 아직, 미리 작성된 코드가 있습니까?
두 번째는 절차적인 문제입니다. 빌드가 중단되었을 때 CI가 버그 추적기에 정확히 무엇을 넣어야합니까? 아마도 :
제목 : "# {마지막 커미터}가 빌드를 망쳤습니다!"
바디 : "# {오류 추적}"
내가이이 질문에 대한 답을 전제로 가정 : 난 내 버그 추적에 CI 나누기해야합니까?내가 작업 한 모든 CI 설정은 이메일 (목록)을 보내지 만, 특히 팀에서 FogBugz를 ToDo 시스템으로 많이 사용하는 경우에는 FogBugz 6에서 사례를 열 수 있습니다. 사례를 열 수있는 It has an API 이 문제에 관해서는 FogBugz의 이메일 제출 주소로 이메일을 보내도록 구성 할 수 있지만 API를 사용하면 마지막 커미터에게 사례를 할당하는 것처럼 더 많은 일을 할 수 있습니다.
Brian의 대답은 나에게 제안합니다. CI가 사례 번호가있는 커밋에서 오류를 발견하면 기존 사례를 다시 열어도됩니다. 모든 사소한 일에 대해 사례 필드를 성문화하는 것과 마찬가지로 CI 자동화가 "너무 똑똑하다"고 잘못 생각하고 성가 시게 될 수있는 지점이 있습니다. 새로운 케이스를 여는 것은 충분할 수 있습니다.
고마워요. 이것은 Chimps 설정을 FogBugz와 통합해야하는지 궁금합니다.
CC에는 빌드가 실패 할 때 경고하는 유틸리티가 포함되어 있습니다. FogBugz에서 실패한 빌드를 로깅 할 가치가 없을 것입니다. 대부분의 빌드가 깨질 경우 즉시 해결되는 문제는 추적 할 필요가 없습니다.
다른 방법으로 돌아가려면 (FogBugz는 문제를 해결 한 체크인을 표시 함) 웹 기반 저장소 브라우저가 필요합니다. FogBugz는 쉽게 구성하여 올바른 변경 사항을 보여줍니다.
우리 회사는 최근에 이슈 추적을위한 JIRA와 빌드를위한 Bamboo를 포함한 (상용) Atlassian 스택을 채택했습니다. 마이크로 소프트와 마찬가지로 (우리는 자바 샵이라고 생각합니다.) 단일 벤더로부터 모든 제품을 얻는다면 긴밀한 통합의 보너스를 받게됩니다.
어떻게 상호 운용성을 수행했는지 보여주는 예는 interoperability page입니다.
충분한 실링. 일반적으로 말하자면 일반적인 접근 방식을 다음과 같이 요약 할 수 있습니다. 버그 추적기 (예 : PROJ-123 키 발행)에서 문제를 생성하십시오.
:
귀하의 CI는 버그 추적기에 아무것도 넣을 필요가 없습니다되지 않습니다. Bamboo는 JIRA에 아무것도 넣지 않습니다. 대신, Atlassian 사람들은 JIRA에 플러그인을 제공하여 Bamboo로 원격 API 호출을하고 "Bamboo, 무엇이 I (JIRA 문제)와 관련된 것입니까?"라는 질문을합니다. 이것은 screenshot으로 가장 잘 설명됩니다.