다면 프로젝트에서 버전 관리를 어떻게 처리합니까?

나는 그것이 광범위한 질문이라는 것을 알고 있으므로 가능한 한 구체적으로 노력할 것입니다. 이 질문은 기술적 인 질문보다 "조직적인"질문입니다.

우리는 다음과 같은 주요 구성 요소로 된다면 프로젝트를 가지고 있습니다.

• 핵심 비즈니스 로직 (데이터 모델)을 호스팅하는 서버
• 핵심 비즈니스 로직을 사용하는 고객을위한 백 오피스
• 핵심 비즈니스 로직도 사용하는 애플리케이션 API (REST)
• 응용 프로그램 API를 사용하는 스마트 폰 앱 (iOS 및 Android)이 있습니다
• 동일한 응용 프로그램 API를 사용하는 스마트 폰과 다른 태블릿 앱 (android)이 있습니다.

곧 나는 적극적인 고객들과 함께 프로덕션에있을 것입니다. 그리고 모든 프로젝트로서, 시간이 지남에 따라 모든 다른 구성 요소를 유지해야합니다. 즉, 다음을 모두 업그레이드 할 수 있습니다.

• 서버의 핵심 비즈니스 로직 코드 (백 오피스, API 및 모바일 앱에서 부작용으로 사용)
• API 자체 (스마트 폰 및 태블릿 앱 모두에서 사용)
• 모든 모바일 앱 (appstore / googleplay를 통해)

물론 서버 측 부분 (핵심 비즈니스 로직 코드 및 API 코드)은 즉시 변경할 수 있습니다. 그러나 클라이언트가 appstore / googleplay에서 새로운 모바일 앱을 다운로드해야하며 최신 버전인지 확실하지 않습니다.

이러한 업그레이드를 고객에게 원활하고 위험없이 수행 할 수 있도록 지침, 모범 사례 팁을 제공 할 수 있습니까?

어떤 버전을 "버전"해야합니까? 클라이언트가 모바일 앱을 업그레이드하지 않아도 모든 것이 작동하도록하는 방법은 무엇입니까? 작업을 쉽게하기 위해 업그레이드하도록 강요해야합니까?

한마디로, 시간이 지남에 따라다면 프로젝트를 살리기 위해 어떻게 조직해야합니까?

모바일 앱이 새 릴리스로 업데이트되는시기를 제어 할 수 없으므로 최소한 REST API를 버전 화해야합니다. 그렇지 않으면 해당 인터페이스에 대해 이전 버전과 호환되지 않는 변경을 수행 할 수 없습니다.

REST API 외에도 네트워크 인터페이스를 통과하는 다른 통신 인터페이스도 버전 화하는 것이 좋습니다. 이렇게하면 서버와 동시에 모든 백 오피스 클라이언트를 업그레이드하지 않아도되며 "베타 테스트"기간을 사용하여 새 버전으로 점진적으로 마이그레이션 할 수 있습니다.

통신 인터페이스를 버전 화하는 것 외에도 변경 사항을 가능한 한 호환되도록 변경해야합니다. 이상적으로 이전 클라이언트를 완전히 지원하는 새로운 인터페이스 버전을 출시하여 변경 사항을 알지 못하는 것이 이상적입니다.

이 게시물 은 귀하의 질문에 대해 흥미로운 지적을합니다.

보다 실용적인 방법으로 3 개의 구성 요소가있는 경우 :

• 소비자 2 명 : 프런트 엔드 및 모바일 앱
• 1 API 제공 업체 : 백엔드

각각에 대해 전형적인 Mmp (Major.minor.patch) 버전 관리 체계를 사용할 수 있지만 백엔드 URL에는 다음과 같은 것을 넣을 수 있습니다 http://youhost/M.m/resourceURI.

발전함에 따라 API의 변경 사항은 소비자와의 계약에 영향을 미치지 않으며 M.mURL에있는 그대로 유지합니다 . 소비자에게 영향을 미치는 백엔드를 변경하는 순간 (행동이나 개체가 다른 경우) M.m+1, M+1.m+1또는 을 사용합니다 M+1.m.

작동 상태를 유지하는 방법은 이전과 동시에 새로운 백엔드를 배포하는 반면 사용자는 새로운 소비자를 설치하고 이전 API는 천천히 중단하는 것입니다.

여기, 내 것보다 더 나은 방법 답을 볼 수 있습니다 유래에 버전 REST API를

지속적인 통합 서버를 설치하고 코드 리포지토리 및 스냅 샷 / 릴리스 리포지토리에 연결하고 빌드를 자동화하는 것이 좋습니다. 여기에는 여러 가지 장점이 있습니다.

1. 모든 구성 요소는 릴리스 될 때 버전이 지정됩니다. 여기에는 최종 제품뿐만 아니라 저수준 라이브러리가 포함됩니다.
2. 모든 코드 커밋은 스냅 샷 빌드를 트리거합니다. 이는 특히 시설을 사용하여 빌드를 중단 한 범인에게 이메일을 보내는 경우 개발자에게 정직성을 유지하는 데 도움이됩니다.
3. 모든 빌드는 단위 테스트를 실행할 수 있습니다. 이것은 코드 품질을 크게 향상시킵니다.
4. 모든 릴리스에는 태그가 지정되므로 프로덕션 수정이 필요한 경우 태그에서 분기하여 수정하기가 쉽습니다.
5. 어떤 종류의 호환성 레지스터를 유지해야합니다. (예 : BackOffice 1.0.23은 REST API 2.0.267 등과 호환됩니다). 이 분야에서 도움이 될 도구를 모르겠습니다.

SVN, Maven 2, Jenkins 및 Nexus와 같은 오픈 소스 도구에 대한 경험이 있지만 이러한 모든 대안이 있습니다.

팀의 속도를 높이기 위해 학습 시간을 과소 평가하지 마십시오. 그러나 일단 속도가 빨라지면 결코 다시는 돌아 가지 않을 것입니다.

비교적 소규모의 개발 및 배포 팀의 경우 IBM Jazz에서 채택한 Client N-1 호환성 모델이 제대로 작동 할 수 있습니다.

클라이언트와 서버를 동일한 버전 번호로 유지 하십시오 . [독립 버전의 매트릭스와 호환성을 관리하는 대신]

클라이언트 버전 Xyy가 Xyy보다 높지만 X + 2.0.0보다 낮은 모든 서버 버전에서 작동하도록 정책을 만듭니다.

서버 버전 4.0의 경우 모든 클라이언트 유형에 대해 클라이언트 버전 4.0이 이상적입니다. 그러나 약간 다른 버전의 클라이언트 및 서버를 허용하도록 호환성을 유지해야합니다.

클라이언트 버전 4.x는 서버 버전 4.x 이상 6.0 미만과 호환되어야합니다. 서버 4.x는 모든 클라이언트 버전 3.0 이상과 호환되지만 4.x 이하이어야합니다.

이렇게하면 새 버전의 클라이언트가 즉시 릴리스 될 염려없이 서버에서 버전을 업데이트 할 수 있지만 유지 관리를 위해 잘 정의 된 호환성 창이 있습니다.

참조 : IBM Jazz 모델 [ https://www.ibm.com/support/knowledgecenter/en/SSYMRC_6.0.0/com.ibm.jazz.install.doc/topics/c_n-1.html]

먼저, 문제를 조금 다르게 구성하여 시작하겠습니다. "버전"에 필요한 소프트웨어를 물었습니다. CS에서 버전은 오버로드 된 용어이며 약 100 개의 다른 것을 의미 할 수 있습니다. 내가 볼 기본 사항은 다음과 같습니다.

1. 버전 관리-버전 관리는 구성 관리 도구로 스냅 샷 및 개발 기록을 추적 할 수 있습니다. 모든 코드는 버전 제어하에 있어야합니다. bin 폴더에 추가하는 편리한 스크립트 만 있으면 상관하지 않습니다. 작성하는 데 시간이 걸리는 것은 개정 제어 소프트웨어에 추가하는 데 2 ​​초의 가치가 있습니다.
2. 구성 관리-빌드의 내용을 제어하는 ​​방법 모든 소프트웨어에는 어느 정도의 구성 관리가 있어야합니다. 버전 관리는 개발 이력을 추적하는 도구 일뿐 아니라 구성 관리는 이력을 만드는 방법에 대한 지침이며 코드 결정과 같은 작업을 수행하는 방법에 대한 지침이므로 관리자에게 버전 제어와 구성 관리의 차이점을 설명하고 싶습니다. 좋습니다.
3. 소프트웨어 버전 관리-코드 릴리스에 이름 지정 이것은 많은 사람들이 "MineSweeper 7.1.29290149210"이나 구매 한 물건을 보는 데 사용하기 때문에 문제를 처음 볼 때 고정되는 것입니다. 그러나 솔직히 저는 이것이 더 큰 문제의 가장 작은 부분임을 알게됩니다. 솔직히 말하면, 1에 의해 생성 된 해시를 사용하고 사람이 읽을 수없는 것이 완벽하게 잘 처리되도록 신경 쓰지 마십시오.

그것이 가장 성 가시고 가장 흥미 롭기 때문에 # 2에 집중할 것입니다. 구성 관리에 적합한 단일 크기의 쿠키 커터 솔루션은 없습니다. 2 명 또는 3 명으로 구성된 팀에 적합한 규칙은 너무 느슨하여 수백 명의 근로자를 고용하는 프로젝트에서 정신을 버리지 못할 수 있습니다. 큰 팀에 적용되는 규칙은 작은 팀에게는 너무 많은 오버 헤드가 필요할 수 있습니다. 무언가를 모으기 위해 자신의 무언가를 조롱해야 할 수도 있지만 구성 관리 시스템의 사양을 개발하는 방법으로 다음 목록을 사용합니다.

1. 시장에서 지원하는 버전 (및 관련 문제)을 어떻게 추적 할 수 있습니까?
2. 프로덕션 시스템으로 출시 할 개발 경로를 어떻게 결정합니까? (프로세스의 다른 단계에서도 준비 될 수 있습니다)
3. 누가 시스템 구성을 제어 / 관리해야합니까? 다른 개발자에게 배포 할 코드를 추가하는 워크 플로우는 무엇입니까?
4. 상호 작용하는 부분 간의 상호 작용을 어떻게 제어합니까? 부품을 변경하면 나머지 시스템이 손상되는지 어떻게 알 수 있습니까?
5. 시간이 지남에 따라 구성 관리 시스템을 개선하는 방법

위의 질문에 대답하는 데 도움이 필요하십니까? 교과서를 채울 수 있으며 컨설턴트는 이런 유형의 포럼에서 벗어날 수있는 컨설턴트 또는 소프트웨어 엔지니어링 관리자를 고용해야합니다.