Pipeline Auto merge 빌드 추가하기 (git flow)
서론
안녕하세요, 마이다스인에서 인재 채용 플랫폼 잡다의 웹 프론트엔드 개발을 담당하고 있는 남준영입니다. ATS 프로젝트 팀에 합류한 후, 저희는 실제 작업 환경에서 git flow 정책을 적용하며 여러 경험을 쌓아왔습니다. 이 글에서는 git flow의 개념부터, 저희 프로젝트에서의 적용 사례, 그리고 최근에 추가한 Bitbucket Pipeline 자동 병합(Auto merge) 단계에 대해 자세히 설명해보려 합니다. 특히, 개발 프로세스의 자동화에 관심이 많으신 분들에게 이 내용이 도움이 될 것으로 기대합니다.
git flow란?
Git Flow는 소프트웨어 개발 프로젝트에서 사용되는 Git 버전 관리 시스템의 한 분기 관리 전략입니다. 이 전략은 Vincent Driessen에 의해 2010년에 처음 소개되었으며, 효율적인 소프트웨어 개발과 유지보수를 위해 설계되었습니다. Git Flow는 기능 개발, 버그 수정, 릴리스 준비 및 유지 보수 작업을 체계적으로 관리할 수 있게 해줍니다.
Git Flow에서 사용되는 주요 브랜치들은 다음과 같습니다:
- Develop 브랜치: 이 브랜치는 개발을 위한 기본 브랜치로, 모든 기능 개발 브랜치의 기반이 됩니다. 개발 팀원들은 새로운 기능을 개발할 때마다 이 브랜치로부터 분기를 생성합니다.
- Feature 브랜치: 새로운 기능이나 개선사항을 개발하는 데 사용됩니다. 개발이 완료되면 이 브랜치는 Develop 브랜치로 병합되어 다른 개발자들과 공유됩니다.
- Release 브랜치: 소프트웨어 릴리스를 준비하는 데 사용됩니다. 이 브랜치는 Develop 브랜치로부터 분기되며, 릴리스 전 마지막 버그 수정, 문서 작업, 그리고 기타 릴리스 준비 작업을 포함합니다. 준비가 완료되면, Release 브랜치는 Master(또는 Production) 브랜치와 Develop 브랜치 양쪽으로 병합됩니다.
- Hotfix 브랜치: 이미 릴리스된 소프트웨어에서 발견된 긴급한 버그를 수정하기 위해 사용됩니다. 이 브랜치는 Master(또는 Production) 브랜치로부터 분기되며, 문제가 해결되면 다시 Master(또는 Production) 브랜치와 Develop 브랜치 양쪽으로 병합됩니다.
- Master(또는 Production) 브랜치: 소프트웨어의 현재 릴리스 버전을 나타냅니다. 사용자에게 배포된 안정적인 코드의 스냅샷을 유지합니다.
Git Flow의 장점은 명확한 분기 관리 정책을 통해 소프트웨어 개발 과정의 복잡성을 줄이고, 팀 내에서의 협업을 용이하게 한다는 점입니다. 개발자들은 각각의 기능, 릴리스, 긴급 수정 작업을 독립적으로 진행할 수 있으며, 이를 통해 전체 프로젝트의 진행 상황을 보다 쉽게 관리하고 통제할 수 있습니다. 그러나 Git Flow를 효과적으로 사용하기 위해서는 전략의 규칙을 철저히 이해하고, 팀 내에서 일관되게 적용하는 것이 중요합니다.
프로젝트에서 사용하고 있는 git flow
환경
ATS는 dv, st, st2, pr 등의 환경을 구분하여 사용하고 있습니다. 이러한 환경 구분을 통해, 개발부터 스테이징, 프로덕션까지의 배포 과정을 명확하게 관리할 수 있습니다.
branch 관리
- develop: 개발을 위한 기본 브랜치로, 모든 기능 개발 브랜치는 여기서 분기됩니다.
- release: 스프린트 단위로 릴리스를 준비하는 브랜치로, 예를 들어 release/v3.1.0과 같은 형식을 사용합니다.
- hotfix: 릴리스된 버전에서 버그 수정이나 긴급한 개선이 필요할 때 사용합니다.
- production: 프로덕션 환경으로 배포되는 최종 버전을 관리합니다.
배포 프로세스
개발이 develop 브랜치에서 진행된 후, release로 이동하여 st, st2 환경에서 검증을 거칩니다. 이후 production으로 배포되며, 배포가 완료되면 release 브랜치의 내용을 production에 병합하고, 다시 production의 내용을 develop에 병합하여 개발 브랜치도 최신 상태로 유지합니다.
Bitbucket Pipeline 자동 병합(Auto merge) 추가 작업
이러한 배포 후 병합 과정을 자동화하기 위해, 저희는 Bitbucket Pipeline에 Auto merge 단계를 추가하였습니다. 이 작업을 통해, 배포 과정에서의 수동 병합 작업을 줄이고, 오류 가능성을 낮추며, 개발 팀의 작업 효율을 크게 향상시킬 수 있었습니다.
구현 방법
Pipeline의 구성은 다음과 같습니다:
- AutoMerge 스텝 정의: AutoMerge라는 이름으로 새로운 스텝을 정의하고, Bitbucket의 기본 이미지를 사용하여 필요한 git 명령어를 실행합니다
스크립트 작성
이 스텝에서는 다음과 같은 작업을 수행합니다
- 먼저, 배포될 브랜치의 버전 번호를 환경 변수에서 추출합니다.
- git 설정을 통해 모든 브랜치를 가져올 수 있도록 합니다.
- production 브랜치로 체크아웃하고, 현재 브랜치(release 또는 다른 브랜치)를 production에 병합합니다. 병합 시 메시지는 "Merge branch '현재 브랜치 이름' into production"으로 설정합니다.
- 병합한 production 브랜치를 원격 저장소에 푸시합니다.
- 이어서 develop 브랜치로 체크아웃하고, production 브랜치의 최신 내용을 develop에 병합합니다. 이 때의 메시지는 "Merge branch 'production' into develop"으로 설정합니다.
- 마지막으로, 변경된 develop 브랜치를 원격 저장소에 푸시합니다.
- step: &AutoMerge
name: Auto Merge to Production
image: atlassian/default-image:3
script:
- export VERSION_NUMBER="${BITBUCKET_BRANCH:8}"
- echo $VERSION_NUMBER
- git config remote.origin.fetch "+refs/heads/*:refs/remotes/origin/*"
- git fetch
# 현재 브랜치를 production에 병합
- git checkout -t origin/production
- git merge $BITBUCKET_BRANCH -m "Merge branch '$BITBUCKET_BRANCH' into production"
- git push origin production
# production을 develop에 병합
- git checkout -t origin/develop
- git merge production -m "Merge branch 'production' into develop"
- git push origin develop
- Pipelines 구성에 스텝 추가
기존의 pipelines 구성에 AutoMerge 스텝을 추가하여, 프로덕션 환경으로의 배포가 성공적으로 완료된 후 자동으로 병합 작업이 이루어지도록 설정합니다.
pipelines:
custom:
... dv st st2..
...
production:
- step:
<<: *production-env
- step:
<<: *build-push
deployment: Production-ENV
- step:
<<: *deploy
deployment: Production-ECS
- step:
<<: *AutoMerge // 추가된 부분
이와 같이 Bitbucket Pipeline에 자동 병합(Auto merge) 단계를 추가함으로써, 배포 프로세스가 더욱 원활하고 자동화되었습니다. 이는 배포 후 병합 작업에 소요되는 시간과 노력을 대폭 줄여주며, 팀이 더 중요한 작업에 집중할 수 있게 해줍니다. 또한, 인간의 실수로 인한 병합 오류를 방지하고, 프로젝트의 브랜치들을 항상 최신 상태로 유지할 수 있게 됩니다.
결론
git flow는 복잡한 개발 프로세스와 다양한 배포 환경을 체계적으로 관리할 수 있게 해주는 강력한 도구입니다. Bitbucket Pipeline의 자동 병합 기능을 통해 이러한 프로세스의 효율성을 더욱 향상시킬 수 있었습니다. 이러한 자동화 작업은 팀의 생산성 향상뿐만 아니라, 프로젝트 관리의 질을 높이는 데에도 중요한 역할을 합니다. git flow 및 자동화 배포 프로세스의 적용을 고려하고 계신다면 이러한 접근 방법을 시도해 보시길 추천합니다.
'Web' 카테고리의 다른 글
모바일 iframe Pinch-zoom에 대한 심층 분석과 해결 방안 (0) | 2024.03.25 |
---|---|
SSE(Server-Sent-Event) 서비스에 적용하기 (0) | 2023.12.01 |
Android target33으로 변경 및 Push Notification 권한 추가 (1) | 2023.12.01 |
쿠키 vs 세션 vs 캐시. 무엇이 다를까? (0) | 2021.07.15 |
HTML,CSS,JS : 정적인 Youtube mobile로 반응형 웹사이트 clone coding (0) | 2020.08.17 |