센드버드 SDK 배포 자동화 도입하기

안녕하세요. Client Foundation 팀 Ernest Hong입니다. 이번 글에서는 SDK 배포 자동화를 도입하게 된 배경과 문제해결 과정을 소개해드리겠습니다. 사내 Tech Talk에서 발표했던 내용을 기반으로 글을 작성합니다. 이 프로젝트를 시작하기 전에 자동화에 대한 많은 경험이 없었기 때문에 여러 시행착오를 겪었습니다. 처음 시작하는 분들도 쉽게 이해할 수 있도록 어떤 상황에서 어떤 식으로 문제를 해결했는지 구체적으로 설명하겠습니다.

1. 왜 자동화가 필요했나요?

저희의 배포 프로세스를 보면 다음과 같습니다.

1. 배포 Jira 티켓 생성

2. 매니저가 Jira 티켓을 승인

3. Private repo 브랜치 정리

4. SDK 빌드

5. Public repo에 새로운 버전 푸시

6. Package Manager에 새로운 버전 업데이트

7. Slack으로 배포 완료 메시지 전송

이 과정을 수동으로 하면 어떤 문제가 있을까요? 배포를 위한 Jira 티켓을 생성하고 승인받는 과정에서 사람이 직접 개입하기 때문에 딜레이가 발생합니다. 그다음 과정들에서도 엔지니어가 직접 처리해야 하고 실수할 수 있는 가능성이 항상 존재합니다. 저는 배포할 때가 되면 배포하는 방법을 써둔 페이지를 열어두고 하나하나 조심스럽게 작업했습니다. 자동화를 위해 인터뷰를 해보니 다른 분들도 비슷한 어려움이 있는 것을 알게 되었습니다. 한 번 실수하면 잘못된 제품이 배포될 수 있는 환경이었습니다. 그리고 changelog를 작성하는 과정에서 slack으로 여러 번 소통해야 했기 때문에 배포마다 번거롭다는 느낌을 받았습니다. 이런 어려움을 해소하기 위해 다음과 같은 목표를 세웠습니다.

1. 배포하는 시간 동안 엔지니어의 손발이 묶이지 않도록 개선하기

2. Changelog를 변경하기 위한 커뮤니케이션 코스트 최소화하기
   Changelog 확정을 위해서 slack으로 여러 번 핑퐁을 해야 했는데 이런 과정을 최소화하고 싶었습니다.

3. 배포할 때 실수를 걱정할 필요 없게 만들기
   수동으로 배포할 때는 여러 번 배포를 해봐도, 한쪽에 배포하는 방법을 띄워놓고 하나하나 틀린 건 없는지 확인하면서 배포해야 했습니다.

4. 빠르고 안정적으로 SDK 배포해서 엔지니어, PM, 고객이 모두 만족할 수 있게 만들기

2. 자동화 도입

먼저 자동화를 도입한 결과물부터 보고, 다음 챕터에서 작동원리를 알아보겠습니다. 엔지니어는 기존에 하던 대로 release 브랜치를 생성합니다. 프로젝트마다 git 전략이 다를 수 있지만 여기서는 git-flow 전략을 따르는 것을 예시로 합니다.

새로운 버전에 변경되는 내용들을 CHANGELOG_DRAFT.md 파일에 작성하고 커밋합니다. 엔지니어가 변경 사항들을 초안으로 작성할 수 있습니다. 초안이기 때문에 나중에 매니저가 자유롭게 수정할 수 있습니다.

Release 브랜치에서 Master 브랜치로 머지하는 Pull Request를 하나 생성합니다. Release에서 Develop 브랜치로 머지하는 것은 자동화가 알아서 처리하도록 했습니다.

PR 코멘트로 `/bot create ticket`을 입력하면 배포 티켓 생성이 시작됩니다.

성공적으로 티켓이 생성되었으면 github 코멘트로 배포 티켓링크를 확인할 수 있습니다.

티켓을 승인할 수 있는 권한을 가진 매니저에게 slack으로 메시지를 보냅니다.

이 배포 티켓에는 이번 배포에 포함되는 작업 목록과 changelog 링크가 있습니다. 연관된 작업 목록을 보여주는 기능이 꼭 필요했습니다. 왜냐하면 배포 티켓을 관리하는 Jira Board와 작업 티켓이 관리되는 Jira Board가 달라서 어떤 작업이 배포되는 건지 알아보기 어려웠기 때문입니다.

자동화 초기 버전에는 텍스트로 필드에 changelog 내용을 넣어줬었는데, 마크다운 형태로 확인할 수 없는 단점이 있었습니다. 그래서 release branch의 해당 파일로 향하는 github link를 연결해줬습니다. 이제 매니저가 수정하고 싶으면 github link로 가서 아래와 같이 수정하면 됩니다.

매니저가 이제 배포해도 좋겠다고 승인하면 티켓을 Approved(Release Approved) 상태로 변경합니다.

이제부터는 자동화가 알아서 처리해줍니다. 배포 티켓 상태가 자동으로 Releasing으로 변경됩니다. 배포를 신경쓰지 않고 다른 작업을 하거나 휴식할 수 있습니다.

성공적으로 배포가 되었으면 slack으로 이런 메시지가 옵니다. 특정 제품과 버전이 배포되었다는 것을 알려줍니다.

3. 작동 원리

배포 작업을 크게 2개로 나눠서 설명하겠습니다. 첫 번째는 배포 티켓 생성이고, 두 번째는 그 티켓을 기반으로 SDK를 배포하는 작업입니다.

3-1. 티켓 생성

티켓 생성부터 살펴보겠습니다. Github Release PR에 코멘트를 달면 배포 티켓이 생성되는 것을 앞에서 확인했습니다. 이 동작을 만들려면 PR에 코멘트가 되었을 때를 인식해야 합니다.

이 작업을 보통 Github Bot을 통해서 구현하는데, 저희는 Github Action을 통해서 명령어 인식을 했습니다. 트리거가 되는 조건을 issue_comment에 걸어뒀는데, pr_comment만 인식하는게 따로 없어서 이렇게 걸어뒀습니다. URL 부분에 /pull/ 이라는 주소를 통해서 PR에 달린 코멘트인것을 확인했습니다.

Github Action으로 명령어를 인식하는 것에 대한 실험 과정은 아래 블로그 글에서 확인할 수 있습니다:

Github Action으로 comment bot 만들기

Github Comment로 CircleCI 실행시키기

센드버드에서는 CircleCI를 주요 CI 플랫폼으로 사용하고 있기 때문에 명령어 인식까지만 Github Action으로 하고 바로 CircleCI를 트리거 해줍니다.

CircleCI API로 Job을 트리거 합니다. CircleCI에서는 작업의 묶음을 Pipeline이라고 부릅니다. 그래서 이 API 주소에도 Pipeline이라고 적혀있고요. CircleCI를 사용할 때 굉장히 불편하다고 생각되는 점이 있는데 특정 Pipeline을 트리거하기가 번거롭다는 점입니다. 특별히 뾰족한 방법을 찾지는 못했고, 빨간색으로 표시해둔 것처럼 flag를 둬서 트리거 했습니다.

위의 API가 호출되면 CircleCI에서는 프로젝트의 config.yml에 약속된 규칙대로 Pipeline을 실행합니다. config.yml 파일에도 `run_workflow_create_ticket`이라는 flag가 있는 것을 확인할 수 있습니다.

그리고 CircleCI 위에서 Jira API를 호출해서 배포 티켓을 생성합니다.

구현 부분은 Python script로 만들어두고 여러 파라미터를 넘겨서 사용했습니다. 이전에는 엔지니어가 직접 티켓을 생성하고 티켓의 여러 필을 직접 채워야 했는데요. 이제는 자동화를 통해 일관적인 티켓을 생성할 수 있게 되었습니다.

아래는 스크립트 구현 중에 해당 버전의 연관된 이슈를 가져오는 API 호출입니다. JQL을 통해서 fixVersion이 매칭되는 이슈들을 가져오도록 검색했습니다. Pagination이 적용되어 있어서 제대로 구현하려면 마지막 페이지까지 가져오는 식으로 기능 구현을 해야할텐데, 저희는 API가 허용하는 최대 개수인 1000개면 충분하다고 판단해서 간단히 1페이지만 가져오도록 구현했습니다.

혹시 Jira 티켓 상태를 어떻게 정의해두었는지 궁금해하실 분들을 위해 간단히 설명하겠습니다. 저희는 다음과 같이 배포 티켓의 상태를 정의했습니다:

• OPEN: 티켓 생성됨

• CANCELLED: 배포 취소됨

• RELEASE APPROVED: 배포 승인됨

• CONDITIONAL RELEASE APPROVED: 배포 승인되었으나 수정 필요함

• RELEASING: 배포 중

• RELEASED: 배포 완료

State Machine처럼 각 상태를 변경할 수 있는데요. 어떤 방향으로 전환할 수 있는지, 누가 상태를 변경할 수 있는지도 정의할 수 있습니다.

3-2. 배포

티켓이 생성되었으니 PM이 내용을 확인하고, 티켓을 Approved 상태로 변경합니다.

티켓 상태가 Approved로 변경된 것을 감지해서 CircleCI를 트리거해야하기 때문에 Jira Automation을 사용했습니다.

Jira Project > Setting > Automation에서 조건을 만족하면 API 호출을 할 수 있습니다. Send web request라는 action을 사용했습니다. 처음 실험을 시작했을 때는 Token 값을 hidden 하는 설정이 없어서 보안 걱정을 했었는데, 실제로 사용할때 쯤에는 Hidden 옵션이 생겨서 보안 걱정 없이 사용할 수 있게 되었습니다. 필드 값 오른쪽에 Hidden 옵션이 있는데 한번 체크하면 해제할 수 없습니다.

다음 단계에서는 private repo의 브랜치들을 머지해주고 SDK를 빌드합니다. 빌드된 결과물을 public repo로 배포합니다. 이 과정은 연속적으로 일어납니다. 이 단계에서는 git과 github API를 사용했습니다.

위의 과정 중에서 Github Release 만드는 부분을 자세히 살펴보겠습니다. Github API를 통해 버전명, Changelog, Framework 파일들을 업로드합니다. 이전에는 하나씩 복사해서 붙여 넣었는데 번거로운 과정을 직접 하지 않게 되어서 만족스러웠고, Git Repo에 커밋하고 Release 하는 데까지 걸리는 시간을 줄일 수 있어서 좋았습니다.

다음으로는 package manager에 업로드 합니다. 예를 들어 iOS에서는 CocoaPods 처럼 중앙화된 패키지 관리 서버에 업로드 합니다.

마지막 단계에서 성공 여부에 따라 적절한 slack 메시지를 전송합니다.

CircleCI에서 Orbs라는 일종의 라이브러리가 있는데, slack도 orbs로 만들어져 있는게 있어서 이것을 사용해서 간편하게 메시지를 전송했습니다. Slack orbs 4.x 버전에서는 web hook을 만들지 않고 OAuth Token을 등록해 channel id를 입력하는 방식으로 변경되어서 한번 세팅해두면 여러 채널에 메시지를 보낼 수 있습니다. 그리고 private channel에는 bot 계정을 멤버로 초대해둬야 메시지를 보낼 수 있습니다.

4. 마무리

수동배포와 자동배포를 비교해봤을 때 이런 차이를 느낄 수 있었습니다. 배포 티켓 생성을 명령어로 하게 되어서 간편해졌습니다. 배포 티켓이 Approve 상태로 변경되는 것을 계속 지켜볼 필요가 없어졌습니다. CHANGELOG 수정을 위해서 여러번 대화하고 엔지니어가 직접 수정할 필요도 없어졌고, SDK 빌드와 배포가 CI에서 이뤄져서 안정적으로 배포할 수 있게 되었습니다.

프로젝트를 진행하면서 많은 것들을 배울 수 있었습니다. 적절한 배포 프로세스를 정의하는 데 시간이 꽤 걸린다는 것을 알게 되었습니다. 다양한 분들을 인터뷰하면서 좋은 아이디어를 얻을 수 있었고 아이디어를 반영하는 과정에서 새로운 도구들을 사용해볼 수 있었습니다. Python도 많이 사용해본 적 없었는데 생산성을 향상하는 데 많은 도움을 받았습니다. 여러 API들을 다뤄보면서 앞으로도 지루하거나 두려운 일에 자동화를 도입할 수 있겠다는 자신감도 생겼습니다.

자동화 프로세스를 앞으로도 개선할 부분이 많습니다. 현재는 Chat에만 배포 자동화가 적용되어 있어 다른 product에도 자동화가 필요합니다. 개별 Repo마다 스크립트 구현이 분산된 구조인데 관리해야 하는 지점이 여러 군데라는 단점이 있습니다. 이런 단점을 해소하려면 배포에 관련된 스크립트들을 가능하면 중앙화된 서버에 두는 방법이 필요할 수도 있습니다.

배포 자동화를 도입하게 된 배경과 방법, 그리고 배운 점에 대해서 정리했는데 이 글이 여러분의 상황을 개선하는데 도움이 되면 좋겠습니다. 혹시 더 좋은 방법을 아신다면 저희에게 연락해주셔도 좋고, 미래에 저희 팀으로 합류해서 함께 논의해봐도 즐거울 것 같습니다. 긴 글 읽어주셔서 감사합니다!