Branch 대신에 FeatureFlag..?
Overview
이번 market api는 작업 특성상 프로세스 생명주기를 짧고 빠르게 잡아야 했다. 따라서, branch를 목적에 따라 다양하게 분리하고, 생명주기 역시 길게 잡는 Git-flow 보다는 그 반대의 성향을 가진 Trunk based development 방식이 더 효율이 좋을 듯 하다.
Trunk based development 작업의 특징은 중심 브렌치(main || Trunk) 하나에 모든 작업을 때려넣는 것인데, 좀 더 자세히 알아보면, 무조건 브렌치 하나만 두는 것이 아니다. 필요하면, featuring 브렌치를 만들기도 한다. 다만, 'git-flow'와는 다르게 생성한 브렌치의 유지기간을 매우 짧게 갖는 것이다.
그런데 이번 프로젝트의 경우, 거의 나홀로 진행하기도 하고, MVP로 작업한 다음 조금씩 살을 붙여가는 방식의 개발을 반복할 것이기 때문에 git-flow처럼 상황에 따라 계속 브렌치를 만드는 행위자체가 번거로울 수 있다.
따라서 이번에는 실험적인 시도를 해보고자, Feature Flag를 활용해보고자 한다.
Feature Flag란?
Feature toggles라고도 하는데, 이 방식은 특정 기능의 동작여부를 코드 변경이나 재배포를 하지 않고도 조절할 수 있는 매커니즘을 제공하는게 주 목적이다.
작동 범위는 글로벌, 애플리케이션 인스턴스, request 범위로 분류되는데, 원할한 개발 프로세스를 위해선 이러한 flag를 설정하는 방법을 최대한 쉽고 간단하게 설정할 수 있어야 한다. 또한 잘 쓰면 시스템의 신뢰도와 안정성을 보장할 수 있지만, 제대로 못쓰면, 오히려 개발자들을 힘들게만 하는 애물단지가 될 수 있다.
Feature Flag가 유용하게 활용될 수 있는 경우는 다음과 같다.
- Trunk based Development
- 환경별 다양한 설정 분류
- A/B 테스트
- 카나리 배포
4 가지의 경우에 따라 적용 방식이 상이할 것 같은데, 현재 이슈에 집중하기 위해 Trunk based Development에 적합한 방식 위주로 찾아보겠다.
spring boot로 Feature Flag 사용법
어떤 방법을 사용하든, 더 이상 사용할 일이 없으면, 관련 내용은 삭제하여, 깨끗하게 유지해야 한다.
- Spring Profiles 으로 구분하기
- Custom Properties (프로퍼티 파일, @ConditionalOnProperty 활용)
- @ConfigurationProperties
- api 형태로 프로퍼티 값 드러내기
이외에도 깃헙에서 제공하는 프로젝트 활용 혹은 microsoft azure 에서 제공하는 스프링 부트 라이브러리를 활용하는 방법도 있다. 그런데 외부 라이브러리의 도움을 받아야할 정도로, 기능 요구사항이 복잡하진 않을 듯하니, 스프링 부트의 기본 기능에 의존하도록 하겠다.
참고
- https://www.atlassian.com/continuous-delivery/continuous-integration/trunk-based-development
- https://www.atlassian.com/continuous-delivery/principles/feature-flags
- https://www.baeldung.com/spring-feature-flags
- https://github.com/topics/feature-flags
- https://learn.microsoft.com/ko-kr/azure/azure-app-configuration/use-feature-flags-spring-boot