“모든 제품에 대한 하나의 큰 VCS 리포지토리”조직 모델에서“다수의 작은 VCS 리포지토리”모델로 원활하게 전환하는 방법은 무엇입니까?

일부 VCS 시스템에서 저장소 가 보유한 제품의 코드베이스가 해당 코드베이스가 여러 제품을 포함하는 것으로 보일 수있는 지점으로 발전 하는 것이 일반적인 시나리오입니다 . 코드베이스를 여러 VCS 리포지토리 (각각 단일 제품 전용)로 분할하면 여러 가지 이점을 활용할 수 있습니다 ( 아래 의 팽창 저장소 모델 보다 VCS 리포지토리 당 제품이 갖는 이점 참조). 기술적 인 측면에서, 대부분의 VCS가이 작업을 지원하므로 코드베이스 분할은 다소 쉬운 단계입니다. 그러나 스플릿은 자동화 된 테스트, 지속적인 제공, 서비스 통합 또는 모니터링과 관련된 엔지니어링 문제를 야기 할 수 있습니다 ( 스 플리트가 제기 한 문제 참조).) 따라서 이러한 분할을 수행하려는 조직은 전달 및 모니터링 파이프 라인을 방해하지 않고 가능한 한 원활하게이 전환을 수행하는 방법을 알아야합니다. 이것의 첫 단계는 아마도 프로젝트 의 개념 과 모 놀리 식 코드베이스에서 분할을 묘사하는 방법을 더 잘 이해하는 것입니다 .

이 질문에 대한 답변에서 다음과 같은 내용을보고 싶습니다.

1. 제품이 무엇인지에 대한 실제적인 정의를 제공하려는 시도로, 기존 코드베이스에서 실제로 제품을 묘사하는 실제 기준을 제공합니다.

2. 이 작업 정의에 따르면 실제로 분할을 수행하는 계획을 정교화하십시오. 우리는 코드베이스가 연속 통합 및 연속 전달을 구현 하는 완전 자동화 된 sdlc에 의해 처리된다는 가정을 단순화 할 수 있습니다 . 즉, 각 코드는 현재 코드베이스에서 구현 된 자동화 된 테스트 슈트에 의해 유효성이 검사되며 각각의 "매직"브랜치에 병합되어 테스트되고 배포 된 제품 아티팩트 가 생성됩니다 . ( 제품 아티팩트 는 예를 들어 소스 타르볼, 문서, 이진 소프트웨어 패키지, Docker 이미지, AMI, 유니 커널입니다.)

3. 그러한 계획은 그것을 우회하는 방법을 설명한다면 만족 스럽다

분할로 제기 된 문제

1. 자동화 된 테스트 절차가 기존 단일 저장소 및 분할 저장소와 어떤 관련이 있습니까?

2. 자동화 된 배포 절차가 기존의 모 놀리 식 리포지토리 및 분할 리포지토리와 어떤 관련이 있습니까?

3. 자동 배포 절차 자체의 코드는 어디에 저장됩니까?

4. 저장된 인프라 , 모니터링 및 고 가용성 전략 은 어디에 있습니까 ?

5. 개발자가 한 번에 하나의 코드베이스 만 필요로하는 방법 (그러나 다른 코드베이스의 아티팩트를 사용할 수 있음)

6. git-bisect 와 같은 도구는 어떻게

한계 참고 사항 : 팽창 저장소 모델에 비해 VCS 저장소 당 제품을 갖는 이점

특정 제품에 대한 코드베이스를 보유하고있는 여러 개의 작은 저장소가 있으면 "팽창 저장소"접근법에 비해 다음과 같은 장점이 있습니다.

1. 팽창 저장소를 사용하면 히스토리가 다른 제품 히스토리와 혼합되므로 제품이 불안정 할 때 릴리스를 롤백하기가 어렵습니다.

2. 부풀린 저장소를 사용하면 프로젝트 히스토리 또는 풀을 검토하기가 어렵고 작은 저장소를 사용하면이 정보를 읽을 가능성이 높습니다. (이것은 git과 같은 VCS에만 해당 될 수 있습니다. svn과 달리 하위 트리를 체크 아웃 할 수 없습니다!)

3. 팽창 저장소를 사용하면 개발할 때 훨씬 더 많은 분기 댄스를 수행해야합니다. N 리포지토리가있는 경우 N 개의 브랜치에서 병렬로 작업 할 수 있고, 하나의 리포지토리 만있는 경우 하나의 브랜치에서만 작업하거나 처리하기 어려운 작업 복사본이있을 수 있습니다.

4. 여러 개의 작은 리포지토리가있는 경우 로그는 프로젝트의 히트 맵을 제공합니다. 그들은 심지어 개발 팀에서 지식 확산의 대리자로 사용될 수 있습니다 .3 개월 이후 repo X에 커밋하지 않으면 repo X 작업 팀에서 나를 개발에 대해 알고 있도록 할당하는 것이 좋을 수 있습니다 해당 구성 요소에서.

5. 작은 리포지토리를 사용하면 구성 요소에 대한 명확한 개요를 얻는 것이 더 쉽습니다. 모든 것이 하나의 큰 저장소에 들어가면 각 구성 요소를 묘사하는 확실한 인공물이 없으며 코드베이스는 진흙의 큰 공을 향해 쉽게 표류 할 수 있습니다 .

6. 소규모 리포지토리를 사용하면 구성 요소 간 인터페이스 작업을 수행 할 수 있습니다. 그러나 우리는 좋은 캡슐화를 원하기 때문에 어쨌든해야 할 일이므로 작은 저장소의 이점으로 간주합니다.

7. 여러 개의 작은 리포지토리를 사용하면 여러 제품 소유자를 보유하는 것이 더 쉽습니다.

8. 여러 개의 작은 리포지토리를 사용하면 전체 리포지토리와 관련되고 자동으로 확인할 수있는 간단한 코드 표준을 사용하는 것이 더 쉽습니다.

실제 답변이 실제로 존재하지 않을 수도있는 매혹적인 질문입니다. VCS에 대한 질문을 상황에 맞게 유지하려고 노력했지만 자연스럽게 자체적으로 인프라 설계 및 구현 계획에 따라 확장되었습니다.

비록 우리 중 많은 사람들이 이런 종류의 전환을 위해 노력하고있는 것 같습니다. 그것은 흥분 될 수 있지만, 동시에 너무 실망스럽고 고통 스럽습니다. 그리고 나는 내 경험과 견해를 공유하고 싶지 않았으며 단지 훌륭한 엔지니어가 아니기 때문에 지루하지 않아야합니다.

디자인

최신 소프트웨어를 작성하려면 인프라와 아키텍처가 함께 있어야합니다. 원하는 경우 단단히 결합하십시오. 그 단어를 사용하는 것이 이상하게 들릴지 모르지만 여기서는 코드 자체에 대해 확실히 이야기하고 있지 않습니다. 동일한 코드의 일부 여야 함을 의미합니다. 구름이 도착하고 사람들이 소프트웨어를 작성하기 시작했을 때, 얼마나 많은 사람들이 머드 볼을 거기에두면 다른 장소에서 같은 머드 볼일 뿐이라는 것을 깨달았습니다 (?) 그리고 그들은 오늘날 devops에서 일하고있을 것입니다. devops는 다른 사람들에게 많은 다른 의미를 가진 유행어이므로, devops 팀이 모든 건축 회의에서 앉을 장소를 보았습니다. 자동화 전용 인 다른 장소. 이런 종류의 변화를 달성하기 위해, 우리는 그곳에 앉기 위해 싸워야합니다.

자신

일관된 히스토리 컷이 존재해야한다는 의미에서 전이는 분리 된 상태로 유지해야합니다. 어떤 확신을 가지고 그것을 승인하고 빨간색 버튼을 누를 것입니까?

새로운 VCS 구조를 수용하기 위해 코드베이스를 변경해야하며 개발 중에 병합을 유지하기가 매우 어려울 것입니다. (이 문제를 위해 촉진 전략이있을 수 있습니다. 나중에 개발을 약간 병렬화하는 데 도움이 될 수있는 일반적인 전략에 대해 이야기하겠습니다).

글쎄, 유일한 방법은 행동 테스트이며 내기 새로운 코드베이스로 이전을 확인하기 위해 동일한 행동 테스트 스위트를 시작해야합니다. 애플리케이션이 여기에서 예상 한대로 작동하는지 확인하는 것은 아니지만 전환으로 인해 동작이 변경되지는 않습니다. 실패한 테스트를하는 것이 좋습니다. 그들이 계속 실패하면!

실제로 머드 볼을 잘 테스트하는 것은 매우 드문 일입니다. 일반적으로 코드는 매우 밀접하게 결합되어 있으며 대부분의 레거시 코드의 경우 단위 테스트가 아닌 테스트 기반 접근 방식으로 개발되지 않았을 가능성이 큽니다.

그러한 테스트 코드가 누락 된 경우 먼저 작성해야합니다.

전략

그렇습니다. 전환은 격리되어 있어야합니다. 그러나 동시에 통합되었습니다. 나는 여기서 미치게 들릴지 모른다는 것을 알고 있지만, 자신감이 어떻게 비즈니스를 유지할 수 있는지 설명하는 다른 단어를 찾지 못할 것입니다. 기업이 큰 모 놀리 식 코드베이스에 대한 개발을 중단하고이 전환을위한 공간을 만들기를 원치 않는 경우는 거의 없으며, 우리는 단지 동전 던지기 내에서 일어나지 않을 것입니다. 아마도 수백 명의 개발자가 지속적으로 코드베이스에 기여하고있을 것입니다 ( POV에서 변조 단어를 사용합니다 ). 우리의 작업은 자신감을 제공하기 위해 특정 스냅 샷을 해결해야하지만, 영원히 뒤쳐지지 않기 위해 자신을 기반으로 유지해야합니다 (여기서는 의미가 아님).

여기에있는 구현 전략은 다른 경험을 제공 할 수 있습니다. 일반적인 개발 라인은 코어와 상호 작용해야 할 때 새로운 구현 브랜치 (이 경우 다른 리포지토리에 거주)를 랩 / 적응 (선택적으로 재 배열 된 방식으로 엔드 포인트 노출)하는 것입니다. 리팩토링과 함께 이와 같은 전략으로 전환하면 VCS 전환을위한 POC 시나리오를 제공 할 수 있으며 나중에 단계별 접근 방식을 사용할 수 있습니다. 진흙 공을 조각하는 것처럼 그것을보십시오. 네 인생은 훨씬 더 재미있는 것들을 제공합니다.

기술 부채

비즈니스 관리 분야는 기술 부채를 이해하고이를 고려하기 시작했습니다. 아뇨, 긁으세요. 사실이 아닙니다. 정적 코드 분석, 코드 검토, 행동 테스트 결과 및 성능 측면에서 측정 및 품질 데이터를 수집하는 것이 점점 일반화되고 있지만 멋진 보고서 및 모든 것을 생성하는 것은 여전히 ​​매우 어려운 일입니다. 리팩토링 접근법. 그것 의 사업 가치 . "민첩한 프로세스를 따르고 있는데, 기능이 향상되지 않습니까?" . 기본적으로 그렇게함으로써 그들은 기술 부채의 존재를 부정하고 있습니다. 필자는 이것이 모노리스에서 마이크로 서비스 아키텍처로의 전환을 시작할 수있는 일반적인 누락 된 필수 단계라고 생각합니다.

재 집계

이 후에도 둘 이상의 단일 제품을 빌드 할 수있는 단일 저장소와 같은보기를 제공 할 수 있습니다. 어떤 이유로 든, 즉 curr / next release, multibrand, 고객 빌드. 이 경우 Google repo와 같은 도구가 도움이 될 수 있습니다. 한 번도 직접 사용하지는 않았지만 하루가 필요하다는 것을 알고 있습니다.

통합 테스트

마이크로 서비스의 경우 통합 테스트는 "자체 API 테스트"라는 다른 컨텍스트를 가정합니다. 기능 또는 성능이 더 높은 수준의 테스트는 존재할 수 있고 존재할 수 있지만 적절한 통합 테스트 없이는 많은 의미가 있습니까? 단위 테스트없이 통합 테스트를하는 것과 같습니다. 당연히 아니지. 그래서 bisect를 자식으로 사용해야하는 경우 마이크로 서비스 저장소 분기에서 실행하고 mudball 저장소에서 실행하는 것을 잊지 마십시오.

추신. 이것은 초안입니다. 제 영어는 나쁘고 언젠가 고칠 것입니다