[DevOps] CI/CD & 형상관리의 기초 + GIT 커밋 메시지 규칙.
▽ [DevOps] CI/CD & 형상관리의 기초 + GIT 커밋 메시지 규칙.
목 차
1. CI/CD 개념 정리
2. GIT 기반 형상 관리 실무
3. GIT 커밋 메시지 규칙.
면접을 다녀왔는데, 형상관리나 커밋메시지를 너무 실무와 동떨어지게(?) 제멋대로 하고 있는 것 같아서 한번 제대로 짚고 넘어가보려고 정리합니다.
1. CI/CD 개념 정리.
1-1. CI (Continuous Integration)
정의.
- 개발자들이 개발 과정에서 작성한 코드를 자주(하루에 수차례)
중앙 저장소에 통합(merge)하는 프로세스.
핵심 목적.
-
코드 통합 주기를 짧게 유지.
-
빌드/테스트 자동화 -> 버그 조기 발견
-
팀원 간 작업 충돌 최소화.
주요 요소.
-
자동 빌드.
-
자동 단위/통합 테스트
-
코드 품질 검사 ( ex : SonarQube )
대표적인 툴 .
-
Jenkins
- 무료
- 다양한 플러그인, IDE 지원
- 많은 사용자와 많은 문서
- 규모가 작은 프로젝트의 경우 설정하는데 리소스 낭비가 발생 가능
- 지라와 연동이 불편하거나 완벽하지 않을 수 있음.
-
GitHub Actions
- 복잡한 과정없이 바로 깃허브에서 사용 가능
- 빌드 과정을 눈으로 확인하기 쉬움
- 깃허브의 모든 이벤트에 대한 작업을 제공하고 다양한 언어와 프레임워크를 지원
- 젠킨스보다 빠름
- Public은 무료, Private 저장소의 경우 매월 3000분 무료
- 문서가 비교적 부족
- UI에서 개별 워크플로우 실행을 삭제 불가
- 워크플로우에서 단일 작업만 다시 실행시킬 수 있음
-
GitLab CI/CD
-
CircleCI
-
Travis CI
- 깃허브와 연동
- 빌드 과정을 한 눈에 이해하기 쉽다
- 초기 설정이 젠킨스에 비해 간편(YML 파일을 통한 설정)
- 별도의 서버 필요 없음. Travis에서 알아서 VM으로 호스팅
- 기업용은 좀 비쌈
- 로컬에서 CI환경과 동일한 빌드환경을 제공하지 않는다
- 젠킨스에 비해 플러그인이 다양하지 않음
- .travis.yml 파일을 수정하고 테스트하려면 git push를 반복해야 함.
Best Practice
- 하루 최소 1회 커밋 → 파이프라인 돌려보기
- 실패한 빌드는 즉시 수정
1-2. CD (Continuous Delivery / Continuous Deployment)
둘 다 CI 이후의 과정을 다루지만, '배포의 주체'가 다릅니다.
| 구분 | Continuous Delivery | Continuous Deployment |
|---|---|---|
| 배포 방식 | 수동 승인 후 배포 | 자동으로 배포 |
| 배포 빈도 | 주로 수일~수주 단위 | 수분~수시간 단위 가능 |
| 사용 환경 | 금융, 의료 등 규제 많을 때 | 서비스가 빈번히 변경되어야 할 때 |
-
주요 작업.
- 스테이징 환경에 자동 배포
- 자동화된 E2E 테스트
- 승인 프로세스 ( Delivery일 때 )
- 프로덕션 자동 배포 ( Deployment일 때 )
Best Practice
파이프라인 단계별로 Rollback 전략 포함
배포 전 Smoke Test 필수
1-3. CI/CD Pipeline 구조.
-
CI/CD 파이프라인은 사용자에게 새 버전(최신 버전)의 소프트웨어를 제공하기 위해 수행해야 하는 단계입니다.
-
{ 빌드 - 테스트 - 릴리즈 - 배포 } 등으로 이루어진 단계.
-
DevOps 또는 SRE 방식으로 더 효과적이게 소프트웨어를 제공하는 데에 초점을 맞추고 있습니다.
-
CI/CD 파이프라이은 특히 통합 및 테스트 단계와 제공 및 배포 단계에서 "모니터링 및 자동화를 도입"하여 애플리케이션 개발 프로세스를 개선합니다.
-
CI/CD 파이프라인의 각 단계를 수동으로 실행할 수 도 있지만, CI/CD 파이프라인을 자동화 할 때 진정한 DevOps라고 할 수 있습니다.
CI/CD 파이프라인의 요소.
-
CI/CD 파이프라인의 단계는 각기 다른 테스크 하위 집단으로 이루어져 있는데,
이를 파이프라인 단계(pipeline stage)라고 부릅니다. -
일반적인 파이프라인 단계는 다음과 같습니다.
- 빌드(Build) : 애플리케이션을 컴파일하는 단계.
- 테스트(Test) : 코드를 테스트하는 단계 / 이 단계를 자동화하여 시간과 수고를 줄일 수 있습니다.
- 릴리즈(Release) : 애플리케이션을 리포지토리에 제공하는 단계
- GIT과 같은 리포지토리에 릴리즈합니다.
- 배포(Deploy) : 코드를 프로덕션에 배포하는 단계.
- 검증 및 컴플라이언스(Validation & compliance ) : 빌드 검증 단계는 해당 조직의 필요에 따라서 결정됩니다.
실제 파이프라인 예시.
# Step 1
Checkout → Prettier / ESLint
↓
# Step 2
Build (Gradle / npm build / docker build)
↓
# Step 3
Unit Test
↓
# Step 4
Static Analysis (SonarQube, CodeQL)
↓
# Step 5
Integration Test / e2e Test
↓
# Step 6
Artifact 생성 → Repository 업로드
↓
# Step 7
Deploy to staging
↓
# Step 8
Manual Approval
↓
# Step 9
Deploy to production
↓
# Step 10
Smoke Test → Monitoring
2. GIT 기반 형상 관리 실무.
2-1. 기본 개념.
형상 관리( Configuration Management )
-
소스 코드, 문서, 설정 파일 등 모든 개발 산출물의 버전과 변경 이력 관리
-
코드 이력 추적 -> 협업 안정성 확보
Git은 분산형 버전 관리 시스템(DVCS)
-
각 개발자가 로컬 저장소를 가짐
-
중앙 서버(GitHub, GitLab, Bitbucket)와 동기화.
2-2. 실무 Branch 전략
(1) Git Flow
대규모 팀, 릴리스 주기 긴 프로젝트
Hotfix 브랜치 자주 발생
Release 브랜치에서 버그 잡고 QA
- main : 배포용
- develop : 개발 통합
- feature/* : 기능 개발
- release/* : 배포 준비
- hotfix/* : 긴급 수정
git checkout -b feature/login develop
git commit -m "feat: 로그인 기능 구현"
git checkout develop
git merge feature/login
(2) GitHub Flow
스타트업/배포 잦은 서비스
-
main 만 존재(main 단일 브랜치)
-
PR 기반 작업
-
기능 개발은 전부 feature branch에서 진행
-
Pull Request -> 리뷰 -> Merge -> CI/CD 자동 배포.
(3) Trunk-Based Development
배포가 매우 잦은 팀 ( 예 : 수십회 / day 배포 )
- main에 직접 merge(단, 매우 짧은 브랜치 생명 주기 )
- 작은 커밋을 수시로 Merge
- Conflict 빠르게 해결
- Feature Toggle, Dark Launch 활용.
2-3. Pull Request(PR) 절차.
- Feature 브랜치 생성
- 커밋 후 Push
- PR 생성
- Description 충실히 작성
- 변경 목적
- 변경 범위
- 테스트 여부
- Description 충실히 작성
- Reviewer 지정
- 리뷰 -> 피드백 반영
- Approve -> Merge
- 브랜치 삭제.
Best Practice
- Reviewer 최소 2명 이상 권장
- PR 크기 작게 유지 (200~400줄 미만 권장)
- 리뷰 피드백 반영 후 재검토
- Merge 전에 CI 통과 필수
- Merge 기준
- CI 성공
- Approve
추가
-
✅ PR 단위
-
최대 400줄 이내 권장
-
하나의 논리적 변경만 포함
-
-
✅ 코드 리뷰 문화
-
리뷰 체크리스트
-
네이밍
-
사이드 이펙트
-
보안 취약점
-
성능 이슈
-
-
“Approve만 눌러주지 말 것”
-
-
✅ Protected Branch
-
main, develop 강제 보호
-
Force push 금지
-
Approver 지정
-
CI 성공 필수
-
-
-
✅ Tagging 전략
-
vX.Y.Z
-
Major: 기능 대규모 변경
-
Minor: 기능 추가
-
Patch: 버그 수정
-
-
Tag는 배포 기록의 기준점
-
2-4. GIT 명령어 정리
브랜치.
# 새 브랜치 생성
git checkout -b feature/login
# 브랜치 목록
git branch
# 브랜치 삭제
git branch -d feature/login
Commit & Push
git add .
git commit -m "feat: 로그인 기능 구현"
git push origin feature/login
PR 머지
# develop에 feature/login 머지
git checkout develop
git merge feature/login
충돌 해결
git fetch origin
git rebase origin/develop
# conflict 발생 시 파일 수정
git add .
git rebase --continue
-
merge vs rebase
- Merge -> 이력 유지, 커밋 많아짐
- Rebase -> 이력 깔끔, 위험도 ↑
Tagging(릴리스 버전 관리)
git tag v1.0.0
git push origin v1.0.0
Stash
급히 다른 브랜치 작업 시 유용
git stash
git stash list
git stash pop
Bisect(버그 추적)
버그가 언제부터 발생했는지 찾을 때 쓰임
git bisect start
git bisect bad HEAD
git bisect good v1.0.0
# 이분법으로 커밋 추적
Cherry-pick
특정 커밋만 다른 브랜치로 적용
git cherry-pick <commit-hash>
3. GIT 커밋 메시지 규칙(Conventional Commits).
3-1. 커밋 메지지 포멧.
3-2. Type
해당 커밋은 무엇에 대한 작업인지 키워드를 통해 표시합니다.
3-3. Subject.
커밋 메세지의 제목입니다.
- 제목은 50자를 넘기지 않고, 마침표를 붙이지 않습니다.
- 제목에 커밋 타입을 함께 작성합니다.
- 과거 시제를 사용하지 않고 명령조로 작성합니다.
- 제목과 본문은 한 줄 띄워 분리합니다.
- 제목과 첫 글자는 반드시 대문자로 씁니다
- 이슈에 관련된 내용이라면 이슈 번호를 붙입니다.
ex)
Feat: 신규 RFID 인식 기능 추가
3-4. Body.
커밋 메세지의 본문입니다.
- 선택 사항이므로, 모든 커밋에 작성할 필요는 없습니다.
- 한 줄에 72자를 넘기면 안됩니다
- 어떻게(how) 보다 무엇(what), 왜(why)에 집중하여 내용을 작성합니다.
- 설명뿐만 아니라 커밋의 이유를 작성할 때도 작성합니다.
ex)
신규 RFID 기능 인식 기능 추가
- RFIDReader.java: 사용자 요건 사항으로 인한 RFID 인식 기능 추가3-5. Footer.
커밋 메세지의 맺음말입니다.
- 선택 사항이므로 모든 커밋에 작성할 필요는 없습니다.
- 이슈를 추적하기 위한 ID를 추가할 때 사용합니다.
- 해결 - 해결한 이슈 ID
- 관련 - 해당 커밋에 관련된 이슈 ID
- 참고 - 참고할만한 이슈 ID
ex)
해결: #123
관련: #321
참고: #222
커밋 메세지 예시
Feat: 신규 RFID 인식 기능 추가(#123)
신규 RFID 기능 인식 기능 추가
- RFIDReader.java: 사용자 요건 사항으로 인한 RFID 인식 기능 추가
해결: #123
