■ 배경

현재 회사는 개발서버가 2중으로 구성되어 있었습니다.

파트 내에서 개발 시작되는 환경은 GitLab과 Jenkins가 호스팅되어 있는 온프레미스 구조로 구성되어 있고 1차 서버에서 2차 개발서버로 미러링 및 배포가 이뤄집니다.

2차 개발서버는 여러 팀에서 참조하고있는데 간헐적으로 1차 개발서버에 장애가 발생하는 문제가 있었습니다. 이러한 장애는 개발, 테스트, 이행 일정에 차질을 초래하여, 팀의 업무 효율성을 저해했습니다.

이러한 문제를 해결하기 위해, 저는 백업 체계를 구축하기로 결심했습니다.

그 과정을 gitLab 미러링 방법을 공유하고자 합니다.

■ GitLab 미러링

1. 백업 gitlab에 소스를 받을 타겟 프로젝트를 생성

생략...

2. 백업 gitlab에 인증을 위한 access token을 생성(선택이며 token이 아닌 로그인 비밀번호를 사용해도 됨)

access token은 해당 메뉴에서 생성할 수 있다.

하나의 프로젝트가 아닌 상위 그룹 하위에 있는 모든 프로젝트에 동일하게 적용하고싶다면, 그룹 settings로 들어가서 access token을 생성하면 된다.

role의 경우, 미러링(push)를 하고자 하는 브랜치의 권한 이상의 권한을 설정한다.

예를들어 미러링을 받을 타겟 프로젝트 main 브랜치의 push 권한이 Maintainer이고 access token의 권한이 Developer로 되어있다면, 해당 브랜치에 push를 할 수 없어서 미러링을 할 수 없다.

(권한은 Owner가 가장 높고 Guest가 가장 낮다.)

3. 원본 gitlab에서 미러링을 설정

프로젝트 > Settings > Repository > Mirroing repositories

Git repository URL에는 목적지의 "http(s)://계정@git주소" 를 적어준다.

예를들어 나의 경우, 폐쇄망에서 구현한 백업 gitlab 프로젝트가 목적지이다.

해당 프로젝트의 주소가 http://10.25.111.222/mygroup/my-proj.git 이고 해당 프로젝트의 권한을 가지고 있는 계정의 정보가 admin 일 경우, http://admin@10.25.111.222/mygroup/my-proj.git 이 되겠다.

password에는 admin 계정의 gitlab 로그인 비밀번호 혹은 생성한 access token을 입력한다.

Mirror only protected branches 를 선택하면 protected branches로 설정한 branch들만 mirroring할 수 있다.

(여러 개발자가 같이 개발을하면 자연스럽게 다양한 feature 브랜치가 생성될텐데 이 모든 브랜치를 가져갈 필요가 없으므로 주요 브랜치만 가져갈 것이라면 protected로 설정해 놓고 선택해주면 좋다.)

protected branches 설정은 Mirroring repositories 바로 아래에서 확인 가능하다.

실제 미러링이 설정이 완료되면 위와 같이 row하나가 생긴다. 나 처럼 여러개의 미러링을 구축할 수 있다.

실제 설정한 브랜치의 변화(commit)이 생기면 자동으로 미러링(현재 설정은 push)가 진행된다.

수동으로 직접 미러링을 시키고 싶다면 오른쪽에 새로고림 아이콘을 클릭해줘도 된다.

d최신 운영 중인 앱에서 특정 메서드를 호출하다 장애가 났었다.

일부 서비스에서 사용이 불가능한 메서드가 있었는데, 환경이 분산되고 복잡하다보니 개발자가 테스트를 놓친 케이스였었다.

이 부분을 개선하고 비슷한 장애를 예방하기 위해서 pre commit rule을 추가해서 특정 키워드가 소스에 추가되면 안내를 위한 팝업을 띄우게 했다. 

🤖 환경

개발팀의 환경은 Mac을 사용하고 있고 Husky plugin이 설치되어 있었다.

git은 개발자가 commit을 수행하면, commit 이 수행되기 전에 스크립트를 실행되게끔하는 pre-commit 기능을 제공한다.

방법은 프로젝트의 .git/ 하위에  "pre-commit"스크립트를 작성하면 된다.

하지만, git에서 제공하는 pre-commit의 경우, 개인 로컬에만 적용되고 remote 환경을 이용해서 개발자들이 바로 적용하게할 수는 없었다.

https://www.npmjs.com/package/husky

husky를 이용하면, pre-commit을 작성하고 배포할 수 있다는 장점이 있어서 이용하기로 이를 활용하기로 했다.

🍎 Mac 팝업 띄위기(osascript)

mac os의 경우, 애플에서 제공하는 osascript를 이용해서 알람이나 팝업을 띄울 수 있다.

$ osascript -e 'display dialog  "팝업 창 메세제"'

팝업 창 띄우기

$ osascript -e 'display dialog  "팝업 창 메세제" buttons{"커스텀 버튼"}'

이렇게 버튼을 커스텀할 수도 있다.

$ osascript -e 'set keyword to "키워드"' -e 'display dialog keyword & "를 사용" buttons{"커스텀 버튼"}'

set 예약어를 사용해서 변수를 지정할 수도 있다

위 소스는 keyword 라는 변수에 "키워드"라는 문자열을 할당한 후, display dialog 예약어로 팝업 창을 띄웠다.

🔍 Git diff로 수정한 소스의 키워드 추가 확인하기

git 프로젝트에 git diff를 사용하면 소스의 변화를 확인할 수 있다.

이때, 추가된 line은 +가 삭제된 line은 -가 맨 앞에 붙어있다.

이를 활용하면, 특정 키워드가 소스에 추가되었는지 확인이 가능하다.

$ git diff --cached | grep -q "^\+.*${KEYWORD}"

--cached 옵션은 스태이징 상태(add 후)를 확인하고 grep의 -q 옵션은 존재하는지 true / false 결과만 return하게 해준다.

-q 옵션을 제외하면, 해당 line을 터미널에 출력 해준다.

이를 활용하면 commit 시 특정 키워드를 확인해서 동작하는 pre-commit을 만들 수 있다.

#!/usr/bin/env sh

KEYWORD="eval"

if git diff --cached | grep -q "^\+.*${KEYWORD}"; then
        response=$(osascript -e 'set KW to "$KEYWORD"' -e 'display dialog KW & "를 추가하셨습니다." buttons{"확인"}')
fi

exit 0

이로써, 자칫 개발자들이 놓칠 수 있는 부분을 한번 더 챙겨서 장애 예방에 도움이될 수 있지 않을까 싶다.

참고로 husky를 활용해서 수정한 소스를 remote 환경에 올려두면, 개발자들이 pull해갈 수 있지만, .git/pre-commit을 작성해야한다면, 소스를 개발자들에게 전파해서 직접 로컬 환경에 적용시키게 하거나 한 사람이 pre-commit 파일을 remote에 올리고 해당 파일을 직접 적용시켜주는 스크립트 등을 만들어서 개발자들은 소스를 pull 받고 스크립트만 실행하면 적용될 수 있게 해줘야할 것 같다.

내 경우는 일부 repo의 경우 husky가 존재하지 않아서 후자의 방법으로 pre-commit을 적용시킬 수 있는 스크립트를 만들어서 제공했다.

팀으로 진행되었던 프로젝트에서 자신의 브랜치 가져올 때, 사용하기 좋습니다.

📝 특정 branch clone하기

git clone -b [브랜치 이름] --single-branch [리포지토리 주소]

리포지토리 주소는 HTTPS, SSH 주소 모두 가능 합니다.

예시

git clone -b space_jin --single-branch https://github.com/space-team/toy-proj

space-team 깃헙의 toy-proj 리포지토리의 space_jin 브랜치만 클론 합니다.