feature toggle

트렁크 기반 개발

• 단일 브랜치에서 개발자 협업
• main 브랜치에 코드가 머지되면, CI 시스템이 테스트/통합 과정 확인
• main 브랜치 코드가 즉시 운영에 반영된다.

빈번한 머지와 배치로, 배치당 수정되는 코드가 적어진다.
PR당 확인해야하는 코드가 적어져 리뷰가 쉬워지고,
배치당 해결해야하는 conflict 가 줄어들면서,
오류를 줄일수 있다.

Feature Toggle

트렁크 기반 개발은 작은 단위 코드라인 변경을 지향하기 때문에,
규모가 큰 기능을 개발할 경우, 미완료 코드를 main에 반영할수 있다.
이때 Feature toggle 을 사용하여, 미완료된 코드가 실행되지 않도록 설정할수 있다.
또는 특정 사용자에게만 새로운 기능을 오픈하여 미리 테스트를 진행하기도 한다.

적용 방법 & 나의 생각

처음 feature toggle 개념에 대해 알게 되었을 때, trunk based development 에 대한 이해가 깊지 못했고, 테스트까지 완료된 기능만 머지하는 상황이었기 때문에 feature toggle의 필요성을 깊게 느끼지 못했다. 오히려 언젠가는 없애야하는 코드를 생성하는 것에 거부감이 먼저 들기도 했다.

하지만 트렁크 기반 개발에 대해 알아보니, 빈번한 머지와 배포로 미완료된 코드라도 운영에 반영 해야하는 상황이 올수 있음을 이해할수 있었다.

trunk based development

현재 개발중인 어플의 경우, 프론트의 배포는 production 브랜치를 만들고, ios 심사를 거치다 보니 배포가 빠를수 없는 환경이다.

trunk 개발에 관한 글중에 "main 코드가 즉시 운영에 반영된다." 라는 말이 있었다. 이말에서, trunk based development 로 가기 위해서는 andriod, ios 배포 자동화가 구축되어, 자동으로 심사가 이뤄지는 흐름을 만들어야 한다는 생각이 들었다. (fastlane 같은 라이브러리를 사용하는걸로 보인다.)

현재 feature toggle 의 역할

배포 자동화까지 이뤄진다면 feature toggle 의 필요성이 증가하고, 빠른 배포가 이뤄질것이다. 현재는 배포 자동화가 구축되어 있지 않지만, 백엔드의 개발/운영 환경이 분리되지 않은 문제를 해결하는 역할로써 feature toggle 을 사용할수 있어 보인다.

기능 변경이나, 신규 개발의 경우, 백엔드에서 main으로의 머지는 운영 배포를 의미한다. 때문에 api 구조가 변경되어 운영환경에 오류가 생기게 된다. feature toggle이 기능 반영 시점을 조절하면서 문제를 해결할수 있다.

더 빠른 배포환경이 필요할 경우, android/ios 배포 자동화를 구축하여 feature toggle을 다양한 방식으로 사용해봐야겠다.

출처: https://tech.mfort.co.kr/blog/2022-08-05-trunk-based-development/