팀에서 Atlassian의 Jira와 Confluence를 협업Tool로써 사용하게되면서 이와 연계하여 Bitbucket과 Bamboo를 사용할 수 있는 기회가 생겼다. Jira의 Issue 페이지 안에서 버튼 클릭만을 통해 브랜치를 생성하고, 그 브랜치가 배포 프로세스 중 어느 단계에 있는지 웹페이지에서 바로 확인할 수 있다는 것은 업무 생산성에 큰 이점이 있었다.
이에 따라, 기존 Gitlab/Jenkins 중심의 프로세스를 Bitbucket/Bamboo로 교체하는 작업을 진행하고 있다.
Gitlab에서 Bitbucket으로
Bitbucket/Bamboo로 전환하면서 브랜치 전략에도 변화를 주었다. 기존에는 배포 단계별로 서로 다른 저장소를 이용했다면, 변경 후에는 하나의 저장소 안에서 master/release/develop 브랜치로 분리하여 사용하기로 했다.
또한, 기존 Gitlab 사용 시에는 배포 단계별로 저장소가 나누어져있어 소스Diff정도만 이용했고 MR(Merge Request)는 사용할 필요가 없었다. 그러나 Bitbucket으로 전환하면서 하나의 저장소에 브랜치를 나누어 진행되므로 PR(Pull Request)를 적극 활용하여, 배포 단계별로 리더급의 승인이 나지 않으면 다음 프로세스를 진행하지 못하도록 구성했다.
개인(Local) 브랜치에서 단위 테스트를 마친 후 develop 브랜치에 Merge하도록 변경한 이후부턴 ‘오탈자 수정’과 같은 불필요한 이력이 사라지게되어 commit 이력이 이전보다 유의미해졌다.
Jenkins에서 Bamboo로
기존 Jenkins의 item을 Bamboo의 plan/deployment로 포팅하는 수준으로 전환 작업이 이루어졌다. 개발하는 입장에서는 큰 변화는 없었지만, 사용자 관점에서 본다면 이점이 있다면 많았다. UI가 직관적이며, Jira 및 Confluence와 연계성이 좋았고 사용자별 권한 제어가 Jenkins에 비해 친절했다.
배포 방식 변경
CI/CD 전환 시 어플리케이션 배포 방식도 변경했다. 변경한 이유 중 가장 중요한 것은 장애 대응이었다. 배포 이후 장애 발생 시 빠르게 원복하여 운영 서버를 정상화 시키는 것이 주 목적이었다.
- AS-IS : 형상서버 → 운영서버로 Class 파일 단위 COPY
- TO-BE : 형상서버 → 운영서버로 Branch(WAR 파일) 단위 COPY
Bamboo는 배포 담당자가 아니어도 단 번에 롤백을 진행할 수 있을 정도로 UI/UX가 잘 되어있다. 정확히는 과거 release들을 그대로 재배포 시키는 것인데, 콤보박스를 통해 여러 버전들 중 선택해서 바로 재배포할 수 있다.
두 번째 Promote 옵션을 통해 과거 release로 즉시 재배포 가능
물론 WAR 통배포 방식으로 변경하면서 좋아지기만 한 것은 아니었다. Class 단위로 배포를 진행했을 땐 배포 진행 도중 한 사람의 소스에서 이상이 발생할 경우 해당 파일만 제외시킨 후 배포해도 됬었다. 그러나 WAR 통배포로 변경 후에는 한 사람의 브랜치만 다시 롤백 시키고 배포시킬 수 없어, 배포 대상 브랜치를 재생성해야만 했다. 배포 직전 이슈 발생 시 조치하는 시간이 기존 5분에서 15분 정도로 더 늘어났다. 그럼에도 불구하고 WAR 통배포를 사용하는 이유는 배포 이후 장애 조치 시간이 Class 단위 배포보다 두 배 이상 빠르기 때문이다.
정리
개인적으로 생각하는 Gitlab/Jenkins 대비 Bitbucket/Bamboo의 장단점은 아래와 같다.
- 장점 : Jira/Confluence와의 연계성, 사용자 친화적 UI/UX
- 단점 : 3rd Party 플러그인 부족 및 기술관련 레퍼런스의 부재
협업 도구로 Jira와 Confluence를 사용하고 있을 경우 개발자 및 결재자 모두에게 이점이 많다. 배포 단계와 소스 변경사항에 대한 추적이 빠르기 떄문이다. 아쉬운 점은 도구 사용 중 이슈 발생 시 이를 해결하기 위한 레퍼런스가 생각보다 많지 않다는 것이다. Jira ↔ Bitbucket간 인증불가 문제와 같이 내가 경험한 이슈들도 제조사측 문의가 필요한 부분이 많아, 해결하는데까지 시간이 다소 필요했다.
