우리는 프로젝트를 수행하고 있지만 프로젝트간에 많은 코드를 재사용하고 공통 코드를 포함하는 많은 라이브러리를 가지고 있습니다. 새로운 프로젝트를 구현함에 따라 일반적인 코드를 제외하고 라이브러리에 넣는 더 많은 방법을 찾습니다. 라이브러리는 서로 의존하고 프로젝트는 라이브러리에 의존합니다. 각 프로젝트 및 해당 프로젝트에 사용 된 모든 라이브러리는 참조하는 모든 라이브러리의 동일한 버전을 사용해야합니다. 소프트웨어를 출시하면 몇 년 동안, 때로는 수십 년 동안 버그를 수정하고 새로운 기능을 추가해야 할 것입니다. 우리는 약 12 개의 라이브러리를 보유하고 있으며, 변경 사항은 종종 2 개 이상의 프로세스를 삭감했으며, 여러 팀이 여러 프로젝트를 동시에 진행하여 이러한 라이브러리를 모두 동시에 변경합니다.
우리는 최근에 git으로 전환하고 각 라이브러리와 각 프로젝트에 대한 리포지토리를 설정했습니다. 우리는 숨김을 공통 저장소로 사용하고, 기능 분기에서 새로운 작업을 수행 한 다음 풀 요청을 작성하고 검토 후에 만 병합합니다.
프로젝트에서 다루어야 할 많은 문제는 여러 라이브러리와 프로젝트의 특정 코드를 변경해야합니다. 여기에는 종종 라이브러리 인터페이스의 변경이 포함되며 일부는 호환되지 않습니다. (이것이 비린 것처럼 들린다면 : 우리는 하드웨어와 인터페이스하고 일반 인터페이스 뒤에 특정 하드웨어를 숨 깁니다. 거의 다른 공급 업체의 하드웨어를 통합 할 때마다 현재 인터페이스가 예상하지 못한 경우가 발생하여이를 개선해야합니다.) 예, 프로젝트를 상상 P1라이브러리를 사용하여 L1, L2하고 L3. L1또한 사용 L2하고 L3, 그리고 L2용도 L3뿐만 아니라. 종속성 그래프는 다음과 같습니다.
<-------L1<--+
P1 <----+ ^ |
<-+ | | |
| +--L2 |
| ^ |
| | |
+-----L3---+
이제이 프로젝트를위한 기능의 변화를 필요로 상상 P1하고 L3있는의 인터페이스를 변경 L3. 이제 프로젝트를 추가 P2하고 P3이러한 라이브러리를 참조 믹스,에. 모든 인터페이스를 새로운 인터페이스로 전환하고 모든 테스트를 실행하고 새로운 소프트웨어를 배포 할 여유가 없습니다. 대체 대안은 무엇입니까?
- 새로운 인터페이스를 구현
L3 - 풀 요청을
L3하고 검토를 기다립니다 - 변경 사항을 병합
- 의 새로운 릴리스를 만들
L3 - 새 릴리스를
P1참조 하여 기능에 대한 작업을 시작한L3다음P1기능 분기 에 기능을 구현하십시오. - 풀 요청을하고이를 검토하고 병합합니다.
(방금 전환 L1하고 L2새로운 릴리스 로 전환하는 것을 잊어 버렸습니다 .이 부분을 고수 할 곳조차 알지 못합니다. 왜냐하면 병렬로 수행해야하기 때문입니다 P1...)
이는 지루하고 오류가 발생하기 쉽고이 기능을 구현하는 데 오랜 시간이 걸리므로 독립적 인 검토가 필요하며 (검토하기가 훨씬 더 어려워 짐) 전혀 확장되지 않으며 비즈니스를 중단시킬 수 있습니다. 우리는 아무 일도하지 않습니다.
그러나 너무 많은 오버 헤드없이 새로운 프로젝트에서 새로운 기능을 구현할 수있는 프로세스를 만들기 위해 분기 및 태깅을 어떻게 사용합니까?