[Git] GitLab

lssue

• 다른 개발자들과 협업을 하기 위한 기능

Issue Label

• Label 종료
  • 타입 - 버그, 기능개선, 신기능, 논의사항 등
  • 상태 - New, In Progress, In Review, Done 등
  • 카테고리 - Front-end, Back-end, UI 등
• Issue의 그룹화
• Issue의 플랫폼, 의존성 등 부가적인 내용 표기
• Issue의 상태 관리
• 본인의 Issue를 손쉽게 검색

Milestone

• 프로젝트의 이슈를 관리하기 위해 사용
• 이슈를 Milestone으로 묶을 수 있음
• Milestone을 사용하면 Issue들의 진척도를 확인하기 수월해짐

MR

• 다른 브랜치의 변경 사항을 반영하기 위한 요청
• 새로운 코드를 추가하여 브랜치에 반영(병합/Merge)하고자 함, 병합(Merge)을 요청(Request) 함

→ 브랜치 생성 - 커밋 - Gitlab으로 브랜치 푸시 - Merge Request

MR 하는 이유

1. 코드 리뷰
2. Master 브랜치의 안정성 유지
3. 보안

Merge Request

• Source Branch : 병합의 소스가 되는 Branch(작업 Branch)
• Target Branch : 작업된 코드가 추가될 Branch(대상 Branch)

이슈와 MR을 연동하는 방법

• 이슈 페이지에서 MR / 브랜치를 생성함

Merge

• MR의 Merge 조건은 자유롭게 설정할 수 있으나 그래야만 하는 것은 아님
• 최소 Approver 수와 특정 사람의 승인을 Merge 조건으로 걸 수 있음 → 가장 알맞은 것

MR의 Merge

• Merge 이후에는 소스 브랜치의 변경사항이 타겟 브랜치로 병합됨

CI(CI-Continuos Integration)

• 새로운 코드에 대한 변경사항이 꾸준히 자동으로 빌드 및 테스트되어 여러 개발자가 동시에 작업할 때 인터럽트가 발생하는 것을 방지할 수 있음
• 안정성 유지 및 시간 절약
• 코드 작성에만 집중 가능
• 분업과 협업을 효율적으로 할 수 있음
• 변경사항을 효율적으로 관리할 수는 없음

CI 하지 않고 빌드하기

• CI/CD가 없을 때

• CI/CD가 있을 때

npm install express
npm install --save-dev mocha should supertest

# npm test
npm test

# Heroku 배포
npm install -g heroku
heroku login
heroku create
git push heroku master

# 배포 확인 -> 웹사이트
still-meadow-28490.herokuapp.com

.gitlab-ci.yml

• CI 기능에 대한 구성/설정을 저장하여 관리

# CI로 자동화 시키기
image: node:latest

stages:
	- test

cache:
	paths:
		- node_modules/

testing:
	stage: test
	script:
		- npm instsall
		- npm test

• 프로젝트에 CI 적용

Stage

• 앞 Stage가 끝나야 다음 Stage가 실행됨
• 단계별로 실행될 스크립트를 자유롭게 설정할 수 있음
• 특정 브랜치에서만 실행되도록 설정할 수 있음
• only : 특정 브랜치에서만 Stage가 작동되도록 하기 위해 주는 옵션

MR에 CI를 연동하는 방법

• 프로젝트의 MR 설정에서 pipeline이 성공되어야 하게 설정함

Wiki

• 프로젝트에 대한 설명/안내 등을 문서로 마크다운으로 작성해서 관리할 수 있는 기능

Gitlab의 Member

• 서브 그룹과 프로젝트는 상위 그룹의 멤버를 상속함
• 그룹을 한 번에 초대할 때 Max Access Level을 넘지 못함
• 그룹 아래에 추가적으로 서브 그룹을 계속 생성할 수 있음
• 권한이 많은 순서대로 Guest - Reporter - Developer - Maintainer - Owner

Lint

• Lint에서 발생한 에러는 고치지 않아도 실행에 지장이 없음
• Lint에서 잡힌 자잘한 수정사항들을 고치지 않고 두면 기술부채가 되어 돌아옴
• Lint 과정을 거침으로서 코드의 질을 향상시킬 수 있음
• Lint는 무조건 빌드 전에 실행해야하는 것은 아님

Gitlab의 통계

• MR이 생성되고 Merge/Close 되기까지 걸린 평균 시간
• 커밋별 CI/CD에 걸린 시간
• CI/CD 실행 추세 및 pass된 수

Error Tracking

• 배포된 서비스에서 발생하는 Error에 대한 정보를 추적하기 위해 Gitlab에서 제공하는 기능

Environment

• 배포 환경을 관리하기 위해 Gitlab에서 제공하는 기능

Feature Flags

• 서비스의 기능을 깃랩에서 on/off 하고 싶을 때 사용하는 기능