[12월] TBD(Trunk-Based Development) & Feature Flag

이번 과제가 TBD와 Feature Flag에 대해 알아보는 것이었는데,
나는 해당 용어들에 대해 처음 들어봐서 아는 것이 없으므로 대표 아티클들을 읽고 정리할 예정.

---

TBD(Trunk-Based Development) 란?

TBD(Trunk-Based Development)는 개발자가 핵심 "트렁크" 또는 기본 분기에 대한 작고 빈번한 업데이트를 병합하는 버전 제어 관리 방식이다.
이는 병합 및 통합 단계를 간소화하기 때문에 DevOps 팀과 DevOps 수명 주기의 일부 사이에서 일반적인 방식이다.
실제로 TBD(Trunk-Based Development)는 CI/CD의 필수 사례이다. 
개발자는 수명이 긴 다른 기능 분기 전략에 비해 약간의 작은 커밋으로 수명이 짧은 분기를 만들 수 있다. 
코드 베이스 복잡성과 팀 규모가 커짐에 따라 TBD(Trunk-Based Development)는 프로덕션 릴리스 흐름을 유지하는 데 도움이 된다.

---

Gitflow 란?

Gitflow는 수명이 긴 기능 분기와 여러 기본 분기를 사용하는 대체 Git 분기 모델이다.
Gitflow는 TBD(Trunk-Based Development) 보다 더 오래 지속되는 브랜치와 더 큰 커밋을 가지고 있다.
이 모델에서 개발자는 기능 분기를 만들고 기능이 완료될 때까지 기본 트렁크 분기에 병합하는 것을 연기한다.
수명이 긴 이러한 기능 브랜치는 트렁크 브랜치에서 이탈하고 충돌하는 업데이트를 도입할 위험이 높기 때문에 병합하려면 더 많은 협업이 필요하다.

---

Gitflow VS TBD(Trunk-Based Development)

소프트웨어 개발 초기에 프로그래머는 최신 버전 제어 시스템을 사용할 수 없었다. 
오히려 그들은 변경 사항을 추적하고 필요한 경우 되돌릴 수 있는 수단으로 두 가지 버전의 소프트웨어를 동시에 개발했다.
하지만, 시간이 지남에 따라 이 프로세스는 노동 집약적이고 비용이 많이 들고 비효율적인 것으로 판명되었다.

버전 제어 시스템이 성숙해지면서 다양한 개발 스타일이 등장하여 프로그래머가 버그를 더 쉽게 찾고, 동료와 함께 코딩하고, 릴리스 흐름을 가속화할 수 있게 되었다. 
오늘날 대부분의 프로그래머는 Gitflow 및 TBD(Trunk-Based Development)이라는 두 가지 개발 모델 중 하나를 활용하여 고품질 소프트웨어를 제공한다다. 

가장 먼저 대중화된 Gitflow는 특정 개인만이 메인 코드에 대한 변경을 승인할 수 있는 더 엄격한 개발 모델입니다. 
이것은 코드 품질을 유지하고 버그 수를 최소화한다. 
TBD(Trunk-Based Development)는 모든 개발자가 기본 코드에 액세스 할 수 있으므로 보다 개방적인 모델이다. 
이를 통해 팀은 빠르게 반복하고  CI/CD를 구현할 수 있다.

Gitflow에는 개발, 핫픽스, 기능 및 릴리스를 위한 별도의 기본 분기 라인도 있다. 
이러한 브랜치 간에 커밋을 병합하기 위한 다양한 전략이 있다. 
저글링하고 관리해야 할 지점이 더 많기 때문에 종종 추가 계획 세션과 팀의 검토가 필요한 더 복잡한 경우가 있다.

TBD(Trunk-Based Development)는 수정 및 릴리스 소스로 기본 분기에 초점을 맞추기 때문에 훨씬 더 간단하다. 
TBD(Trunk-Based Development)에서 주 브랜치는 항상 안정적이고 문제없이 배포할 준비가 되어 있다고 가정한다.

---

Benefits of TBD(Trunk-Based Development)

TBD(Trunk-Based Development)는 지속적인 통합을 위한 필수 사례이다. 
빌드 및 테스트 프로세스가 자동화되었지만 개발자가 공유 브랜치에 드물게 통합되는 고립되고 긴 기능 브랜치에서 작업하는 경우 지속적인 통합은 그 잠재력을 발휘하지 못한다.

• Allows continuous code integration (지속적인 코드 통합 가능)
  • 트렁크 기반 개발 모델에는 메인 브랜치로 유입되는 커밋 스트림이 꾸준히 있는 리포지토리가 있어,
    지속적인 통합이 가능하며, 새 코드가 트렁크에 병합되면 자동화된 통합 및 코드 적용 범위 테스트가 실행되어 코드 품질을 검증한다.
    
• Ensures continuous code review (지속적인 코드 검토 보장)
  • 트렁크 기반 개발의 빠르고 작은 커밋은 코드 검토를 보다 효율적인 프로세스로 만든다.
    소규모 분기를 통해 개발자는 작은 변경 사항을 빠르게 확인하고 검토할 수 있다.
    
• Enables consecutive production code releases (연속 프로덕션 코드 릴리스 가능)
  • 자동화된 테스트, 코드 수렴 및 코드 검토는 언제든지 프로덕션에 배포할 준비가 된 트렁크 기반 개발 프로젝트를 제공한다.
• Trunk-based development and CI/CD
  • 지속적인 통합을 통해 개발자는 트렁크에 대한 각 위원회 후에 실행되는 자동화된 테스트와 함께 트렁크 기반 개발을 수행한다. 이렇게 하면 프로젝트가 항상 작동.

---

TBD(Trunk-Based Development) best practices

 

• Develop in small batches (작은 배치로 개발)
  • 트렁크 기반 개발은 빠른 리듬을 따라 코드를 프로덕션에 전달
• Feature flags (기능 플래그)
  • 기능 플래그는 개발자가 비활성 코드 경로의 새로운 변경 사항을 래핑하고 나중에 활성화할 수 있도록 하여 트렁크 기반 개발을 훌륭하게 보완한다.
• Implement comprehensive automated testing (포괄적인 자동화 테스트 구현)
  • 짧은 실행 단위 및 통합 테스트는 개발 중 및 코드 병합 시 실행된다. 
    장기 실행, 전체 스택, 종단 간 테스트는 전체 준비 또는 프로덕션 환경에 대해 이후 파이프라인 단계에서 실행된다.
• Perform asynchronous code reviews (비동기 코드 검토 수행)
  • 트렁크 기반 개발에서는 코드 검토를 즉시 수행해야 하며 나중에 검토하기 위해 비동기식 시스템에 넣지 않아야 한다. 자동화된 테스트는 사전 코드 검토 계층을 제공한다.
    
• Have three or fewer active branches in the application's code repository
  (애플리케이션의 코드 저장소에 3개 이하의 활성 분기 보유)
  • 브랜치가 병합되면 삭제하는 것이 가장 좋다. 
    많은 양의 활성 분기가 있는 리포지토리에는 불행한 부작용이 있다.
• Merge branches to the trunk at least once a day (적어도 하루에 한 번 branch를 trunk에 병합)
  • 고성능 트렁크 기반 개발 팀은 적어도 매일 열려 있고 병합 준비가 된 분기를 닫고 병합해야 한다. 
    이 운동은 릴리스 추적을 위한 리듬을 유지하고 설정하는 데 도움이 된다.
• Reduced number of code freezes and intergration phases (코드 동결 및 통합 단계 감소)
  • 애자일 CI/CD 팀은 통합 단계를 위해 계획된 코드 동결 또는 일시 중지가 필요하지 않아야 한다.
    단, 조직에서는 다른 이유로 필요할 수 있다.  CI/CD의 "지속적"은 업데이트가 지속적으로 진행되고 있음을 의미.
    트렁크 기반 개발 팀은 코드 동결 차단을 피하고 릴리스 파이프라인이 중단되지 않도록 적절히 계획해야 한다.
• Build fast and execute immediately (빠르게 빌드하고 즉시 실행)
  • 빠른 릴리스 리듬을 유지하려면 빌드 및 테스트 실행 시간을 최적화해야 한다.

---

Feature flags (기능 플래그) 란?

 

기능 플래그(일반적으로 기능 토글이라고도 함)는 새 코드를 배포하지 않고 런타임 중에 선택 기능을 켜고 끄는 소프트웨어 엔지니어링 기술이다. 
이를 통해 팀은 추가 코드를 강요하지 않고 변경할 수 있으며 기능의 수명 주기 동안 보다 통제된 실험을 수행할 수 있다. 
이 때문에 기능 플래그는 민첩한 관리 스타일과 CI/CD 환경에 매우 유용한 많은 새로운 워크플로우를 가능하게 한다.

---

Benefits of  Feature flags

기본 수준에서 기능 플래그를 사용하면 코드를 커밋하고 휴면 상태에서 프로덕션에 배포한 다음 나중에 활성화할 수 있다. 
이를 통해 팀은 최종 제품의 사용자 경험을 더 잘 제어할 수 있다.  개발팀은 새 코드가 전달되는 시기와 사용자를 선택할 수 있다.

• Validate feature functionality (기능 확인)
  • 기능 플래그는 기본적으로 "꺼짐"으로 설정될 수 있으므로 일단 코드가 배포되면 생산 중에 유휴 상태로 유지되고 기능 토글이 명시적으로 활성화될 때까지 새 기능이 비활성화된다. 
    그런 다음 팀은 코드를 활성화하는 기능 플래그를 켤 시기를 선택하여 팀이 QA를 수행하고 예상대로 작동하는지 확인할 수 있다. 
    팀이 이 프로세스 중에 문제를 발견하면 즉시 기능 플래그를 해제하여 새 코드를 비활성화하고 문제에 대한 사용자 노출을 최소화할 수 있다.
• Minimize risk (위험 최소화)
  • 예를 들어 애플리케이션에서 트래픽이 급증하고 모니터링 시스템에서 문제가 증가했다고 보고하는 경우 팀은 기능 플래그를 사용하여 성능이 좋지 않은 기능을 비활성화할 수 있다.
• Modify system behavior without disruptive changes (방해가 되는 변경 없이 시스템 동작 수정)
  • 기능 플래그를 사용하여 복잡한 코드 통합 및 배포 시나리오를 최소화할 수 있다.
    

---

 

나는 워크 플로우 방식이라는 용어 자체를 제대로 인지하지 못하고 있었다,
Gitflow란 단어를 들어보긴 했지만 이번에 개념들을 알았으며 내가 이제껏 사용했던 방식이 Gitflow였음! 뜻밖의 수확!

TBD 워크플로우를 적용시키려면 애자일과 monorepo로 프로젝트를 관리해야 할 것 같은데, 
branch의 수명주기가 짧아야 한다는 것은 머릿속으로는 매우 이상적이고, 그렇게 된다면 좋을 것 같지만 막상 코드 리뷰와 버그들을 마주할 수밖에 없고, 그 속에서 안정적이면서 빠른 릴리즈 흐름을 가져간다는 게 생각만큼 쉬울 것 같지 않다.

최근 팀플을 해보면서 느낀 것은 branch를 장기적으로 갖고 있으면, 그만큼 좀 다운되는? 쳐지는 부분은 없지 않아 있는 것 같다. 근데 다시 생각해보니  branch가 아니라, 프린트 이후의 전반적인 일정이 문제가 아닌가 싶다.
프로젝트가 장기적으로 들어가면서 팀원들 각각 일정이 있어서 시간 맞추기가 어렵고,
여러 사건들이 있어서 모든 것들이 점점 딜레이 되고 있다.. 팀플은 정말 어려운 작업이다.

아무튼 애자일을 토대로 빠르지만 체계적이고 안정적인 시스템을 갖춘 후, TBD 방식을 이용하는 것이 베스트 일 것 같다는 생각을 해보았다.

---

[출처 : https://www.atlassian.com/continuous-delivery/continuous-integration/trunk-based-development ]
[출처 : https://www.atlassian.com/continuous-delivery/principles/feature-flags ]
[출처 : https://trunkbaseddevelopment.com/ ]
[출처 : https://trunkbaseddevelopment.com/feature-flags/ ]
[출처 : https://www.youtube.com/watch?v=CsbBuE_MF2U ]