[GitLab]소스코드 관리, GitLab으로 완벽 해결하기

보통 여러 인원과 함께 프로젝트를 진행할때, 구성원간 유기적이고 신뢰성있게 코드를 관리하는것은 매우 중요하다.

오늘은 gitlab을 활용해서 손쉽게 코드 및 업데이트 내용을 관리하고, 소스코드의 히스토리를 확인, 공유할 수 있는 협업 방식에 대해

포스팅해보려 한다.

 

 

 

먼저, Git과 GitLab에 대해서 간단히 알아보자.

Git이란?

git 은 소스 코드 버전 관리 시스템으로 로컬에서 변경 사항을 추적하고 원격 리소스에서 변경 사항을 푸시하거나 가져올 수 있다.

 

 

 

GitLab 이란?

GitLab은 깃 저장소 및 CI/CD, 이슈 추적, 보안성 테스트 등의 기능을 갖춘 웹 기반의 데브옵스 플랫폼으로 개인 또는 조직이 Git repository 의 내부 관리를 제공하는데 상용할 수 있는 Github 으로 즉 비공개된 Github라고 할 수 있다.

실무에서는 7:3정도로 github보다 Gitlab이 많이 사용된다고 한다.

 

 

본론으로 들어가서, 보통 프로젝트를 진행할때 함께 진행하는 구성원과 코드관리에 있어 몇몇 문제들이 발생할때가 있는데,

1) 커밋하고나서 머지하려고 보니, 충돌나는 경우
2) 서로 같은 로직을 이중개발하는 경우(코드 또는 개발내용에 대한 공유가 잘 이뤄지지 않은 경우)
3) 서로 합의되지않은 코드가 배포되는 경우(문제가 발생할 소지가 있는 코드가 포함되었지만 cross check가 되지않은 경우)
4) 서로의 개발내용(코드)에 대해 이해도가 낮아, 퇴사자 발생 시, 인수인계가 힘들어지는 경우

이와 같이, 소스 관리의 시스템이 갖춰지지 않을 경우 발생할 수 있는 문제는 정말 많다.

 

 

 

그럼 이제 서로 소스코드를 공유하고, 이력관리 및 업데이트 내용에 대한 구성원들간의 합의를 이룰수있는

깔끔한 GitLab 활용 방법을 알아보자.

 

1) 먼저, 구성원들의 개발 내용들은 모두 별개의 Branch로 관리되어야 한다.

여러 구성원과 함께 진행되는 프로젝트의 경우 서로간의 소스코드가 충돌하거나 영향을 미칠 수 있다.

그렇기 때문에, 각자의 개발 내용은 별도의 브랜치로 관리되어야하는데,

이는, 문제가 발생할 경우, 관련 branch의 수정 내용에 대해서만 확인하면 손쉽게 해결이 가능하고, 문제가 클 경우

빠르게 이전 환경으로 rollback하는 등 빠른 대처가 가능해지기 때문이다.

따라서, 각 개발내용을 별도의 브랜치에서 독립적으로 관리하는것이 반드시 필요하다.

 

아래는 프로젝트에 참여하는 구성원들이 목적에 맞게 branch를 관리하고,

GitLab의 merge request를 통해 소스코드 검증체계를 갖추었을때의 업무 프로세스이다.

 

1. 유재석 사원이 페이지 조회 기능을 개발했을때 -> 'feature/search' 라는 이름으로 Branch를 만들어 관리한다.
2. 박명수 대리가 파일 삭제 오류를 수정했을때 -> 'issue/file_delete_error' 라는 이름으로 Branch를 만들어 관리한다.
3. 유재석 사원과 박명수 대리는 각각 테스트를 완료한 후 -> 'dev'라는 개발서버로 merge requests한다.
4. 정준하 팀장은 'dev'에 등록된 merge request 내용을 확인하고, 필요한 부분에 대해 comment를 남김으로써 소스의 문제점을 수정하도록 지시한다.
5. 확인이 완료된 개발서버 소스에 대한 배포를 진행한다.
6. 개발서버에 배포된 내용에 대한 테스트가 완료되면 -> 'master' 라는 운영서버로 merge requests 한다.
7. 마찬가지로, master에 등록된 merge request 내용에 문제가 없을 경우 운영서버 배포를 진행한다.

<branch 생성 방법>

 

위와 같이 branch명 앞쪽에 작업한 내용에 대해 간단히 기재할 경우, 좀 더 작업물에 대한 빠른 파악에 용이하다. 

작업물 성격(Type)은 아래와 같이 요약되어 사용되는 경우가 많으니 참고하자.

 

 

이제, 위 과정들에 대해서 조금 더 자세히 알아보자.

 

 

 

먼저, 특정 브랜치의 작업이 완료되었고, 해당 내용을 운영서버에 배포한다고 가정하자.

이때, GitLab에는 merge한 내용을 구성원들에게 공유하고,

소스코드를 상호 검증할 수 있는 기능(관리방식)이 있는데, 이것을 'merge requests'라고 한다.

 

해당 프로젝트의 책임자 또는 배포 담당자에게 merge request를 등록함으로써, 작업 결과물을 투명하게 공유하고, 

동시에 배포 내용에 대한 상호 검증 기능을 하게 된다.

예를들어, 해당 Merge Requests건에 대해서 과반 이상의 구성원 동의를 받았을 경우에만 배포를 진행하도록 시스템을 구축한다면,

업데이트 과정에 강력한 안전장치가 될 수 있을 것이다.

2) master에서 git을 merge한 후 해당 프로젝트의 GitLab 화면에서 [Merge Requests]를 선택한다.

 

Merge Requests를 선택한 화면에서 [open], [Merged], [Closed], [All] Tab을 확인할 수 있고, 클릭할 경우, 상태별 Merge Reqeusts 내용을 확인할 수 있다.

3) [New Merge requests]를 선택한다.

 

4) 그리고, Source Branch와 Target Branch에서 각각, 작업한 소스 브랜치와 배포할 타겟 브랜치를 선택한다.

 

5) 마지막으로, 해당 Merge Requests에 대한 담당자와 상세 내용을 기재한다. 

여기서, 모든 작업물에 대해서 별도의 브랜치를 생성할 경우, 매우 많은 브랜치가 생성되고 merge이후에 완료된 브랜치는 추후 삭제를 진행하는 작업을 해야할 수 있는데, 이것에 대한 삭제 옵션 기능을 제공하고있다.

Merge Requests 화면 하단의 "Remove source branch when merge request is accepted"라는 옵션을 선택할 경우 머지가 확정된 이후 해당 merge requests에 포함된 브랜치는 모두 삭제된다.

 

 

해당 프로젝트가 공유된 구성원들은 해당 Merge requests내용을 확인할 수 있으며,

아래와 같이 수정 반영된 소스코드에 대해 의견을 남기게 된다.

 

만약 구성원 중 과반(제안)이상의 인원이 해당 요청에 대하여 동의(위로 엄지)한다면, 충분히 검증된 내용으로 판단하여

담당자가 Master merge를 검토할 수가 있다.

오늘은 GitLab을 이용한 소스코드 관리 및 공유 시스템에 대해서 정리해보았다.

 

-> 위 내용을 간단히 정리해보면,

먼저 GitLab의 Merge request기능을 통해 멤버들은 서로의 코드 내용에 대해 공유할 수 있기때문에, 코드의 충돌을 방지하고, 공통소스를 공유하여 사용할 수 있다.

그리고, 배포 결정에 있어 신뢰성과 안정성을 가질 수 있기 때문에, 매우 유용한 프로세스로 활용될 수 있다.