🌿GitLab Merge Request 하는 법
Github이나 GitLab이나 Git 기반으로 명령어 자체는 크게 다르지 않다.
-
기능별 브랜치 파기:
git checkout -b (브랜치 이름)으로 브랜치를 만들어 작업해준다. -
코드 작성 및 커밋 후 Push: 코드 작성 후 Commit한 다음 원격 저장소로 푸시해준다:
git checkout -b (브랜치 이름)
# 1. 기능 브랜치 생성
git checkout -b feature/test
# 2. 작업
# 3. 커밋
git add .
git commit -m "feat: 테스트 기능 추가"
# 4. 원격 저장소에 Push
git push origin feature/test- Merge Request (MR) 생성: GitLab 웹페이지로 이동하면
Create merge request버튼이 뜨는데.
작업했던 브랜치의 내용을 main 브랜치로 합쳐달라는 MR을 직접 생성해준다.
웹상에서 코드가 어떻게 변경되었는지(Diff) 확인해주면 된다.
Merge(병합) 버튼을 눌러 main에 코드를 반영해주면 된다.
Merge Request가 성공적으로 완료된 화면이다.
⚙️GitLab CI/CD Pipeline 구축하기 (자동 빌드 & 테스트)
코드가 main에 merge되거나 새로운 코드가 push될 때, GitLab이 알아서 프로젝트를 빌드하고 테스트(gradle build)를 돌려주는 파이프라인을 만들어주자
- 프로젝트 최상단 루트에 .gitlab-ci.yml 파일을 생성해준다.
GitLab CI/CD는 이 파일 하나로 주로 움직인다.
기본적인 자바/그레이들(Gradle) 프로젝트용 파이프라인 스크립트를 작성한다.
image: gradle:8.5-jdk17
stages:
- build
- test
variables:
GRADLE_OPTS: "-Dorg.gradle.daemon=false"
before_script:
- export GRADLE_USER_HOME=`pwd`/.gradle
build_job:
stage: build
script:
- gradle assemble
test_job:
stage: test
script:
- gradle test- GitLab에 Push 후 Pipeline 확인하기
위 파일을 작성해서 main 브랜치에 푸시한 뒤, GitLab 메뉴의 Build > Pipelines로 들어가준다.
Build > Pipelines로 접속하여 초록색 불(passed)이 나오면 성공적으로 반영이 되었다는 뜻이며, 자동으로 코드를 빌드하고 테스트를 통과시키는 모습을 확인할 수 있었다.
수동으로 하는 방법:
Build > Pipeline editor으로 들어간다.
Start building 버튼을 누른다.
이런 화면이 나오면 CI/CD 설정 코드(예: gradle 빌드 스크립트 등)을 작성해준 뒤 Commit changes버튼을 눌러준다.
💡 오늘의 느낀 점 및 회고
GitHub만 쓰다가 GitLab의 CI/CD를 처음 설정해 보면서, 설정 파일 하나(.gitlab-ci.yml)만으로 빌드와 테스트가 자동으로 돌아가는 환경이 구축된다는 점이 매우 신기했다. GitHub Actions로 빌드와 테스트를 관리해 본 경험이 있었는데, GitLab에서도 .gitlab-ci.yml 파일 하나로 빌드부터 테스트까지 원스톱으로 자동화되는 과정을 직접 구현해 보니 코드를 푸시하고 검증하는 일련의 자동화 프로세스가 어떻게 맞물려 돌아가는지 느낄 수 있었다.
특히 무료 티어에서 무분별한 악성 스크립트 실행을 막기 위해 계정 인증(카드 등록 등)을 거쳐야 파이프라인이 동작한다는 새로운 사실도 알게 되었다. 툴마다 환경 설정 방식이나 정책이 조금씩 다를 수 있음을 기억해야겠다.
