다중 저장소 환경의 패키지 및 버전 전략

우리는 자체 팀 리포지토리를 관리하는 여러 팀이있는 작은 회사입니다. 이것은 웹 플랫폼이며 각 팀의 아티팩트는 매일 밤 테스트를 위해 배포됩니다. 버전 관리 및 패키징 관련 프로세스를 공식화하려고합니다.

모든 팀에는 일상적인 개발을 수행하는 마스터 지점이 있습니다. 각 팀의 품질 보증 담당자는 팀 변경 사항의 결과물을 요리사가 모든 구성 요소를 결합한 테스트 베드에 배포하기를 원합니다. 아티팩트는 타르볼이지만 버전을 올바르게 생각하고 추론 할 수 있도록 RPM으로 변환하고 싶습니다.

릴리스 프로세스에는 각 git 리포지토리의 개발 분기 (대부분의 경우 마스터)에서 릴리스 분기를 차단하는 과정이 포함됩니다. 그런 다음 일련의 아티팩트에서 테스트 및 사인 오프를 수행하는 품질 보증 담당자에게 제공됩니다.

예를 들어 이것은 관련된 릴리스 브랜치가있는 일반적인 git 저장소입니다.

 0-0-0-0-0-0-0-0-0-0 (master)
   |           |
   0           0
 (rel-1)       |
               0
            (rel-2)

개발 브랜치에서 오는 패키지의 버전 관리를 수행하기위한 계획을 찾으려고 노력하고 있습니다. 각 리포지토리의 마스터 분기에 과도한 태그를 지정하고 분기 만 해제하도록 태그를 제한하고 싶지 않습니다. 그러나 표준 yum / rpm 의미를 사용하여 테스트 시스템에서 배포 된 패키지를 쿼리 할 수 ​​있어야합니다. 마스터 브랜치에 태그가없는 경우 개발 버전은 어떤 모양입니까? 나는 git describe빌드 버전의 유용한 표현을 제공 할 수 있지만 지점의 다양한 릴리스 지점에 태그가 지정되면 잘 작동 한다는 것을 이해합니다 .

EDIT1 : @ Urban48 님의 답변에 답변

릴리스 과정을 좀 더 설명해야한다고 생각했습니다. 이 논의의 목적을 위해 master모든 저장소에 지점이 있다고 가정 합니다. master지점은 개발 지점으로 간주되고 자동화 된 CI-CD에 배포 QA 환경을 활성화. 이것은 마스터의 안정성을 보장하기 위해 야간 테스트의 하위 집합이 실행되는 곳입니다. 릴리스 브랜치를 절단하기 전에이 작업 파이프 라인을 살펴 봅니다. 릴리스 지점은 수명이 짧습니다. 예를 들어, 안정적인 마스터에서 릴리스 브랜치를 절단 한 후 전체 회귀가 실행되고 수정 사항이 작성되어 프로덕션에 배치됩니다. 이 작업을 수행하는 데 약 일주일이 걸립니다. 우리는 거의 2 주마다 생산을 릴리스합니다.

당사의 기능 분기는 항상 마스터에서 차단되며 CI-CD 안정성 검사를받는 마스터와 병합하기 전에 일정량의 개발자 테스트를 거칩니다.

핫픽스는 핫픽스 분기 (릴리스 분기에서 잘라 냄)에서 만들어지며 최소한의 영향 테스트로 프로덕션 환경에 배포됩니다.

릴리스 및 핫픽스 분기에 대한 버전 관리 전략은 다음과 같습니다. 같은 버전을 통해 품질 보증 사이클 이동하는 동안 가지를 출시 v2.0.0-rc1, v2.0.0-rc2및 품질 보증 사인 오프가 될 마지막으로 후 v2.0.0.

우리는 때때로 버전이되는 지점을 릴리스 (및 마스터)하기 위해 병합 된 작은 기능에 대해 점선 릴리스를 수행합니다 v2.1.0. 그리고 핫픽스는 v2.1.1패턴을 가정합니다 .

그러나 문제는 이러한 브랜치를 버전 화하는 것이 아닙니다. 이 버전 관리 체계를 완전히 변경하지 않는 것이 좋습니다. 유일한 변화는 개발 브랜치에 관한 것입니다. 석사. CI-CD 환경에서 이전 버전의 프로덕션 환경에 어떤 버전이 있는지 확실하게 표시하려면 어떻게해야합니까? 이것은 스마트 git 태깅을 통해 이상적으로 수행되지만 마스터 브랜치를 지나치게 태그하지 않는 것이 바람직합니다.

흠, 기술에 무관 한 .net 예제가 있습니다.

간단히 요약하겠습니다.

• gitflow 분기 전략을 사용하는 구성 요소 당 git repo

• 팀 도시 건설을 촉발시키는 모든 노력

• teamcity 빌드는 수동 메이저 마이너 + AssemblyInfo.cs의 빌드 번호 (예 : 1.1.hotfix.build)로 버전을 수정합니다.

• teamcity는 nuget 게시 라이브러리에 대해 동일한 버전 번호를 사용하여 nuget 패키징을 트리거합니다

• 문어는 수동 테스트를 위해 qa에 완성 된 빌드를 배포합니다 (모든 테스트에 합격 한 것으로 가정)

• 모든 것이 좋으면 문어를 통해 수동으로 버전을 프로덕션에 배포하십시오.

이제 이것은 많은 버전의 패키지가 떠 다니는 것을 의미합니다. 우리는 -prerelease 플래그를 사용하여 실험했지만 prelease에서 'normal'단계로 수동 이동 패키지를 추가로 필요로했으며 이에 종속 된 구성 요소를 다시 빌드해야했습니다.

핵심은 일부 중앙 프로세스를 통해 모든 빌드를 고유하게 버전 화하는 것입니다.

그런 다음 'omg, 어떤 버전이 있습니까?'대신 '어떤 버전을 원하십니까?'라는 상황에 처해 있습니다.

편집 : 댓글 다시 작성

그 핵심을 실제로 강조하기 위해. 완성 된 소프트웨어를 구성하는 분기와 ALL이 커밋 한 버전을 결정 합니다. 이 지점에서 버전이 지정된 소프트웨어 만 배포하십시오.

그러나 내 관점은 분기 전략을 해결해야한다는 것입니다.

• 기능 (또는 다른 개발자) 버전을 버전 화하지 마십시오.
• 버전 마스터
• 마스터 패키지 만 사용

버전 관리 문제를 해결하거나 솔루션에 대한 더 많은 방법을 생각하는 데 도움이되는 대체 워크 플로를 제공하겠습니다.

약간의 철학이 먼저 있습니다.
(워크 플로에 대해 몇 가지 가정을하고 있습니다. 틀린 경우 수정 해주세요)

1. 테스트는 소급하여 실행됩니다 .

   지점에서 maser지점을 제공 한 다음 QA에서 테스트 할 수 있도록 아티팩트로 전환합니다.
   문제는 테스트가 실패하면 중단 master될 수 있다는 것입니다!

   부작용:

   • 개발자가 믿지 못하게한다 master

   • 마스터에서 릴리스 분기로 분기하므로 이전 릴리스가 중단되면 어떻게됩니까? 마스터가 다시 수정 될 때까지 새 기능 통합을 중지합니다.

   • 릴리스 브랜치에서 버그가 수정되면 다시 master병합하여 병합 충돌 을 일으킬 수 있습니다. (그리고 우리는 갈등을 좋아하지 않는다)

2. 작은 코드 병합 및 수정 :

   master특정 기능의 일부가 아닌 작은 수정 또는 변경과 같이에 병합 된 모든 코드를 추적하기가 어렵습니다 .

   부작용:

   • 개발자는이 작은 수정 사항을 지금 또는 나중에 마지 여부를 잘 모릅니다.

   • 이 새로운 작은 수정 사항을 버전해야합니까?

   • 어느 시점에서 master분기 의 상태가 무엇인지, 어떤 코드가 거기에 떠 있는지 명확하지 않습니다.

   • 새로운 기능의 일부가 아닌 빌드가 깨졌습니다. 그리고 그것이 어디에서 왔는지 추적하기가 정말 어렵습니다.

자식 작업 흐름에 대한 내 아이디어는 다음과 같습니다.

master이미 새로운 기능 개발 을 위해 분기합니다 . 그러나 이제는 새로 생성 된이 지점에서 릴리스하는 대신이 기능을 선택하여 release지점으로 병합하십시오 .

이제 특정 릴리스로 진행되는 작업을보다 잘 제어 할 수 있습니다.
이제 개발 버전과 안정적인 버전을 쉽게 격리 할 수 ​​있습니다.

QA의 해당 기능 분기에서 아티팩트를 계속 빌드 할 수 있습니다.
모든 것이 정상이면 해당 기능을로 다시 병합 master하고이 기능 / 버그 수정 / 핫픽스를 릴리스 분기로 선택하십시오.

버전 관리
기능 분기 버전은 다음과 같은 이름 규칙을 사용할 수 있습니다.1.2.3-rc.12345

release브랜치 의 버전은 1.2.3 ( 1.2.3> 1.2.3-rc.12345걱정할 일이 적습니다)

이 워크 플로는 위에서 언급 한 문제 등을 해결합니다.
또한 올바른 버전 관리 전략을 제안하며이 릴리스주기의 대부분을 자동화 할 수 있습니다.

나는 그것이 당신에게 어떤 식 으로든 도움이되기를 바랍니다. 나는 당신이 생각해 낼 수있는 모든 경우를 기꺼이 논의 할 것입니다.

추신 :
나는 내 영어가 아닌 주된 언어가 아니라 사과합니다.

프로세스가 매우 복잡해 보이고 약간의 태그를 얻는 것은 피할 수없는 것처럼 보입니다.

두 가지 아이디어가 떠 오릅니다.

1. "마스터"지점은 일반적으로 "개발"지점에있는 것으로 취급합니다. 이것은 메시지 분기를 많이 오염시킵니다.

2. QA가 작업을 마치면 빌드 / CI 서버가 사용중인 모든 저장소의 태그가 포함 된 보고서 (예 : 텍스트 파일)를 만들 수 있습니다. 이제 repo에 게시 할 수있는 버전의 파일이 생성됩니다. 그런 다음 릴리스 버전만으로 분기에 태그를 지정하고 개별 구성 요소의 버전을 확인하려는 경우 보고서를 확인할 수 있습니다.