고객 별 소프트웨어 패치를 처리하는 현실적인 방법은 무엇입니까?

16

다른 사람들이 다음 문제를 해결하는 효과적인 방법을 모 으려고합니다. 직장에서 우리는 특정 고객 만 볼 수있는 소프트웨어 패치 (최종 사용자 시스템에 설치)를 발표했습니다. 사용자 지정 코드는 자체 소스 제어 분기에 있습니다. 문제는 동기화를 유지하기 위해 두 개의 병렬 코드 라인 (및 빌드 스크립트)이 있으며, 원래 코드를 패치 할 때마다 고객 별 코드를 패치하고 테스트해야한다는 것입니다.

궁금합니다. 다른 조직에서이 시나리오를 어떻게 처리합니까? 우리는 비즈니스 솔루션에 개방하지 않은 단지 기술 (관련 소스 제어) 것들. 예를 들어, 고객에게 해당 지점에서 업데이트를받을 수 없음을 알리는 것에 대해 이야기했습니다.

우리의 브랜칭 전략은 다음과 같습니다 ( Visual Studio TFS 브랜칭 가이드를 기반으로 하지만 Subversion을 사용하고 있지만) 여기에 이미지 설명을 입력하십시오

version-control business release-management

— Vimes
소스

당신은 사용한 경우 hg또는 git당신이 패치 큐 (사용하여 볼 것을 제안 할 수 의욕 대기열 확장 또는 스택 힘내 )하지만 TFS는 아무것도 비슷한 경우 모르겠어요.

— Mark Booth

어쩌면 TFS 제안 분기 전략을 사용하더라도 Subversion을 사용하고있을 것입니다 .P 패치 대기열이 필요한 테스트를 줄입니까? 소스 제어 패치 용인 것 같습니다. 우리는 고객이 최종 사용자 시스템에 설치하는 패치를 다루고 있습니다.

— Vimes

2

비즈니스 솔루션은 다음과 같습니다.하지 마십시오.

— JeffO

@JeffO good call =) 어쨌든 이것을 데이터 구동 런타임 스위치로 만들 수있는 방법이 있습니까?

— Patrick Hughes

1

@JohnB는 - 죄송합니다, 나도 몰라,하지만 당신은 소스 패치가있는 경우 다음 빌드 시스템은 테스트를 자동화 할 수 있어야한다, 플러스 유지하는 고객마다하는 패치 의 외부 svn그들이 당신의 정상적인 흐름을 혼란하지 않는 의미합니다. 패치 대기열이 유용 할 것 같으면 git-svn 또는 hgsubversion을 사용하여 시험 대기열을 사용해 볼 수 있습니다 . DVCS 프런트 엔드를 사용하여 까다로운 워크 플로를 원활하게 수행하면 svn사람들이 DVCS 도매로의 이동을 고려하여 다른 모든 이점을 얻을 수도 있습니다.

— 마크 부스

5

고객에게 특정 패치를 제공하기 시작하면 제품과 함께 유지 관리해야하는 새 버전의 제품을 즉시 생성했습니다. 즉, 두 버전간에 변경 사항이 전파되어야합니다. 일반적으로 고객 별 패치는 소스 코드를 포함하여 고객이 소유해야하는 사용자 정의입니다.

문제 를 해결 하기위한 패치가 즉각적인 문제에 대한 최적의 임시 수정이 아니라면 메인 라인 분기로 만들지 않을 것 같습니다 . 이 경우 패치가 예상되는 수정 사항이 메인 라인에 포함될 때까지 패치를 유지하면됩니다.

— 찰스 램버트
소스

5

키가 "보이는"것 같습니다. 별도의 코드 분기가없는 것이 아니라 동작을 변경하는 구성 옵션은 어떻습니까?

— 로렌 페치 텔
소스

이는 간단한 사용자 정의에 효과적 일 수 있지만 더 복잡한 사용자 정의는 모든 고객에게 제품을 더욱 어색하고 불안정하게 만들 수 있습니다.

— FrustratedWithFormsDesigner

3

@FrustratedWithFormsDesigner 단일 클라이언트를위한 복잡한 사용자 지정은 제품 관리 및 디자인에서 심각한 태만을 나타냅니다. 제품의 단일 고객에 대해 별도의 지점을 필요로하는 솔루션은 제품 소유자의 모든 고객 요구와 불충분 한 청지기 직분을 충족시키기 위해 제품의 심한 부적절 함을 나타냅니다.

— maple_shaft

2

나는 또한 이것이 이전 고용주를 계속해서 물린 것을 보았다. 나쁜 습관 일 뿐이지 만 일반적으로 경영진이 원하고 되돌릴 수없는 일입니다. 특히 Subversion을 사용하는 경우 이것은 사라지지 않는 악몽 일뿐입니다. 코드를 동기화 상태로 유지하면 시간과 시간이 다치게됩니다.

— Steve Hill

1

@maple_shaft-그러나 "국제화를 구현하기 위해 코드 브랜칭을 사용해 본 적이 있습니까?"

— psr

3

@maple_shaft-농담 이었지만 실제로는 국제화를 처리하기 위해 분기를 사용하는 것이 적어도 고객 특정 지점만큼 나쁘다는 것이 내 요점이었습니다. 아마도 그런 곳에서 일하고 싶지 않다는 의미에서 똥이 아닙니다. 내가 주제를 상당히 벗어난 것이 무례합니다.

— psr

3

이것을 단기 또는 장기적인 것으로 보십니까? 사실 비즈니스는 이미이 고객을 수용하기로 결정 했으므로 단기적으로는 비즈니스 관행 (추가 비용 수용 / 고객의 비용 청구)을 통해 주로 해결해야하는 비즈니스 결정입니다.

장기적인 경우 구성 (또는 설정 등)을 통해 고객의 요구를 쉽게 수용 할 수 있도록 소프트웨어를 리팩터링하면 비용을 절감 할 수 있습니다.

상대적으로 단기적인 의미라면 곧 이러한 변경 사항을 기본 / 개발 지점으로 다시 병합하고 모든 사용자도 변경 사항을 볼 수 있으며 현재 상황의 한계 내에서 작업하는 것이 가능할 것입니다. 내가 말했듯이, 고객 수용에 대한 결정이 내려 졌을 때해야 할 일에 대한 결정이 이루어져야했다.

긴 이야기가 짧습니다. 장기적으로는 기술적으로 해결하고 단기적으로 처리하십시오.

물론 동전 던지기 지점이 있습니다. 그 시점에 있다면 개발자가 선호하는 모든 것을 할 것입니다.

— 엘그린 고 그란데
소스

2

우리는 subversion도 사용합니다-그리고 우리는 그러한 시나리오를 정확하게 보게됩니다.

기억해야 할 몇 가지 핵심 사항은 다음과 같습니다.

고객에게는 특정 지점을 피해야하지만 가능한 한 최소화해야합니다. 항상 모두에게 적합한 솔루션을 일반화 할 수 있는지 묻습니다.
고객 별 지점은 새 릴리스에서 시작해야합니다. 버전 1.2가 있고 버전 1.2.1에서 1.2.11까지 파생 된 것으로 가정합니다. 고객 지점에는 모든 패치가 허용되어야하므로 고객 지점은 기본 버전과 호환 가능 해야합니다 .
호환되지 않는 새 버전을 시작할 때 고객 별 지점을 새로 만들어야합니다. 불행한 부분은 어떻게 든 작업 을 다시 수행 해야 할 수도 있다는 것입니다. 한 가지 솔루션은 고객 지점에서 모든 패치를 작성하여 추출해야하며 여전히 호환 가능한 모든 항목을 새 고객 지점에 적용 할 수 있습니다.
어떠한 상황에서도 항상 고객 별 변경 사항을 푸시하여 지점 또는 트렁크를 해제해야합니다. 그러나 이상적으로는 이러한 고객 별 작업이 줄어드는 방식으로 작업을 일반화해야합니다.

나는이 아이디어를 함께 보여 주려고 노력했다 아래 다이어그램 .

— 디판 메타
소스

1

확장 메커니즘을 코드에 도입하는 것은 어떻습니까?

기본 코드는 다음과 같습니다.

class Foo
{
}

프로그램이 시작되면 시작 폴더에서 로컬 사용자 정의를 위해 DLL / moral equivalent을 검사합니다. 하나를 찾으면로드되고 회사 특정 버전의 Foo가 포함될 수 있습니다.

class FooForABC : Foo
{
}

FooForABC는 Foo와 동일한 동작을 구현하지만 ABC에 필요한 특정 동작을 제공하는 데 필요한 기능을 재정의합니다. 이 기술은 지원해야하는 모든 시나리오를 처리 할 수있을 정도로 유연해야합니다.

— 윈스턴 에워 트
소스