동일한 프로젝트 여러 클라이언트에 대한 분기 모델 제안

우리는 서로 다른 클라이언트의 기반으로 작동하는 여러 응용 프로그램을 포함하는 매우 큰 프로젝트를 보유하고 있습니다.

모든 고객은 제품, 다른 마일스톤, 다른 요구 사항 등을 자체적으로 가지고 있으므로 각 프로젝트는 자체 요구에 따라 독립적으로 발전 할 것입니다.

프로젝트의 핵심은 모든 프로젝트에서 비슷 하지만 (균등하지는 않음) 조직은 각 고객을 독립적으로 처리하는 팀 (필요에 따라 그들 사이의 커뮤니케이션)을 갖도록 만들어졌습니다. 지금까지 인터넷을 검색하거나 훌륭한 아이디어를 제시하여 우리의 요구에 맞는 구성표를 찾을 수 없었습니다. :)

지금까지 우리는 제품을 모든 요구 사항에 맞게 변경하고 필요한 변경 사항에 대한 특정 분기를 제공하기 위해 노력하고 있지만 제품의 아키텍처는 우수하지만 천천히 큰 문제가되고 있습니다. 우리가 직면 한 주요 문제는 다음과 같습니다.

• 각 고객에 대한 다른 이정표 : 이는 각 팀이 안정성이나 제품에 영향을 미치는 나머지 커밋없이 다른 시간으로 버전을 제작해야 함을 의미합니다.
• 경우에 따라 시스템의 핵심에 영향을 미치거나 영향을 줄 수있는 다른 요구 사항
• 대규모 팀 (20 명 이상의 팀원)
• 시스템 버그 처리 : 팀이 프로젝트에서 다른 고객에게 영향을 줄 수있는 버그를 발견하면 어떻게해야합니까?

참고 : 우리는 10 + M LOC를 가진 프로젝트에 대해 이야기하고 있습니다.

참고 : Team Foundation System, Visual Studio 2008 및 C # (주로)을 사용하고 있습니다.

상황을 해결하는 방법에 대한 제안, 출처 또는 아이디어가 있습니까? 시장에 비슷한 문제가있는 모델이 있습니까?

실제로 분기 모델이 필요 하지 않고 분기가 없는 시스템과 관련하여 다차원 제약 조건을 처리하기위한 완전한 포괄적 인 접근 방식이 필요 합니다. 실제로는 공통점이 있지만 분기마다 다르게 발전하는 여러 시스템을 유지 관리하는 것이 항상 문제가 될 수 있으므로 모든 것을 단일 시스템으로 바꾸어 전체적으로 발전하지만 서로 다른 구성으로 구성하는 것이 좋습니다. 이것은 너무 단순 해 보이지만,이 분야에서 많은 성공적인 산업 응용 분야에 대한 광범위한 연구가 진행되고 있습니다.

이 접근 방식의 이름은 소프트웨어 제품 라인 또는 제품 라인 엔지니어링 입니다. 에서 CMU SEI의 소프트웨어 제품 라인 페이지 :

소프트웨어 제품 라인 (SPL)은 특정 시장 세그먼트 또는 미션의 특정 요구를 충족시키고 규정 된 방식으로 공통 핵심 자산 세트에서 개발 된 공통 관리 기능 세트를 공유하는 소프트웨어 집약적 시스템 세트입니다. .

핵심 아이디어는 모든 요구 사항, 이정표, 모든 기능 (이 도메인의 핵심 용어)이 최고 수준의 전체 시스템의 일부라는 것입니다. 다양한 고객에게 배포 된 실제 시스템은 기본적으로 기능 모음입니다. 그러나 각 기능은 시스템에 으깬 물리적 구성 요소 일뿐 아니라 다른 기능에 따라 정의되거나 다른 기능에 의해 활성화됩니다 (따라서 기능을 선택하면 자동으로 종속성 등을 포함시킬 수 있습니다).

이 모든 지점을 유지 관리하는 대신 고객 별 구성 세트와 함께 하나의 시스템을 유지 관리해야합니다.

실제로는 매우 큰 시스템을 사용하여 이러한 접근 방식으로 마이그레이션하는 것이 어렵거나 불가능할 수도 있지만, 적어도 (부분적으로) 어떤 접근 방식을 사용할 수 있는지 평가하기 위해 SPL에 사용 된 접근 방식을 조사하는 것이 유용합니다. 당신의 작업에 통합.

추가적인 유용한 링크들 :

• Wikipedia : 제품 라인 엔지니어링
• CMU SEI의 사례 연구
• 소프트웨어 제품 라인 , 소개 자료가 많은 사이트.

첫 직장에서 시작했을 때 비슷한 프로젝트를 수행했지만 규모는 작았지만 같은 문제에 직면했습니다. 또한 모든 클라이언트에 대한 일반적인 솔루션 처리 요구 사항으로 시작했지만 요구 사항이 모순되는 지점까지만 가능했습니다. 각 고객에 대해 제안하고 별도의 버전을 시작했습니다. 이로 인해 요구 사항 및 사용자 지정 문제가 해결되어 버그 및 전역 변경 사항을 해결하기위한 유지 관리의 악몽이되었습니다.

응용 프로그램의 코드는 비슷하기 때문에 한 고객 버전에서 다른 고객 버전으로 변경 사항을 병합하는 것은 매우 복잡했으며 각 버전을 개별적으로 다시 테스트해야했습니다 (자동 테스트는 없었습니다!). 다른 버전에서 회귀 버그가 종종 발생했습니다. 시나리오에서 한 팀은 해당 버전의 버그를 해결하고 다른 팀은 변경 사항을 완전히 이해하지 못하는 버전 (우리는 모든 버전에서 작업하는 한 팀)과 병합해야하기 때문에 상황이 더욱 악화 될 수 있습니다.

공유 글로벌 코어가 없으면 동일한 문제가 발생합니다. 회사를 떠나기 전에 우리의 접근 방식이 틀렸다는 것을 알았습니다. 이러한 개발 시나리오를 지원하기 위해 상위 사용자 지정 가능한 응용 프로그램 계층에서 구성 할 수있는 공유 가능한 확장 가능한 코어 및 데이터 모델이 필요했습니다. 이 핵심은 각 고객 별 맞춤화의 기반으로 사용되며 별도의 팀에서 유지 관리해야합니다. 여러 프로젝트 관리자가 동일한 팀의 리소스를 필요로하기 때문에 관리상의 복잡성이 포함되지만 아키텍처를 일관되게하고 전체 프로세스를 제어하며 버전을 동기화하는 유일한 방법입니다.

나는 기본이 될 수 있지만 시스템의 핵심과 직면하고있는 것은 구성 요소를 사용하고 소프트웨어의 다른 릴리스를 유지 관리하고 지원 해야하는 모든 사람이 직면하는 동일한 문제이며 각각 다른 릴리스가 필요하다고 생각합니다 구성 요소 버전.

예를 들어

• 릴리스 1.0에는 라이브러리 A 1.0, 라이브러리 B 2.0, 라이브러리 C 5.6이 필요합니다.
• 릴리스 2.0에는 라이브러리 A 1.0, 라이브러리 B 3.7, 라이브러리 C 5.7이 필요합니다.
• 릴리스 3.0에는 라이브러리 A 1.2, 라이브러리 B 3.7, 라이브러리 C 5.8이 필요합니다.

컴포넌트 문제를 해결하는 방법은 모든 버전의 라이브러리를 버전 제어 시스템에 배치하고 (소스에서 빌드) 검색 경로 (참조 경로?)를 변경하여 각 프로젝트가 올바른 라이브러리 버전을 사용하도록하는 것입니다.

델파이에서는 디자인 타임에 라이브러리가 필요하지 않으면 프로젝트 구성 파일 (소스 제어하에)을 통해 쉽게 수행됩니다. 그렇지 않으면 여전히 가능하지만 델파이 IDE를 사용하도록 전환해야하므로 약간 더 고통 스럽습니다. 올바른 버전도 있습니다 (버전 관리중인 등록 (.reg) 파일이 여기에 올 수 있습니다).

코어 시스템의 해결책은 다른 버전을 유지 관리하는 라이브러리로 처리하는 것입니다. 본질적으로 각 버전마다 다른 브랜치를 설정해야 함을 의미합니다. 그러면 클라이언트 응용 프로그램은 적절한 코어 시스템의 분기 폴더를 참조하여 코어 시스템의 올바른 "버전"을 사용할 수 있습니다.

코어 시스템에 대한 종속성이 위의 예와 유사 할 경우 클라이언트 응용 프로그램에 대한 종속성은 추가 참조를 갖습니다. 즉, 코어 시스템의 버전입니다.

여러 클라이언트 응용 프로그램의 장점은 특정 버전의 코어 시스템 사용을 시작할시기를 선택할 수 있으며 아직 특정 클라이언트 응용 프로그램에 사용할 준비가되지 않은 코어 시스템 변경의 영향을받지 않는다는 것입니다.