지난 블로그에서는 “GitOn : Agent 등록부터 CI/CD 파이프라인 배포까지“라는 주제를 통해 DevOps 환경에서의 생산성을 극대화하는 GitOn의 효율적인 배포 프로세스에 대해 살펴보았습니다.
이번 글에서는 그 연장선으로 “GitOn에서 Issue기반의 협업은 어떻게 이루어질까” 라는 주제를 다루고자 합니다. 이전 내용과 많은 부분이 연계되어 있으니 원활한 이해를 위해 이전 블로그의 내용을 보고 오시는 것을 권장 드립니다.
GitOn은 협업 중심의 Git 소스 코드 관리 플랫폼으로, Issue management 기능을 내장하고 있습니다. 흔히 사용하는 GitHub나 GitLab과 같은 클라우드 기반 Git 호스팅 플랫폼에서도 Issue 관리 기능을 지원하는데요, 이러한 플랫폼에서 관리되고 있는 오픈 소스 프로젝트들을 여럿 살펴보면 거의 대부분 이슈기반으로 Task를 등록해서 issue와 commit 그리고 pull request까지 Reference로 연결해서 추적성을 가져갈 수 있게 협업을 진행하고 있습니다. 즉, Issue – Commit – Pull Request가 서로 Reference로 연결되어 작업 추적이 용이하고 협업의 효율성을 높여줍니다. 이는 모든 개발자와 IT 전문가가 공감할 만한 기본적인 워크플로우입니다.
그렇다면 우리는 왜 GitOn을 사용해야 할까요?
다른 장점도 많지만 Issue 관리 측면에서만 보면 타 Git 협업 시스템에서는 지원하지 않는 Issue의 custom field 설정, Issue의 state custom 설정, 그리고 state의 workflow를 custom할 수 있어서 설정의 자유도가 높다는 장점을 가지고 있습니다. 이러한 유연한 설정은 다른 Git 협업 플랫폼에서는 찾아보기 어렵고, 프로젝트 관리 및 협업의 질을 한층 더 높이는 역할을 합니다.
이번 블로그에서는 Issue와 관련된 커스텀 설정들을 구성해보고, 데모 프로젝트에서 Issue생성부터 commit과 Pull Request 생성 및 Branch 병합까지 어떻게 연계가 가능한지를 전체 사이클로 보여드리겠습니다.
1. Custom Field등록
Admin 계정으로 로그인 한 후 Administration -> Issue Settings -> Custom Fields 탭으로 진입해보겠습니다.
전체 프로젝트에서 사용할 수 있는 field 목록을 볼 수 있고 + 버튼을 눌러보면 다양한 field type을 확인 해보실 수 있습니다. 예를 들어 관리자 라는 field를 정의할 때, Priority(우선순위)가 Major거나 Critical 같이 높은 우선순위를 가졌을 경우 특정 프로젝트의 소유주 혹은 관리자레벨의 유저는 무조건 해당 이슈의 추이를 지켜볼 수 있게 담당자로 할당이 되어야 하는 Advanced한 설정을 원할 수 있습니다. 이러한 복잡한 조건을 가진 field도 GitOn의 custom field 설정으로 생성 가능합니다.
관리자라는 하나의 field를 생성해보겠습니다.
Type은 User로 선택을 하고 Name을 관리자라고 적어주겠습니다. 그리고 여러명의 유저를 할당할 수 있게 `Allow Multiple` 옵션을 활성화 해주겠습니다. `Show Conditionally`는 다른 field가 어떠한 조건을 만족할 경우에만 해당 field가 보여지게 하는 옵션으로, 활성화를 한 후 When(조건)에서 Priority 선택 및 `has any value of`를 선택하고 `Major` 와 `Critical` 두 개 값을 선택해 주겠습니다.
그 이후 Available Choices에서 All users 선택 및 Default Value에는 `Use specified default value`를 선택하고 `Literal value`에는 관리자 레벨의 유저를 선택해 주겠습니다.
옆 옵션인 `Applicable Projects`에 특정 프로젝트들을 지정해주면, 해당 프로젝트들만 default로 `Literal value`에 적힌 유저가 자동 할당 되게 됩니다.
마지막 옵션인 `Applicable Projects`도 특정 프로젝트들을 지정해주는 옵션인데, 지정한 프로젝트들만 해당 field가 활성화 되어 보여지게 됩니다.
위 2개의 `Applicable Projects`는 공란으로 두면 default로 모든 프로젝트에서 활성화가 됩니다. 마지막으로 Save를 눌러서 저장하겠습니다.
이렇게 해서 하나의 커스텀 field를 만들어 봤으며, 이어서 Issue state 커스텀 설정을 같이 확인해보겠습니다.
2. Issue State등록
Administration -> Issue Settings -> State 탭으로 진입해주겠습니다.
GitOn에 등록된 모든 state를 확인할 수 있으며, + 버튼을 통해서 state 등록이 가능합니다. State는 단순하게 Name과 Description 그리고 Color(state의 색상)로 이루어져 있습니다. 여기서는 `PR Review` 라는 state를 하나 생성해주도록 하겠습니다.
다음으로는 Issue의 State Transition설정에서 기존에 만들어 둔 state들의 From -> To 설정으로 어떠한 state에서 어떠한 state로 이전할 수 있는지 정의하는 state transition 커스텀 설정을 해보겠습니다.
3. Issue Transition등록
Administration -> Issue Settings -> State Transition 탭으로 진입해주겠습니다.
State 의 From -> To 상태 이전 설정이 여기에서 전부 정의되어 있는 것을 확인할 수 있으며, + 버튼을 눌러보면 다양한 Type을 지원하고 있는 점을 확인할 수 있습니다.
여기서 정의할 내용은 두 가지 입니다.
- Issue가 Open 혹은 In Progress 상태에서 PR Review상태로 이전을 하는데, Pull Request가 새로 열렸을 때만 Open/In Progress -> PR Review 상태로 자동이전이 되게 하는 설정
- Issue가 PR Review상태에서 Closed 상태로 이전을 하는데, Pull Request가 Merge 상태로 전환되었을 때만 PR Review -> Closed상태로 자동이전 되게 하는 설정
먼저 1번 케이스에 대한 설정을 만들어 보겠습니다.
Type을 `Pull request is opened` 로 지정해주고 From States에 `Open`, `In Progress` state 값을 선택합니다. To State에는 `PR Review` state값을 선택해주겠습니다.
`Target Branches` 에는 공란으로 두면 모든 Branch에 적용한다는 의미입니다. `Applicable Issues` 에는 어떤 이슈를 적용하냐는 뜻인데, `fixed in current pull request`를 넣어주겠습니다. `fixed in current pull request` 의 뜻은 Source branch에는 있지만 Target branch에서 없는 미해결 commit과 레퍼런스가 걸린 모든 이슈들이 일치한다는 의미인데, 해당하는 이슈들은 `fix #issue-number`와 같이 commit message fix patterns(issue settings에서 정의 되어있음)을 이용해 issue와 commit간 레퍼런스가 걸려있어야 합니다.
`Remove Fields`는 해당 상태이전이 작동하면 어떤 field 를 지울지에 대해 지정하는 설정인데, 따로 field 를 지울 필요는 없으니 공란으로 놔두고 Save를 하겠습니다.
이어서 2번 케이스에 대한 설정을 만들어 보겠습니다.
Type을 `Pull request is merged` 로 지정해주고 From States에 `PR Review` state 값을 선택합니다. To State에는 `Closed` state 값을 선택해주겠습니다.
`Target Branches`, `Applicable Issues`, `Remove Fields` 설정은 이전 했던 설정과 동일하게 지정하여 Save를 하겠습니다.
이로서 Issue management에서의 custom 설정을 완료하였습니다.
4. Issue 생성
이전 블로그에서 데모를 진행했던 NodeJS 기반의 웹/앱 프로젝트에서 issue생성을 진행해보겠습니다.
좌측 사이드 메뉴의 Issues -> List탭으로 진입하여 + 버튼을 클릭한 후 Title 및 Description을 적어주겠습니다.
하단에 Custom Field가 다양하게 표시되는데, Type을 `Task`로 선택하고 Priority를 `Major`로 지정을 해줍니다. 이때 하단의 관리자라는 field가 표시되게 되고 자동으로 관리자 레벨의 유저가 해당 field에 할당되게 됩니다. (이전에 만들어둔 관리자 field 입니다.) 나머지 Mandatory field값은 알아서 채워 넣은 후 Save를 진행하겠습니다.
관리자 field에 할당된 사용자에게는 위와 같이 mail 알림이 가게 되어있어서 중요한 이슈에 대한 알림을 지속적으로 받을 수 있게 됩니다. 더 나아가서 Webhook을 통해 Slack이나 Mattermost와 같은 팀 협업 기반의 메신저 플랫폼을 사용하면, 채널을 통해 Issue, pull request, build, push, comment와 같은 event에 대해서 지속적으로 알림을 받을 수도 있습니다.
위는 Mattermost에서 webhook을 통해 event들에 대한 notification을 받은 예시입니다.
5. Branch 생성 및 소스 수정 과 함께 Commit 생성
이제 생성된 이슈에 대한 작업을 진행하기 위해 웹 소스파일을 수정하고 `task-1`이라는 child branch를 만들어 수정내용을 반영 해보겠습니다.
편의를 위해 개발 환경이 아닌 GitOn 웹에서 직접 소스코드를 수정해보도록 하겠습니다.
참고로 이슈 우측 하단의 Reference Id를 복사했다가 commit을 할 때 코멘트로 입력해줘야 issue와 commit간 레퍼런스가 걸리기 때문에 복사를 해두도록 하겠습니다.
좌측 하단 메뉴에서 Code -> Branches 메뉴로 진입하여 + 버튼을 통해 `task-1` 이라는 child branch를 만들어줍니다. (이때 Revision을 master로 지정해주겠습니다.)
다시 Code -> Files탭으로 진입 후 branch를 방금 생성한 `task-1` branch로 전환을 한 후 웹 소스코드 파일을 열어서 logo image url을 넣은 후 Save를 해줍니다.
이때 Commit message를 적을 수 있는데 issue의 reference Id를 복사한 후 `Fix for (<reference Id>)` 형태로 메세지를 적은 후 Save를 해줍니다.
GitOn웹 에디터에서 직접 Commit을 진행하면 따로 Push절차 없이 remote branch에 내용이 반영 됩니다. 다시 Issue 페이지로 돌아오면 방금 진행한 Commit이 Issue에 Reference가 걸린 것을 확인할 수 있습니다.
6. Pull Request
GitOn : Agent 등록부터 CI/CD 파이프라인 배포까지에서 소개해드린 GitOn에서 CI/CD 파이프라인 구성을 미리 진행 해보셨다면, `task-1` branch에 코드 수정 내용이 업데이트 되어 CI/CD 파이프라인에 Trigger가 걸려서 자동으로 Job이 수행 되는 것도 확인이 가능합니다.
CI/CD 파이프라인 과정이 잘 끝나서 Pass했다는 가정하에 마지막 단계를 진행하겠습니다. `task-1` branch에서 빌드 및 테스트도 잘 끝났다는 가정하에, 이제 master branch로 merge를 진행해야 하는데요, 이때 GitOn과 같은 Git기반 소스코드 관리 협업 플랫폼에서는 Pull Request 혹은 Merge Request라는 용어로 branch간에 병합 요청을 할 수 있게 메뉴를 제공하고 있습니다.
Pull Request를 통해 Project(Repository)의 특정 멤버들을 reviewers로 지정 후 해당되는 모든 멤버들이 code review 후에 승인을 해줘야 Assignees로 지정된 project 관리자 혹은 Code Writer권한을 가진 멤버가 merge request를 최종 승인 후 merge가 완료됩니다.
`task-1` branch의 내용을 `master` branch로 merge하기 위해 pull request를 진행할건데,이때 reviewers 및 Assignees를 한 명씩 지정해서 최종 merge까지 진행을 해보겠습니다. 이때 Pull request가 Open 되었을 때와 Merge되었을 때 Issue의 state도 자동으로 전이 되는 것도 같이 확인할 수 있습니다.
좌측 하단의 Pull Requests 메뉴에서 + 버튼을 통해 새로운 Pull request를 생성할 수 있습니다. 이때 Source부분에서 변경내용이 있는 `task-1` branch 를 선택하고 Target에서는 `master` branch를 선택한 후 제목 및 내용을 알맞게 채워 주시고 Reviewers에서 특정 멤버 선택 및 Assignees를 지정 후 Send Pull Request를 눌러주겠습니다. (이때 제일하단에 해당 Pull Request에 반영될 Commit 리스트를 확인하실 수 있습니다.)
Pull Request가 열렸고 Issue로 다시 되돌아가면 Issue의 state가 Open -> PR Review상태로 자동으로 상태이전이 되어 있는 것을 확인할 수 있습니다.
Reviewer로 등록된 멤버가 PR이 생성되어 있는 것을 확인 후에 Approve(Code Review를 했다고 가정함)를 진행합니다. 이후 Assignees로 지정된 프로젝트 관리자 혹은 Code Writer 권한이 있는 멤버에게 최종 Merge 버튼이 활성화되고, 최종 점검을 통해 Merge를 진행합니다.
이로서 `master` branch로 `task-1` 변경 내용이 merge가 잘 되었으며, 다시 Issue페이지로 돌아오면 PR Review -> Closed 상태로 Issue의 state가 자동 이전이 되어 있는 것을 확인할 수 있습니다. CI/CD 파이프라인을 통해 `master` branch에서도 업데이트가 생겼기 때문에 Trigger로 인해 자동으로 Job이 수행되어 웹/앱의 최종 재배포까지 진행이 되었습니다.
7. 마치는말
이렇게 해서 GitOn을 활용한 Issue Management 및 Pull Request 기반 팀 협업 워크플로를 살펴보았습니다. 만약 GitHub나 GitLab 같은 플랫폼을 사용해본 경험이 있으시다면, 본 글에서 설명한 GitOn의 높은 커스터마이징 자유도, 빠른 성능, 그리고 편리한 CI/CD 파이프라인 구성이 차별화된 강점으로 느껴지셨을 것입니다.
GitOn은 Docker, k8s, Bare Metal/VM(script) 설치를 지원하여 쉽고 빠른 설치가 가능하며, 위에서 소개 드린 내용 이외에도 Role management, Backup, HA, Rest API 지원, 보안 등을 지원하고 있어 소규모 프로젝트부터 대규모 Enterprise 환경까지도 충분히 사내 구축 및 안전성 있는 운영이 가능합니다.
현재 사내에서 Git 관리 플랫폼을 고민하고 계시거나 기존 플랫폼의 한계를 느껴 마이그레이션을 고려하고 계신다면, GitOn이 최적의 솔루션이 될 수 있을 것입니다. 높은 커스터마이징 자유도와 안정성을 갖춘 GitOn은 소규모 프로젝트부터 엔터프라이즈 환경까지 다양한 요구를 충족하며, 팀의 협업과 생산성을 혁신적으로 향상시킬 수 있습니다.
지금 바로 GitOn의 강력한 커스터마이징 기능과 안정적인 성능을 직접 경험하고, 팀에 최적화된 플랫폼을 선택해보세요.
