지난 9월 12일 서울 위워크 삼성점에서 GitLab 코리아 17번째 밋업이 오프라인으로 진행됐습니다. 이날 행사는 코로나19에 따른 ‘사회적 거리 두기’ 해제 조치 이후 ‘인포그랩과 GitLab 코리아의 첫 오프라인 밋업’이라는 의미가 있었죠. 밋업 주제는 **‘효율성과 생산성 높이는 GitLab 마이그레이션’**이었습니다. 밋업은 두 개의 세션으로 진행됐는데요. 세션 1에서는 유인철 GitLab 코리아 이사가 **‘GitLab 마이그레이션으로 얻는 유익’**을 주제로 발표했고요. 세션 2에서는 인포그랩 DevOps 팀에서 **‘Jira, GitLab으로 쉽게 마이그레이션 하기’**를 주제로 발표와 시연을 선보였죠. 이 글에서는 이날 밋업의 주요 발표 내용을 살펴보겠습니다.
GitLab의 주요 마이그레이션 기능 이모저모
세션 1에서는 GitLab의 주요 마이그레이션 기능과 GitLab 마이그레이션의 성공 사례를 다뤘는데요. 유인철 GitLab 코리아 이사는 GitLab의 마이그레이션 기능을 1)Self-managed(자체 관리형)에서 SaaS로, 2)GitHub 또는 Bitbucket 또는 Jira에서 GitLab으로, 3)기타 도구에서 GitLab으로 마이그레이션 하는 기능 이렇게 3가지로 나눠 소개했습니다. 특히 각 기능이 필요한 상황과 고려할 점, 준비사항, 마이그레이션 될 내용, 마이그레이션 방법 등을 자세히 알아봤어요.
1.Self-managed → SaaS
| 마이그레이션 방법 | 내용 |
|---|---|
| Project Export/Import | GUI 기반으로 이관 |
| Group Export/Import | 그룹 구성 정보만 주고받을 수 있음 |
| Direct Transfer | 별도 파일을 이동하지 않고 그룹, 서브그룹, 프로젝트를 GitLab.com에 전송 |
유 이사는 Self-managed에서 SaaS로 마이그레이션 해야 하는 상황을 이렇게 설명했습니다. 1)GitLab 인스턴스를 관리하는 데 부담을 느낄 때, 2)매달 새로운 기능을 적용하는 업그레이드가 부담될 때, 3)공유 러너(Runner)를 최대한 활용해서 서버를 효율적으로 이용할 때, 4)고가용성이 필요할 때, 5)더 안정적인 개발 환경이 필요할 때, 6)전 세계 어디서든 바로 작업할 수 있는 개발 환경이 필요할 때이죠.
그러나 Self-managed에서 SaaS로 마이그레이션 하기에 앞서 미리 고려할 점이 있다고 해요. 첫째, Self-managed와 SaaS 간 기능 차이를 알아야 합니다. 일례로 맞춤형 git hooks는 지원되지 않고요. push rules를 사용해야 한다고 합니다. 둘째, 프로젝트 사 이즈도 검토해야 하죠. 5GB 이하로 프로젝트 사이즈를 줄여야 합니다. 셋째, 러너 사용 전략을 고민해야 해요. GitLab에서는 공유 러너를 이용한 모든 job 시간의 합계를 ‘컴퓨터 할당량’이라고 하는데요. 이를 최대한 활용해야 합니다. 참고로 한 달 동안 사용할 수 있는 공유 러너 시간에는 제한이 있습니다.
이어서 유 이사는 Self-managed에서 SaaS로 마이그레이션 하는 방법 두 가지를 소개하고, 장단점을 각각 짚었습니다. 첫째, Project Export/Import 기능인데요. 이 기능을 사용하면 GUI(그래픽 사용자 인터페이스) 기반으로 이관할 수 있습니다. 내보내는(export) 파일이 5GB 이하면 쉽게 진행할 수 있죠. 그러나 5GB가 넘는 프로젝트에는 제약이 있고요. 동일한 사용자를 미리 만들어야 합니다.
둘째, Direct Transfer 기능인데요. 이 기능은 GitLab 15.6 버전부터 본격적으로 지원되고 있습니다. Direct Transfer 기능을 사용하면 별도 파일을 이동하지 않고도 그룹, 서브그룹, 프로젝트를 GitLab.com에 전송할 수 있는데요. ‘프로젝트까지 전송할지’ 여부도 선택할 수 있죠. 기능은 계속 업데이트되고 있고요. 일부 기능은 베타 단계이지만 정상적으로 동작합니다.
2.GitHub → GitLab
| 사전 준비 사항 |
|---|
| 1.GitLab에서 Maintainer 권한이 있는 사용자가 수행 |
| 2.프로젝트에 있는 GitHub 계정은 외부 연결 메일 계정이 있어서 GitLab과 매핑 가능 |
| 3.사용자 매핑 위해 GitHub의 이메일 주소가 GitLab에도 있어야 함 |
| 4.GitLab에서 import source로 GitHub이 활성화돼야 함 |
GitLab은 GitHub에서 GitLab으로 마이그레이션 하는 기능을 지원하고 있죠. 지난 8월 인포그랩 기술 블로그에서도 이를 자세히 소개했습니다. GitHub에서 GitLab으로 마이그레이션 할 때, Repository description(리포지터리 설명), Git repository data(Git 리포지터리 데이터), Branch protection rules(브랜치 보호 규칙), Collaborator(협업자), Issue, Pull request 등을 마이그레이션 할 수 있는데요. 이 밖에도 수많은 데이터를 마이그레이션 할 수 있죠. 앞서 언급한 인포그랩 기술 블로그에서 이 내용을 자세히 확인할 수 있습니다.
유 이사는 GitHub에서 GitLab으로 마이그레이션 할 때 사전 준비 사항으로 다음 내용을 제언했는데요. 첫째, GitLab에서 Maintainer 권한이 있는 사용자가 수행해야 합니다. 둘째, 프로젝트에 있는 GitHub 계정은 외부 연결 메일 계정이 있어서 GitLab과 매핑할 수 있죠. 셋째, 사용자 매핑을 위해 GitHub의 이메일 주소가 GitLab에도 있어야 합니다. 넷째, GitLab에서 import source로 GitHub이 활성화돼야 하는데요. 이는 Self-managed 사용자에게 적용되는 내용입니다.
GitHub Action에서 GitLab CI로 마이그레이션 할 수도 있죠. 이는 수동으로 진행해야 하지만 작업하기 쉽다고 하는데요. 첫번째, 마이그레이션 한 뒤에 .github/workflows 폴더를 보면 lint.yml, smoke.yml, unit.yml 이렇게 Action 파일 3개를 볼 수 있습니다. 두번째, import 된 프로젝트로 가서 WebIDE를 수행하고요. 세번째, 프로젝트 root에 .gitlab-ci.yml 파일을 생성합니다. 넷째, 앞서 언급한 Action 파일 3개의 주요 job 내용을 수동으로 복사해서 구성하고요.
3.Bitbucket 등 기타 도구 → GitLab
| 사전 준비 사항 |
|---|
| 1.GitLab에서 Maintainer 권한이 있는 사용자가 수행 |
| 2.GitLab에서 import source로 Bitbucket이 활성화돼야 함 |
GitLab은 Bitbucket에서 GitLab으로 마이그레이션 하는 기능도 지원합니다. 마이그레이션 되는 데이터와 마이그레이션 되지 않는 데이터를 잘 구분해야 하는데요. 유 이사는 각 데이터를 다음과 같이 설명했습니다. 마이그레이션 할 수 있는 데이터는 Repository description, Git repository data, Pull request, Pull request comments입니다. 그러나 Pull request approval과 Attachments in Markdown, Task list, Emoji reaction은 마이그레이션 할 수 없고요.
Bitbucket에서 GitLab으로 마이그레이션 할 때는 다음 사항을 미리 준비해야 한다고 하죠. GitLab에서 Maintainer 권한이 있는 사용자가 수행해야 합니다. 또 GitLab에서 import source로 Bitbucket이 활성화돼야 하는데요. 이는 Self-managed 사용자에게 적용되는 내용입니다. 이밖에 유 이사는 GitLab으로 마이그레이션 할 수 있는 플랫폼으로 Bitbucket Cloud, Bitbucket Server, Clear Case, CVS, FogBugz, Gitea, Perforce, TFVC, Jira 등도 소개했습니다.
GitLab 마이그레이션 성공 사례 누가 있나
많은 조직이 GitLab으로 마이그레이션 해 개발 효율성과 생산성을 높이고 있는데요. 유 이사는 국내외에서 GitLab으로 마이그레이션 한 성공 사례를 여러 가지 공유했습니다. 이 글에서는 세 가지 사례를 추렸습니다.
1.B사(Bitbucket → GitLab)
B사는 Bitbucket에서 GitLab으로 마이그레이션 했는데요. 이 회사는 하나의 제품으로 CI/CD까지 수행할 수 있는 환경이 필요했습니다. 아울러 고가용성 또는 재해복구 환경을 구축하는 확장 가능한 솔루션도 원했는데요. B사는 프로젝트 약 100개를 Bitbucket에서 GitLab으로 마이그레이션 했습니다. GitLab에서 제공하는 UI를 사용해 진행했고요. 사용자 계정은 미리 매핑했죠. 이 회사는 GitLab Ultimate 에디션을 사용하고 있는데요. 다양한 보안 검증 스캐너를 활용해 보안 검사를 수행합니다. 올해 업그레이드 과정에서 Geo 서버 간에 불일치가 있었지만 재동기화 기능을 사용해 문제를 해결했고, 정상 작동 중이라고 하죠.
2.Verizon(Jenkins → GitLab CI)
Verizon은 Jenkins에서 GitLab CI로 마이그레이션을 진행했습니다. 이 회사는 마이그레이션에 약 1년을 투자했는데요. 이와 관련해 다음 작업을 수행했습니다. 데이터 마이그레이션과 이관 작업을 진행했고요. 표준 CI/CD 템플릿을 작성했죠. 또 연관된 시스템과 연동 이슈를 검토하고 해결했고요. 자동 스케일 아웃되는 공유 러너를 구축했습니다. 사용자를 교육하고, 전체 프로젝트도 관리했고요.
3.OW2(Jira → GitLab)
OW2는 Jira에서 GitLab으로 마이그레이션 했는데요. 이곳은 Jira 정보를 그대로 유지하도록 별도의 마이그레이션 도구를 개발했습니다. 이로써 이슈 간 연결 관계, 이슈 생성과 업데이트 날짜, 커밋과 이슈 간 연결 관계를 유지했죠. OW2는 오픈 소스 커뮤니티를 위한 비영리 조직인데요. 커뮤니티에서는 GitLab으로 마이그레이션 한 데 긍정적 반응을 보였습니다. 이들은 GitLab의 이슈 추적, 워크플로에 만족하고요. 매일 사용하면서 생산성 향상을 경험한다고 하죠.
Jira에서 GitLab으로 마이그레이션 해야 할 이유
세션 2에서는 Jira에서 GitLab으로 마이그레이션 하는 방법과 마이그레이션 이후 GitLab으로 프로젝트를 협업하는 방법을 다뤘습니다. 먼저 신철호(Dexter) 인포그랩 이사가 Jira에서 GitLab으로 마이그레이션 해야 하는 이유를 설명했는데요. Jira 서버(Server) 제품의 지원 중단 문제와 사용자에게 주어진 선택지의 실효성, DevOps 측면에서 GitLab이 대안인 이유를 각각 살펴봤습니다.
1.Jira 서버 제품 지원 중단
2024년 2월 15일부터 Jira의 서버 제품 지원이 중단되는데요. 기존 서버 사용자는 ‘Jira 클라우드(Cloud) 제품으로 갈지, Jira 데이터 센터(Data Center) 제품으로 갈지’ 선택의 기로에 서 있습니다. 일례로 데이터 센터 제품으로 가려면 비용이 상당합니다. 이 제품의 라이선스당 사용자 수는 500명 단위인데요. 1500명 상업용 연간 가격은 4만2000달러(한화 5590만원)이죠. 그다음 단계인 5011000명 가격은 7만2000달러(한화 9580만원)고요. 조직이 감당하기에 부담스러울 수 있습니다.
신 이사는 사용자가 선택할 수 있는 대안으로 몇 가지 도구를 제시했습니다. Pivotal Tracker, IBM Engineering Requirements Management DOORS Next, Rally Software, GitLab, ServiceNow Agile Development, GitHub이 있죠. 신 이사는 “여기서 제일 좋은 선택은 조직에서 잘 쓰는 도구로 전환하는 것인데 GitLab이 좋은 대안이 될 수 있다”고 말했습니다. 이어서 일하는 방식의 변화 측면에서 조직이 요구받는 상황을 살펴봤어요.
2.DevOps 필요성 대두
먼저 Agile과 DevOps가 부상했죠. 신 이사에 따르면, 2018~2019년 국내에 Agile 붐이 폭발적으로 일면서 ITSM(IT 서비스 관리)에도 Agile이 완성형으로 만들어졌고요. 그 이후 **‘이제 Agile만으로 소프트웨어 개발의 전체 라이프사이클에 필요한 툴셋을 사용하기 어렵다’**는 판단에 DevOps 니즈가 많이 생겼습니다. 신 이사는 “Jira가 Agile의 완성형을 갖춘 도구라면, GitLab은 DevOps의 완성형 도구”라고 설명했습니다.
과거에는 워터풀 방식과 Agile 방식을 섞어서 3개월, 6개월 단위로 일하며 이터레이션을 돌렸고요. 완료하지 못한 일은 마지막 이터레이션을 돌리며 릴리즈했습니다. 현재는 스프린트가 끝났을 때 릴리즈하고, 완료하지 못한 일을 스프린트 끝에 진행하다가 이제 필요할 때 언제든지 릴리즈하는 환경으로 바뀌고 있죠. 신 이사는 “그렇게 되려면 Agile만으로 안 되고, DevOps로 소프트웨어 전체 라이프사이클에 필요한 협업 과정을 완성형으로 만들어야 한다”고 설명했습니다.
3.포인트 솔루션 한계
이러한 DevOps를 무엇으로 구현할 수 있을까요? 시중에는 여러 도구가 있습니다. 지속적 테스트 도구, CI 도구, SCCM(System Center Configuration Manager) 도구 등이 그 예죠. DevOps를 구현하기 위해 여러 도구를 사용하면 팀 간에 의사소통 문제, 높은 학습곡선 문제, 변화 관리 문제 등이 생길 수 있습니다. 신 이사는 “새로운 버전이 업그레이드되거나, 입 퇴사자가 빈번하게 생기거나, 그에 따른 도구 변화 관리 asset을 충분히 만들지 않으면 여러 도구를 쓰면서 많은 장애물이 발생한다”고 말했습니다. 그러나 GitLab은 단일 도구 안에서 소프트웨어 전체 라이프사이클에 필요한 기능을 모두 갖추는 방향으로 발전하고 있고요. 현재 많은 부분에서 완성형을 띄고 있죠.
4.소프트웨어 전체 개발 라이프사이클 지원 필요
이제 DevOps 활동은 필수가 됐습니다. 신 이사에 따르면, ‘우리가 소프트웨어를 빌드해서 고객이 원할 때 기능을 선보이도록 준비하는 과정을 얼마나 잘 수행할 수 있을까?’ 생각해 봐야 하죠. 물론 Jira에는 대체할 수 없는, 좋은 기능이 많습니다. 그러나 Jira 기능만으로 소프트웨어 개발의 핵심 활동을 모두 다루기는 쉽지 않다는대요. 신 이사는 “GitLab은 마일스톤을 만드는 상위 에픽, 요구사항 만들기, 기능을 개발한 다음, 그 기능의 CI/CD 파이프라인을 자동화하고, 이를 출시할 준비를 거쳐 선보이기까지 전체 흐름을 만드는 데 초점을 두고 있다”고 말했죠. 정리하면 Jira에서 한정적으로 사용하는 기능을 GitLab은 다 갖추고 있고요. GitLab으로 이관하면 이런 기능을 편리하게 사용할 수 있습니다.
Jira에서 GitLab으로 손쉽게 마이그레이션 하는 방법
이어서 손성훈(Jeff) 인포그랩 DevOps 엔지니어가 Jira에서 GitLab으로 마이그레이션 하는 방법을 설명하고, 마이그레이션 자동화 시연을 선보였는데요. 앞서 인포그랩 DevOps 팀은 Jira에서 GitLab으로 마이그레이션 하는 토이 프로젝트를 진행했습니다. ‘Jira에서 서버 제품을 더 이상 지원하지 않는다’는 기사가 계기였고요. 팀은 ‘Jira 서버를 이용하던 사람들은 어떡하지? 우리가 GitLab으로 마이그레이션 하는 프로젝트를 만들어 볼까?’라는 생각으로 프로젝트를 기획했죠. 손 엔지니어는 팀이 진행한 ‘Jira에서 GitLab으로 마이그레이션 하는 토이 프로젝트’를 토대로 GitLab의 마이그레이션 기본 도구와 고려 사항, 한계점, PoC 결과를 각각 다뤘습니다.
1.Jira → GitLab 마이그레이션 기능 현황
GitLab은 Jira에서 GitLab으로 마이그레이션 하는 기능을 지원하고 있죠. GitLab에서는 Jira 이슈의 title, description, label을 복사하고요. 나머지 메타 데이터는 description으로 가져옵니다. 또 Jira User를 GitLab User로 매핑 UI도 제공하고요. 이 기능은 약 3년 전 계획, 개발된 걸로 알려졌습니다. 마이그레이션 기능에는 제약사항이 일부 있는데요. 첫째, Jira Integration 설정이 필수입니다. 둘째, Jira API v3만 제공하고요.
손 엔지니어에 따르면, Jira와 GitLab은 사용 문법이 달라 정확하게 마이그레이션 되지 않기도 합니다. 예를 들어, description에서 ‘Heading 1’, ‘Heading 2’, ‘Heading 3’가 GitLab에는 ‘Numbered’, ‘SubNumbered’, ‘SubNumbered 2’로 옮겨졌는데요. 이는 GitLab은 마크다운 문법을 사용하고, Jira는 마크다운 대신 ‘ADF(Atlassian Document Format)’라는 독자 규격을 써서 생긴 차이라고 하죠. 또 issue type이나 priority, label도 정확하게 마이그레이션 되지 않는다고 하고요.
2.인포그랩 DevOps 팀 마이그레이션 프로젝트 방향
손 엔지니어는 팀에서 마이그레이션 프로젝트를 진행하며 위 문제를 개선하기 위해 두 가지 목표를 세웠다고 합니다. 첫째, ‘Jira의 에픽은 어디로 가고, 이슈는 어디로 가야 하는지’ 의사결정을 내렸고요. 둘째, ‘title, description, label, component 등 Jira 이슈의 필드가 GitLab의 어떤 필드로 가야 할지’ 구체적으로 마이그레이션을 진행하기로 했죠. 정리하면 프로젝트와 이슈 계층구조, 필드 매핑을 고려해 마이그레이션을 수행했습니다. 구체적으로는 Jira의 에픽을 GitLab의 에픽으로 옮길 때, 서브 그룹에 있는 서브 에픽으로 마이그레이션 할지, 아니면 상위 그룹에 있는 에픽으로 마이그레이션 할지 사용자가 결정하도록 자유도를 줬고요. 이슈는 이슈로 마이그레이션 하도록 했습니다.
그러나 마이그레이션에는 다음 한계가 있었습니다. 서브 태스크도 서브 태스크 아래 이슈에 있는 태스크로 마이그레이션 하고 싶었지만 현재 GitLab의 태스크 API가 지원하지 않고요. 손 엔지니어는 “’내년에 지원한다’는 마일스톤이 잡혀 있어서 해당 API가 오픈하면 그때 서브 태스크를 태스크로 마이그레이션 할 수 있다”라고 설명했습니다. 아울러 Jira에 필드가 너무 많다는 점도 문제였죠. description, label, component 같은 단순한 기능은 GitLab에서도 지원해 마이그레이션 할 수 있는데요. 다양한 time tracking, security 관련 필드는 GitLab에서 지원하지 않아 마이그레이션 하지 못한다고 합니다.
인포그랩 DevOps 팀은 이 한계를 바탕으로 최종 설계도를 만들었는데요*.* Jira의 프로젝트는 GitLab의 프로젝트로, Jira의 에픽은 GitLab의 에픽으로, Jira의 이슈는 GitLab의 이슈로 가기로 하고요. Jira의 title, description, version, story point, resolution은 GitLab에 그대로 매핑할 수 있었습니다. Jira의 resolution은 GitLab의 closed로, Jira의 story point는 GitLab의 weight로 옮겼죠. Jira의 issue type, component, status, priority는 GitLab의 label과 scoped label을 사용해 모두 마이그레이션 했고요. 이밖에 몇 가지 custom field도 개발했습니다. 특히 인포그랩 DevOps 팀이 집중한 부분은 description인데요. 포맷을 정규 표현식으로 모두 파싱한 다음, 그 내용을 마크다운으로 변환해 마이그레이션을 진행했습니다.
3.마이그레이션 프로젝트 결과
마이그레이션 결과는 이렇습니다. Jira 순정 모드를 마이그레이션 하는 건 쓸만했고요. 플러그인, 오토메이션을 빼면 마이그레이션이 잘 됐습니다. GitLab Label로 대부분 매핑했고요. 타깃 상위 그룹에 에픽도 생성했습니다. Jira에서 연결된 이슈 링크를 GitLab에도 마이그레이션 했고요. Jira wiki markup은 Markdown 컨버터로 변환했죠. 이슈에 attachment, comment도 추가했고요. 그러나 custom field를 많이 만들면 마이그레이션 할 때 어려움이 있다고 합니다.
손 엔지니어는 마이그레이션을 이렇게 회고했는데요. 잘한 점은 첫째, 클라우드 버전을 먼저 만들고, 서버용을 추가로 만들었다는 점이고요. 둘째, custom field 매핑만 설정하면 대부분 마이그레이션 할 수 있다는 점입니다. 셋째, 병렬 처리를 적절히 구성해 이를 하지 않았을 때보다 3배 이상 빠르게 마이그레이션 하도록 했다는 점이고요. 넷째, 트렌드에 맞게 YAML 기반으로 설정 관리했다는 점입니다. 다섯째, 오픈 소스로 누구나 마이그레이션 할 수 있도록 했다는 점이고요. 여섯째, Brew로 패키지를 배포했다는 점이죠.
개선할 점은 다음과 같다는데요. Jira 서버에서 마이그레이션 할 때는 이렇습니다. 첫째, 스프린트 매핑이 추가로 필요하다는 점입니다. 둘째, Cascade 필드는 방법이 없다는 점이고요. Jira 클라우드에서 마이그레이션 할 때 개선할 점은 이렇습니다. 플러그인 관련 데이터 마이그레이션 등 수많은 실제 케이스에 테스트가 필요하다고 하죠. 인포그랩 DevOps 팀의 이번 프로젝트는 오픈 소스 프로젝트인데요. 이를 함께 개선하고 싶은 분은 github.com/infograb/j2lab이나 gitlab.com/infograb-public/j2lab으로 참여하면 됩니다.
마이그레이션 이후 GitLab에서 할 수 있는 일
그다음, 한동민(Kane) 인포그랩 DevOps 엔지니어가 ‘ 마이그레이션 이후 GitLab에서 Jira 기능을 어떻게 사용할 수 있는지’ 설명했습니다. 프로젝트를 관리하는 방법과 마이그레이션 데이터를 활용한 실제 사례, Jira 오토메이션 같은 워크플로를 GitLab에서 사용하는 방법을 소개했습니다.
Jira는 issue type이나 custom field, status, enforced workflow를 별도로 두죠. 이는 GitLab의 scoped label을 사용해 다 관리할 수 있습니다. Jira 오토메이션 같은 enforced workflow는 GitLab Triage를 활용해 대체할 수 있죠. 아울러 GitLab은 Jira에 없는 기능이 있는데요. GitLab은 기본적으로 Git 저장소이기에 Merge Request(MR)와 같은 코드 리뷰 기능을 지원합니다. 아울러 GitLab은 올인원 플랫폼이라서 사용자가 프로젝트 형상 관리부터 DevSecOps까지 다양한 업무를 단일 플랫폼에서 수행할 수 있고요. 지금부터 Jira 기능을 GitLab에서 사용하는 방법 또는 Jira에 없는 GitLab 기능을 자세히 살펴보죠.
1.프로젝트 로드맵과 상위 수준 트래킹
이는 Jira의 Backlog에 해당하는 기능으로, GitLab의 Roadmap, Epic Board에서 이용할 수 있죠. Roadmap은 회사/제품 로드맵을 관리하고요. Epic Board는 비즈니스/포트폴리오 워크플로를 관리합니다. Roadmap에서는 하위 에픽을 둬 선명하게 관리할 수 있고요. 시간선으로 나타내어 전체 일정을 한눈에 볼 수 있습니다. 에픽별 목표 달성 수준도 %로 보여주고요. Epic Board에서는 상위 수준 에픽도 칸반으로 관리할 수 있죠. Jira와 달리 에픽 자체 워크플로를 관리하는 칸반 보드를 제공하고요. label을 사용한 필터링으로 쉽게 맞춤화할 수 있습니다.
2.프로젝트 활동 트래킹
이는 GitLab의 Issue Board와 Milestone 기능을 활용할 수 있습니다. Issue Board에서는 칸반 보드를 지원하고요. 여기서는 Jira와 비슷하게 이슈 상태를 추적할 수 있습니다. Jira의 릴리즈는 마일스톤으로 대체할 수 있고요. Jira의 스프린트는 이터레이션으로 대체할 수 있죠. 이슈를 누르면 각 마일스톤의 이슈 보드를 확인할 수 있고요. 마일스톤을 클릭하면 시각화 차트를 제공하며 해당 마일스톤의 해당 버전 동안 어떤 이슈가 있었는지 볼 수 있습니다. 이터레이션도 누르면 해당 이터레이션 동안 어떤 이슈가 있었고, 어떤 기능을 개발했는지 확인할 수 있죠.
3.이슈
이는 GitLab의 Issue Filter, Issue/MR Quick Action 기능으로 수행할 수 있는데요. Issue Filter로는 이슈를 신속하게 탐색할 수 있고요. Issue/MR Quick Action으로는 이슈를 빠르게 생산하고, 소비할 수 있습니다. Issue Filter에서 label과 마일스톤, 담당자를 조합해 텍스트 기반으로 검색하면 대부분 이슈를 빠르게 탐색할 수 있고요. Issue/MR Quick Action을 사용하면 ‘/’ 커맨드를 눌러 GitLab 페이지에서 이슈 생성 창으로 이동할 수 있죠. 같은 키를 눌러 이슈 필드도 생성할 수 있습니다. Quick Action은 GitLab에만 있는 기능인데요. 마우스를 클릭하지 않고 키보드만으로 작업할 수 있어 엔지니어 선호에 부합합니다.
4.Merge Request
앞서 언급했듯 이는 Jira에는 없고, GitLab에 있는 기능이죠. GitLab은 Git 저장소라서 프로젝트를 관리할 수 있고요. 따라서 Merge Request로 변경 사항을 추적하고, 코드를 리뷰하며, 승인 체계도 만들 수 있습니다. GitLab에는 멤버별로 권한이 있어 함부로 merge 할 수 없도록 승인 체계를 운영할 수 있죠. 아울러 인라인 에디터로 코드도 리뷰할 수 있는데요. 에디터에서 코드를 클릭하면 코멘트를 달 수 있고요. 코멘트를 사용하면 리뷰 부분을 정확히 명시할 수 있죠. Resolved Thread 기능을 사용해 코드 관련 의견도 주고받을 수 있습니다.
5.CI Job 결과, Artifact로 리뷰
이는 GitLab의 Merge Request Widget과 Artifact 기능을 활용할 수 있죠. Merge Request Widget을 사용하면 CI 작업 결과를 MR에서 즉시 확인할 수 있습니다. Artifact로는 공유 산출물을 빠르게 취합하고요. Merge Request Widget으로 MR 파이프라인 동작, 파이프라인 결과를 볼 수 있습니다. 아울러 Artifact로 파이프라인 결과를 바로 체험할 수 있는데요. 파이프라인 탭에서 Artifact를 누르면 작동한 파이프라인의 Artifact를 각각 다운로드 받을 수 있습니다.
6.GitLab Triage Bot으로 에스컬레이션
이는 Jira의 오토메이션 기능에 해당하는 기능입니다. GitLab Triage Bot은 에픽, MR, 이슈 에스컬레이션을 봇으로 실행하죠. GitLab Triage Bot에서는 인스턴스, 특정 그룹, 특정 프로젝트를 대상으로 Triage를 실행할 수 있고요. Job에서 정책에 따라 작업을 진행합니다. 또 스케줄을 생성하면 자동으로 정책에 따라 작업을 실행하고요.
맺음말
지금까지 GitLab 코리아 17번째 밋업의 주요 발표 내용을 살펴봤습니다. 이 글의 요점은 다음과 같은데요.
1.GitLab의 마이그레이션 기능은 1)Self-managed(자체 관리형)에서 SaaS로, 2)GitHub 또는 Bitbucket 또는 Jira에서 GitLab으로, 3)기타 도구에서 GitLab으로 마이그레이션 하는 기능으로 구분할 수 있습니다.
2.GitLab Self-managed에서 SaaS로 마이그레이션 할 때는 1)Project Export/Import 기능, 2)Direct Transfer 기능을 사용할 수 있습니다.
3.Jira에서 GitLab으로 마이그레이션 해야 하 는 이유는 다음과 같은데요. 첫째, 2024년 2월 15일부터 Jira의 서버 제품 지원이 중단됩니다. 기존 서버 사용자는 ‘Jira 클라우드(Cloud) 제품으로 갈지, Jira 데이터 센터(Data Center) 제품으로 갈지’ 선택의 기로에 서 있죠. 데이터 센터 제품으로 가려면 비용이 상당합니다.
4.둘째, GitLab은 기존 Jira 서버 사용자에게 좋은 대안이 될 수 있죠. 이제는 Agile만으로 안 되고, DevOps로 소프트웨어 전체 라이프사이클에 필요한 협업 과정을 완성형으로 만들어야 하는데요. GitLab은 이에 적합한 수단입니다.
5.셋째, GitLab은 단일 도구 안에서 소프트웨어 전체 라이프사이클에 필요한 기능을 모두 갖추는 방향으로 발전하고 있습니다. Jira 기능만으로 소프트웨어 개발의 핵심 활동을 모두 다루기는 쉽지 않은데요. Jira에서 한정적으로 사용하는 기능을 GitLab은 다 갖추고 있죠.
6.인포그랩 DevOps 팀은 Jira에서 GitLab으로 마이그레이션 하는 오픈 소스 프로젝트를 진행했는데요. 프로젝트와 이슈 계층구조, 필드 매핑을 고려해 마이그레이션을 수행했습니다.
7.구체적으로 Jira의 프로젝트는 GitLab의 프로젝트로, Jira의 에픽은 GitLab의 에픽으로, Jira의 이슈는 GitLab의 이슈로 마이그레이션 하고요. Jira의 title, description, version, story point, resolution은 GitLab에 그대로 매핑했습니다. Jira의 resolution은 GitLab의 closed로, Jira의 story point는 GitLab의 weight로 옮겼죠. Jira의 issue type, component, status, priority는 GitLab의 label과 scoped label을 사용해 모두 마이그레이션 했고요. 이밖에 몇 가지 custom field도 개발했습니다.
8.마이그레이션 결과는 긍정적이었습니다. Jira 순정 모드를 마이그레이션 하는 건 쓸 만 했고요. 플러그인, 오토메이션을 빼면 마이그레이션이 잘 됐습니다. GitLab Label로 대부분 매핑했고요. 타깃 상위 그룹에 에픽도 생성했습니다. 이슈 맵을 그리고 GitLab에서 매핑했고요. Jira wiki markup은 Markdown 컨버터로 변환했죠. 이슈에 attachment, comment도 추가했고요. 다만 custom field를 많이 만들면 마이그레이션 할 때 어려움이 있다고 합니다.
9.마이그레이션 이후에는 GitLab에서 Roadmap과 Epic Board를 사용해 프로젝트 로드맵을 관리하고, 상위 수준에서 트래킹할 수 있습니다. 아울러 Issue Board와 Milestone으로 프로젝트 활동도 트래킹할 수 있고요. Issue Filter, Issue/MR Quick Action으로 이슈를 빠르게 탐색하고, 생산하며, 소비할 수 있죠. 또 Merge Request(MR)로 변경 사항을 추적하고, 코드를 리뷰하며, 승인 체계도 만들 수 있고요. CI 작업 결과를 MR에서 즉시 확인할 수 있습니다. Artifact로는 공유 산출물을 빠르게 취합하고요. 이 밖에 GitLab Triage Bot으로 Jira의 오토메이션에 해당하는 기능을 수행할 수 있죠.
인포그랩은 GitLab 및 DevOps에 대한 맞춤 기술 지원을 제공합니다. GitLab(Omnibus/Cloud Native Hybrid) 구축 관련한 지원이 필요하시면 문의하기 로 연락 주십시오.