공유 어셈블리 버전 관리 및 문제 추적

Question

우리는 3 개의 다른 프로젝트 (.NET)를 개발하는 3 개의 팀을 보유하고 있으며 공통 코드 및 제어 공유 라이브러리가있는 프로젝트가 하나 있습니다. 각 팀은 Mercurial의 하위 저장소를 사용하여이를 참조합니다. 각 팀은 자신의 프로젝트에서 버그를 수정하기 위해 SharedLibrary에 변경 사항을 푸시 할 수 있습니다. 따라서 한 프로젝트에 버그를 수정하면 두 번째 버그에 버그가 생길 수 있습니다.

우리는 이슈 추적을 위해 JIRA를 사용하고 있으며, 각 팀과 SharedLibrary에 대해 4 개의 프로젝트가 있습니다.

누구나 워크 플로를 제안 할 수 있습니다. 통합 실패 가능성을 줄이며 (한 팀이 다른 팀 프로젝트를 중단 함) 가능한 경우 빨리 실패를 알리는 데 도움이됩니까?

포인트 고려해야 할

1. 우리는 JIRA에서 SharedLibrary에 대한 버전 필요하십니까? 어떻게 유지되어야 하는가?

2. 누가 공유 라이브러리의 변경 사항을 확인합니까?

3. hg에 지점을 구성하는 가장 좋은 방법은 무엇입니까?

4. JIRA 워크 플로를 구성하는 가장 좋은 방법은 무엇입니까? ShareLibrary 문제는 JIRA의 어떤 프로젝트에서 제기 되었습니까?

비슷한 상황에 대한 워크 플로/솔루션에 대한 도움말이나 사례를 제공해 주시면 감사하겠습니다. 제안

Answer 1

커플 :

1. 예, 당신은 당신이 당신의 다른 프로젝트를 할 것처럼 SharedLibrary에 대한 버전을 유지해야한다. 3 개의 프로젝트 각각의 릴리스를 SharedLibrary의 특정 버전에 연결해야합니다. 3 개 프로젝트 팀 중 하나가 다른 팀을 참조하지 않고 프로젝트 팀을 변경하게한다면 호환되지 않는 변경 사항을 도입 할 위험이 높습니다.
2. SharedLibrary가 특정 사용자 또는 팀에 의해 유지 관리되지 않는 경우 SharedLibrary에 대한 업데이트 검토를 담당하는 각 프로젝트 팀의 대표로 구성된 교차 기능 팀을 제안하는 것이 좋습니다. JIRA는 버전별로 이슈를 추적 할 수 있습니다. 변경 사항이 다른 프로젝트를 손상시키지 않는지 확인하려면 Jenkins와 같은 지속적인 통합 서버에서 실행할 수있는 각 프로젝트에 대한 포괄적 인 테스트 세트를 준비하십시오.
3. 여기에 특별한 제안이 없습니다.
4. 저는 SharedLibrary를 별도의 JIRA 프로젝트로 유지할 것입니다.