대규모 조직에서 가지를 피하는 방법?

대규모 조직에서 작업 할 때 분기 별 상황을 어떻게 피합니까?

우리는 소프트웨어를 업데이트하지 않고 높은 / 중요 보안 패치 및 맞춤형 기능 만 사용하는 여러 대기업과 협력하고 있습니다. 이러한 조직은 주요 업데이트간에 만 패치 및 사용자 지정 릴리스를 수행합니다. 주요 업데이트는 몇 년이 소요될 수 있으며 비용이 많이 듭니다. 이러한 접근 방식을 통해 우리 (소프트웨어 회사)는 주요 고객 당 코드 분기를 가지게되는데, 이는 장기 분기의 모든 비용과 비 효율성을 수반합니다.

커뮤니티에 대한 나의 질문은 다음과 같습니다.

• 고객으로부터 유사한 업데이트 수락 방법을 경험 했습니까?
• 이 접근법을 사용하는 데 도움이되는 제안은 무엇입니까?
• 소프트웨어 업데이트에 대한 조직의 접근 방식을 변경하는 데 도움이되는 제안은 무엇입니까?

Michael이 언급했듯이 릴리스 버전 / 수를 기준으로 표준 수명주기를 제공하는 표준 솔루션을 제공하십시오 (일반 고객에게는 의미가있는 경우 하나 이상의 짧은 수명 중간 버전으로 인터리브 될 수 있음).

고객에게 적절한 표준 마이그레이션 마감일이있는이 표준 릴리스 트랙을 시작할 수있는 옵션을 제공하십시오.

그들이 완전한 맞춤형 지사 지원 전략을 고집한다면, 그에 따라 요금을 청구하고, 그러한 완전한 맞춤형 지원을 제공하기위한 모든 추가 비용을 적절히 충당하기 위해 – 그것은 사업 적으로 만 이해됩니다. 일부 고객은 비용을 절감하기 위해 마이그레이션 할 것입니다 (사용자 지정 지점 수를 줄이는 데 도움이 됨).

사용자 지정 브랜치가 시작된 릴리스 버전의 연령에 따라 점진적으로 증가하는 변수 지원 청구는 고객이 더 새로운 브랜치로 더 빨리 마이그레이션하여 이전 사용자 지정 브랜치를 더 빨리 닫는 데 도움이 될 수 있습니다. 이렇게하면 여러 버전의 소프트웨어를 동시에 실행하는 고객이있는 경우 고객 당 사용자 지정 분기 수를 줄일 수 있습니다.

릴리스 브랜치 (표준 및 사용자 정의 모두)에서 전체 브랜치 병합을 수행하는 함정에 빠지지 않도록하십시오. 모든 변경 브랜치는 개별적으로 개발되거나 통합 된 수정 사항이어야합니다.

이러한 각 브랜치가 점차 서로 분기되므로 커스터마이징 / 개별 개발이 필요한 핫픽스의 수가 기하 급수적으로 늘어날 것입니다 (일반 체리 픽 병합 병합 실패). 이를 위해서는 개발 비용을 고려해야합니다.

그림에 (중요한) 브랜치 병합이 없으면이 브랜치에 대해 완전 자동화 된 CI / CD 파이프 라인을 구축 할 수 있으며 (좋은 중요성을 강조 할 수는 없음), 우수한 핫픽스 추적 / 관리 시스템을 갖추어 핫픽스를 제공합니다. 그냥 일상적인 (또는 거의).

고객이 아닌 버전별로 지점을 유지 관리하면 고객 수를 줄이는 데 도움이 될 수 있습니까?

그렇지 않으면 소프트웨어에서 실제로 벗어날 수있는 유일한 방법은 소프트웨어를 직접 호스팅하고 SaaS 모델로 전환하여 한 버전 만 유지할 수있는 것입니다.