[continuous-integration] 지속적 통합에서 여러 분기 처리

CI 확장에 대해 이야기 할 때 실제로 주요 라인과 함께 모든 기능 분기를 처리하기 위해 CI 서버 사용을 확장하는 것에 대해 이야기하는 것입니다. 처음에는 지점의 개발자가 CI 작업에 포함 된 자동화 된 테스트의 모든 이점을 얻었으므로 이것은 좋은 접근 방식처럼 보입니다. 그러나 발견 한 것과 같은 CI 서버 작업을 관리하는 데 문제가 발생하고 더 중요한 것은 실제로 CI를 수행하지 않는다는 것입니다. 예, CI 서버를 사용하고 있지만 모든 개발자의 코드를 지속적으로 통합하지는 않습니다.

실제 CI를 수행한다는 것은 모든 개발자가 정기적으로 메인 라인에 참여하고 있음을 의미합니다. 말하기 쉽지만 어려운 부분은 응용 프로그램을 중단하지 않고 수행하는 것입니다. 지속적 배포 , 특히 13 장 : 구성 요소 및 종속성 관리 의 응용 프로그램 릴리스 가능 유지 섹션을 참조 하는 것이 좋습니다 . 요점은 다음과 같습니다.

• 완료 될 때까지 새 기능을 숨 깁니다 (일명 기능 토글 ).
• 일련의 작은 변경으로 점진적으로 모든 변경을 수행하십시오. 각 변경은 해제 할 수 있습니다.
• 추상화에 의한 분기를 사용하여 코드베이스를 대규모로 변경합니다.
• 구성 요소를 사용하여 다른 속도로 변경되는 애플리케이션 부분을 분리합니다.

추상화에 의한 분기를 제외하고는 꽤 자명합니다. 이것은 다음을위한 멋진 용어입니다.

1. 변경해야하는 시스템 부분에 대한 추상화를 만듭니다.
2. 추상화 계층을 사용하도록 시스템의 나머지 부분을 리팩터링합니다.
3. 완료 될 때까지 프로덕션 코드 경로의 일부가 아닌 새 구현을 만듭니다.
4. 새로운 구현에 위임하도록 추상화 계층을 업데이트합니다.
5. 이전 구현을 제거하십시오.
6. 더 이상 적절하지 않은 경우 추상화 계층을 제거합니다.

14 장 : 고급 버전 제어 의 분기, 스트림 및 지속적 통합 섹션 의 다음 단락 은 영향을 요약합니다.

점진적 접근 방식은 분기를 만들고 새로운 기능을 다시 설계하고 개발하는 데 궁호를 뛰어 넘는 것보다 더 많은 규율과주의, 그리고 실제로 더 많은 창의성을 요구합니다. 그러나 변경 사항으로 인해 애플리케이션이 중단 될 위험이 크게 줄어들고 병합, 파손 수정 및 애플리케이션을 배포 가능한 상태로 만드는 데 많은 시간을 절약 할 수 있습니다.

기능 브랜치를 포기하는 데 상당한 마음의 전환이 필요하며 항상 저항을 받게됩니다. 내 경험상이 저항은 개발자가 메인 라인에서 코드를 커밋하는 것이 안전하다고 느끼지 않는 데 기반을두고 있으며 이는 합리적인 관심사입니다. 이는 일반적으로 위에 나열된 기술에 대한 지식, 자신감 또는 경험 부족 및 자동화 된 테스트에 대한 자신감 부족에서 비롯됩니다. 전자는 교육 및 개발자 지원으로 해결할 수 있습니다. 후자는 처리하기 훨씬 더 어려운 문제이지만 분기는 추가적인 실제 안전성을 제공하지 않으며 개발자가 코드에 대해 충분히 확신 할 때까지 문제를 연기합니다.