Patterns for Managing Source Code Branches

[Pyohwan]

https://martinfowler.com/articles/branching-patterns.html

Patterns for Managing Source Code Branches

• Modern source-control 시스템은 소스 코드에서 브랜치를 쉽게 만들 수 있는 강력한 도구를 제공한다.
  • 그러나 결국 이 브랜치들은 머지 되어야 하며, 많은 팀들이 얽힌 덤불(thicket) 을 대처하는데 많은 시간을 소비한다.
  • 팀이 효과적으로 브랜치를 사용할 수 있는 여러가지 패턴이 있고, 여러 개발자의 작업 통합 밑 프로덕션 릴리스로 집중한다.
  • 가장 중요한 주제는 브랜치를 자주 통합하고, 최소한의 노력으로 생산에 배포할 수 있는 건전한 메인라인에 노력을 집중 시키는 것

Base Patterns

• 두가지의 주요 카테고리
  • 통합(integration) : 여러 개발자가 자신의 작업을 일관되게 전체로 결합하는 방법
  • 프로덕션 경로(path to production) : 브랜치를 사용하여 통합된 코드 기반에서, 프로덕션에서 실행되는 제품 관리 경로

    Source Branching

    사본을 작성하고 모든 변경 사항을 기록

• 여러 사람이 동일한 코드 기반에서 작업하는 경우, 당연히 작업할 수 없다.
• 이에 대한 간단한 대답은 각 개발자가 코드 베이스의 사본을 작성하는 것
  • 쉽게 자기 작업을 할수 있지만 또다른 문제 발생 : 작업 완료 후 병합은 어떻게?
• 소스코드제어시스템들 사용하는 방법. 각 브랜치의 변경 사항을 커밋으로 기록 한다는것
  • utils.java 에 대한 변경 사항 기록 및 병합을 쉽게 함
• 브랜치를 정의. head or tip 은 최신 커밋
• 브랜치를 두개로 나누고, 하나의 브랜치가 다른 브랜치로 적용할때에는 머지된다.
• 소스코드 제어 시스템은 특정한 방식으로 "브랜치"를 사용하는 경향이 있다.
• Scarlett 과 Violet 은 각자 git repo 를 복제해서 작업하고 커밋은 서로 독립적이지만, 언젠간 변경 사항을 공유 repo 에 push 하고 머지해야 한다.
• codeline 이란? 특정 버전의 코드 베이스로 정의. Git, Github, Mercurial, Subversion 포함한 용어

  When to use it

• 커밋에 대한 모든 변경 사항을 기록하는 소스 제어 시스템을 사용하면, 머지 과정이 쉬워지지만 사소한건 아니다.
  • Scarlett과 Violet 변수 이름을 변경하면, 사람 개입 없이는 해결이 안되는 충돌이 있다.
• textual conflict 과 Semantic Conflict 설명 함. (생략)

  Mainline

  제품의 현재 상태로 작동하는 단일, 공유, 브랜치

• 메인라인은 팀 코드의 현재 상태로 간주하는 특수 코드 라인.
  • 새로운 작업을 시작할때마다 메인라인에서 로컬 repo 로 코드를 가져와서 작업 함
  • git 에선 "master" 로, subversion 에선 "trunk"
• 메인 라인은 하나의 공유된 코드 라인인것이 중요.
  • git 에서 origin repo 가 있고 해당 master 가 mainline 이다.

    When to use it

• 2000년대 초에는 빌드 엔지니어가 있었고, 모든 팀 구성원에 이메일을 보애고, 다양한 파일을 받아서, 통합 트리에 복사하고, 코드 베이스를 컴파일했다. 테스트 가능한 빌드 만다는데 보통 몇주 걸렸음

  Healthy Branch

  각 커밋마다 브랜치 결함이 없는지 확인하기 위해 테스트 빌드 와 같은 자동 검사 수행

• Mainline 은 승인된 공유 상태이기 때문에, 안정적인 상태를 유지하는것이 중요
  • 포괄적인 자동화된 테스트가 필요하다.

    When to use it

• 생략

  Integration Patterns

  Mainline

  개발자는 메인라인에서 pulling 하고 병합 - 만약 healthy 하면 메인라인으로 pushing

• 메인라인의 가장 큰 장점은 통합을 단순화 함.
• Scarlett 은 메인라인에서 자신의 repo 로 clone 애서 작업 함.
  • 그 사이에 Violet 이 메인라인에 몇가지 changes 를 적용 함. Scarlett 은 이런 변경점을 모름
• 이제 통합을 하려 하는데, 첫번째로는 메인라인을 로컬 마스터 브랜치로 가져 옴. 그러면 Violet 의 변경 사항이 적용 됨.
• Violet 의 변경사항을 머지하고 메인라인으로 푸쉬. textual 충돌은 소스 컨트롤 시스템에서 자동으로 잡아주지만, semantic 충돌은 어렵다.

  Feature Branching

  기능에 대한 모든 작업을 자체 브랜치로 두고, 기능이 완료되면 메안라인으로 통합해라.

• Scarlett repo 의 master 에서 feature 브랜치를 만들어서 하라

  Integration Frequency

• Dev Ops Report 의 연구에 따르면 엘리트 개발 팀은 저 성과자 보다 더 자주 통합 하더라.

  Low-Frequency Integration

• 메인라인에 병합을 빨리 안하니, Violet 은 큰 덩어리를 병합해야 하는데 모이면 힘들다.

  High-Frequency Integration

• 메인라인 병합을 자주 하니, 병합에 대한 부담이 적다.

  Comparing integration frequencies

• Low-Frequency Integration 는 High-Frequency Integration 보다 두배나 더 많은 통합 고통
  • 더 중요한것은 위험도 함께 작아진다.
• Scarlett과 Violet 이 충돌을 언제 감지할까? Violet 은 최종 병합까지 충돌 발생할지 감지하지 못한다. 반면에 High-Frequency Integration 에서는 첫번째 병합에서 감지 됨
• Self Testing Code 강조

  Continuous Integration

  개발자는 일반적으로 하루 미만의 작업으로 공유할 수 있는 건강한 커밋을 즉시 메인 라인 통합을 한다.

• 한 팀이 high-frequency integration 이 더 효율적으로 스트레스를 덜 받는다고 경험하게 되면, 이제는 "우리가 얼마나 자주 갈 수 있을까?" 이다.
• 당신은 당신의 로컬 repo 를 통합하지 않은 채 하루 이상 일을 해서는 안된다.
  • 실제로, 대부분의 지속적인 통합 실무자들은 하루에도 여러번 통합하고, 한시간 정도의 업무량을 통합하는데 만족 한다.

    Comparing Feature Branching and Continuous Integration

• 피쳐 브랜칭은 현재 업계에서 보편적인 브랜치 전략으로 보이지만, 지속적 통합이 보통 우월한 접근법이라고 말하는 실무자가 많다.
  • 지속적 통합의 주요 장점은 훨씬 더 높은 통합 빈도를 지원한다는 것이다.
• 통합의 빈도가 높아지면, 통합 참여가 줄어들고, 통합에 대한 두려움이 줄어든다.
• 지속적 통합은 high-frequency integration 이점을 얻을 수 있고, feature 길이를 통합 빈도에서 분리 시킬 수 있다.
• 지속적 통합의 단점. 피쳐를 on / off 할 수 있어야 하는데, 쉽지가 않다.
  • 또한, 건강한 브랜치 유지를 위해서는 강력한 테스트 방법을 개발 해야 함
• 병합의 크기와 불확실성이 Feature Branching 의 문제점. 가장 큰 문제는 리팩터링을 억제(약화) 한다.
  • 리팩토링은 높은 통합 빈도에서 가장 잘 동작한다.

Feature Branching and Open Source

• 오픈소스쪽에서는 메인티너(maintainer) 가 있고, 컨트리뷰트에 코드 질 을 검수한다.
  • 컨트리뷰트가 언제 작업할 지 모른다.
• 크든 작든 해당 기능이 언제 끝날지 모르는 Feature Branching 에서는 통합하기 전까지 기다려 줄 수 있다.
  • 코드 리뷰, 품질 을 통과하는것이 더 중요하다.
• 하지만, 상업 소프트웨어 팀은 매우 다른 작업 환경이다.
  • 상근 개발팀이 있고, 코드 품질과 딜리버리 능력에 대한 신뢰가 있다.
  • 이들은 유급 직원이기 때문에, 리더들은 프로젝트 투입 시간, 코딩 표준, 집단 습관 등을 통제 가능하다
• 따라서 오픈소스와 상업소프트웨어 팀은 브랜치 전략이 같을 필요 없다.
  • 지속적인 통합은 오픈소스 쪽에서는 불가능에 가깝지만, 상업소프트웨어 쪽은 현실적인 대안

Reviewed Commits

메인라인에 대한 모든 커밋이 수락되기 전에 동료가 검토한다

• 코드 리뷰는 코드 품질을 향상 시키고, 모듈화, 가독성을 향상 시키며, 결함을 제거하므로 오랫동안 장려 해왔다.
• 상용 조직에서는 개발 워크플로우를 맞추기가 어렵다는 것을 알게 됨
• 오픈소스 세계에서는 널리 사용됨
• Reviewed Commits 은 오픈 소스에서 인기를 끌었고, 헌신적인 메인티너와 컨트리뷰터가 있는 조직 모델과 잘 어울린다.
• Reviewed Commits 의 약속을 위한 규율을 정하는것이 중요
• 어떤 개발자가 어떤 일을 마치고 다른 일을 한다면? 검토 확정까지 추가 적인 개발이 어렵다.
• Reviewed Commits 와 Continuous Integration 은 함께 할 수 있긴 한데, Reviewed Commits and Feature Branching 이 일반적인 조합이다.

  When to use it

• 지난 10년 동안 Reviewed Commits 은 관행이 되었지만, 단점과 대안이 있다.
• Reviewed Commits 을 잘 수행해도, 통합 프로세스에 항상 약간의 대기시간 발생하여 통합 빈도가 낮아진다.
• Pair Programming 은 코드 리뷰보다 빠른 피드백 가능
• Reviewed Commits 을 사용하는 팀은 빠르게 커밋하지 않는다.
• 귀중한 피드백은 너무 늦어서 유용하지 않다.
• reviewed commits 은 귀중한 관행이 될 수 있지만, 리더에 지나치게 의존하지 않는 균형 잡힌 팀을 키우려는 경우, 건강한 코드 기반으로의 필수 경로는 아니다.

Integration Friction

• Reviewed Commits 의 문제점 중 하나는 통합하기가 번거롭다는 것
• Manual 프로세스는 특히 일반적인 마찰 원인
  • 개발자 교육, Deployment 파이프라인 or QA 환경으로 이러한 종류의 마찰을 줄일 수 있음
• 사람들이 지속적인 통합을 꺼려하는 것 중 하나는, 높은 수준의 통합 마찰이 있는 환경에서만 일한 경우
  • 통합하는데 한시간이 걸리고 하루에 여러번 하면? 통합 이벤트가 끝나면 몇분 안되어서 다른 세상으로 된다.
• 문화적 요소는 통합 마찰, 구성원간 신뢰에 영향을 줌
  • 리더가 동료를 못 믿고 있다면, 코드베이스 손상하는 커밋 방지하고 싶음
  • 반면에 신뢰하는 동료라면, 리뷰를 없앨 수 있고, 리팩토링을 사용하여 해결할 수 있다.

The Importance of Modularity

• Modularity 이 안좋은 곳은 작은 변경사항도 코드베이스의 많은 부분을 통해 파급 된다.
• Modularity 은 통합에도 영향을 주는데, 잘 분리된 환경이면 애초에 변경 사항 충돌이 안남

Personal Thoughts on Integration Patterns

• (마틴 파울러가 선호하는것) Continuous Integration

The path from mainline to production release

• 메인라인은 정기적으로 새로운 코드와 수정된 코드를 가진 활성 브랜치다.
  • 새로운 일을 시작할 때 안정적인 기반을 시작하려면 건강을 유지하는것이 중요
  • 건강하다면 메인라인에서 프로덕션으로 코드를 직접 배포 가능
• 메인 라인을 항상 릴리스 가능한 상태로 유지한다는 이 철학은 Continuous Delivery 의 핵심 원칙
  • 태그를 사용하여 릴리스 추적 가능

    Release Branch

    릴리스 준비된 제품 버전을 안정화 하기 위해 커밋만 수락하는 지점

• 일반적으로 릴리스 브랜치는 현재 메인라인에서 복사하지만 새 기능을 추가할 수는 없다.
  • 메인 개발팀은 기능을 메인라인에 추가하고, 릴리스에서 작업하는 개발자는 프로덕션 준비 상태가 되지 않도록 결함을 제거하는 데만 초점을 맞춥니다.
  • 이러한 결함을 고친 수정 사항은 릴리스 브랜치에 적용되고 메인라인에 병합된다.
• 릴리스 브랜치의 픽스 작업 범위는 갈수록 많아지고 병합하기 어려워 짐

  When to use it

• 릴리스 브랜치는 메인라인을 건강한 상태로 유지할 수 없을때 유용하다.
  • 팀의 일부는 프로덕션 준비에 필요한 버그 수정에 집중할 수 있다
• 최고의 팀에서는 릴리스 브랜치가 필요 없고, single-production 제품에는 이 패턴을 사용하지 않는다.
  • 메인라인이 충분히 건강하다면, 메인라인에 바로 커밋 그리고 릴리스가 가능
  • 릴리스는 공개적으로 볼 수 있는 버전 및 빌드 번호를 태그로 지정

Maturity Branch

코드기반 성숙도의 버전을 표시

• "production branch", "staging branch", and "QA branch" 과 같은 분기

Environment Branch

소스 코드 커밋을 적용한 새 환경에서 실행되는 제품 구성

• 소프트웨어는 일반적으로 워크스테이션, 프로덕션 서버 등 다양한 테스트 및 스테이징 환경에서 실행해야 한다.
• 메인라인에서 새분기를 만들고, 적절한 환경 변경 사항을 적용하고, 제품을 재구성해서, 스테이징 환경에 배치한다.
• 변경 사항은 일반적으로 수작업으로 적용

  When to use it

• 새로운 환경에 대비할 수 있는 좋은 방법이지만, 매우 고전적인 안티 패턴이다.
• 모든 환경에서 실행되는 동일한 실행 파일이 필요하며, 환경 파일은 분리시켜야 한다.

Hotfix Branch

긴급한 프로덕션 결함을 해결하기 위한 작업을 캡쳐 지점

• 프로덕션에 심각한 버그가 나타나면 가능한 빨리 수정해야 한다.
• 수정이 적용된 프로덕션의 핫픽스는 메인라인에 적용되고, 다음 버전에서 회귀가 발생하지 않도록 해야 한다.

Release Train

정기 일정으로 출발하는 열차처럼 정해진 시간 간격으로 출발

• 2주 마다 또는 6개우러 마다 정기적으로 릴리스를 설정
• 기능이 완료될 시기를 예측하는데 도움
• 단점은, 중요 기능이 몇주 또는 몇 달 동안 누락 되어 있음
• 릴리스 트레인을 사용하다가, 팀이 점점 나아지면 결국 continuous delivery 로 갈 수 있다.

Release-Ready Mainline

메인라인 헤드를 항상 프로덕션에 넣을 수 있도록, 메인라인을 건강하게 유지

• 메인라인이 건강하면 언제든지 메인라인을 릴리스해서 태그로 릴리스 기록 가능하다

When to use it

• release-ready 메인라인이 최상의 선택

Final Thoughts and Recommendations

• 브랜치의 첫번째 팁 : 브랜치 사용할 때 어떻게 병합할지 알아 낼 것
• 다음 지침 : Bodart's Law 를 기억하라. 모듈성으로 문제 해결 가능한가? 배포 파이프라인 개선 가능한가? 태그가 충분한가? 브랜치의 필요성을 없애는것이 일반적으로 좋은 일
• LeRoy 의 illustration 을 기억하라 : 브랜치를 통합하지 않고 실핼하면, 급수족으로 브랜치 된다. 따라서 얼마나 자주 통합하는지 고려 하라. 통합 빈도를 두배로 높혀라.
• 병합은 브랜치의 어려운 부분이며, 병합을 어렵게 만든다.