20250817 TIL - [DevOps & Tools] GitLab, Jenkins, Postman

myo·2025년 8월 17일
CI/CDGitLabTILgitjenkinspostman개발환경디버깅배포형상관리

DevOps & Tools

목록 보기
1/2
post-thumbnail

TIL

GitLab은 협업과 형상관리를 위한 필수 도구이며, Jenkins로 자동배포를 관리하고 Postman으로 API 테스트를 진행한다. BO 배포는 최소화해 위험을 줄인다.

GitLab 형상관리

1. GitLab 형상관리

형상관리란?

형상관리(Configuration Management)는 소스 코드, 문서, 설정 파일 등 프로젝트 산출물의 변경 이력을 추적·관리하는 활동을 말합니다.
Git은 대표적인 형상관리 도구이며, GitLab은 Git을 기반으로 한 협업/형상관리 플랫폼입니다.

형상관리를 잘하면 다음과 같은 장점이 있습니다.

  • 변경 이력 추적 가능 → 언제, 누가, 무엇을 수정했는지 확인 가능
  • 여러 개발자 동시 작업 지원 → 브랜치로 작업 분리 후 병합
  • 이전 버전으로 롤백 가능 → 배포 실패 시 빠른 복구
  • 코드 리뷰, Merge Request, Issue 관리까지 통합 가능

GitLab 주요 기능과 실무 활용

1) Code 탭

  • 프로젝트 소스 코드를 직접 확인
  • 특정 브랜치/커밋 시점의 파일 상태 조회 가능
  • 신규 파일 추가, 수정, 삭제 가능 (단, 실무에서는 대부분 로컬에서 작업 후 Push)

2) Merge Requests (MR)

  • 기능 개발이 끝나면 MR 생성 → 코드 리뷰 후 병합
  • MR 작성 시 포함해야 할 내용:
    • 작업 브랜치
    • 병합 대상 브랜치 (예: develop → main)
    • 변경 요약 및 테스트 방법
    • 관련 이슈 번호
  • 실무 팁:
    • MR은 가능한 한 작은 단위로 올려야 리뷰와 충돌 해결이 쉬움
    • 코드 리뷰 시 불필요한 로직, 하드코딩, 중복 코드 확인

3) Cherry-pick

  • 특정 커밋만 다른 브랜치로 가져올 때 사용
  • 사용 시 주의사항:
    • 적용할 브랜치와 커밋의 코드 베이스 차이가 크면 충돌 발생 가능
    • 커밋 의존성이 있는 경우 반드시 관련 커밋까지 함께 반영
  • 절차:
    1. Commits 탭 → 원하는 커밋 클릭
    2. Options → Cherry-pick
    3. 대상 브랜치 선택 후 반영

4) Repository Graph

  • 브랜치 생성, 병합, 커밋 이력을 시각적으로 확인 가능
  • 병합 누락, 브랜치 꼬임 여부를 파악할 때 유용
  • 실무 팁:
    • 병합 전/후 Repository Graph를 확인하여 불필요한 브랜치나 커밋 중복 여부를 점검

5) 커밋 개수 검증

  • Git Clone 후 커밋 개수가 배포 전 확인했던 개수와 동일해야 함
  • 다르면:
    • 브랜치 누락
    • 병합 실패
    • Push 누락
      → 배포 시 치명적인 누락 발생 가능
  • 확인 방법 (로컬 터미널):
    git log --oneline | wc -l
		```

2. GitLab에서 브랜치 생성 절차

  1. GitLab 웹 UI 접속

  2. 프로젝트 → Code → Branches 탭

  3. New branch 버튼 클릭

  4. 아래 항목 입력:

    • Branch name: 브랜치 전략에 맞춘 이름 (예: feature/coupon)

    • Create from: 어떤 브랜치를 기준으로 만들지 선택 (develop이나 main이 일반적)

  5. Create branch 클릭 → 브랜치 생성 완료

3. 브랜치 전략

  • main → 운영(배포) 브랜치

  • develop → 개발 통합 브랜치

  • feature/* → 기능 단위 개발 브랜치

  • hotfix/* → 운영 긴급 수정

  • release/* → 배포 준비 브랜치

4. Protected Branch

  • 운영 브랜치(main, master)와 통합 브랜치(develop)를 Protected Branch로 지정하면:

    	- 직접 push 불가

	- MR을 통한 코드 리뷰 필수

	- 승인자 최소 인원 설정 가능

  • 배포 사고 방지에 매우 유용

5. 역머지(Reverse Merge)란?

역머지는 체리픽으로 복사된 커밋을 포함한 브랜치를 다시 머지할 때,
이미 반영된 변경사항을 Git이 인식하게 하거나 중복 적용을 방지하는 작업입니다.

실무에서는 다음과 같이 처리합니다.

  • --strategy=ours 옵션을 사용해 Git에게 “내가 현재 브랜치의 내용을 우선시한다”라고 알려줌

  • 또는 충돌 난 부분을 수동으로 해결하여 중복된 코드가 반영되지 않도록 조정

6. 왜 역머지(Reverse Merge)가 필요한가?

체리픽은 커밋 이력을 복사하는 방식이기 때문에, Git 내부에서는 이 커밋들이 서로 연결되어 있지 않습니다.
즉, 같은 내용의 커밋이 서로 다른 커밋 ID로 두 브랜치에 존재하게 됩니다.

같은 내용의 변경이라도 커밋 ID가 다르기 때문에 Git 입장에서는 서로 다른 커밋으로 인식합니다.

문제 상황
1. unity 브랜치에서 버그 픽스 커밋 A 생성

  1. coupon 브랜치에 커밋 A를 체리픽하여 적용

  2. 시간이 지나 unity 브랜치를 coupon에 머지할 때

  3. Git은 커밋 A가 서로 다른 커밋으로 인식 →
    중복된 변경으로 인식하거나 충돌 발생 가능

이 때, 중복 커밋을 해결하고 충돌을 방지하기 위해 역머지(Reverse Merge) 과정이 필요합니다.

Jenkins 배포

1. Jenkins란?

Jenkins는 CI/CD(Continuous Integration / Continuous Deployment) 도구로,
코드 변경 사항을 자동으로 빌드, 테스트, 배포하는 데 사용됩니다.

장점:

  • 자동화로 인한 배포 속도 향상

  • 휴먼 에러 최소화

  • 배포 이력 관리 용이

2. 환경별 주요 컨테이너

  • 개발 환경

    	- ```billi-dev-api-container```

	- ```billi-dev-fo-container```

  • 운영 환경

    	- ```billi-prd-api-container```

	- ```billi-prd-fo-container```

3. Jenkins 배포 절차

  1. Jenkins 접속

  2. 해당 프로젝트 Job 클릭

  3. Build Now 버튼 클릭

  4. 콘솔 로그에서 빌드/배포 진행 상황 확인

  5. 빌드 성공 여부 확인 (성공 시 ✅, 실패 시 ❌)

4. 실무 체크 포인트

  • 빌드 전 GitLab 커밋 개수 확인 (형상관리와 연계)

  • 배포 환경(Dev/Prod) 잘못 선택하지 않도록 주의

  • 빌드 실패 시 콘솔 로그를 통해 원인 분석 후 재배포

Postman과 API 테스트

1. Postman이란?

Postman은 API 개발, 테스트, 디버깅, 문서화를 위한 올인원 도구입니다.
개발자는 Postman을 통해 API 요청을 손쉽게 보내고, 응답을 확인하며, 자동화된 테스트와 문서화를 진행할 수 있습니다.

2. Postman의 주요 역할

2.1 API 요청 테스트 도구

  • GET, POST, PUT, DELETE 등 HTTP 요청을 직접 보내고 응답을 확인할 수 있습니다.
  • 백엔드 개발 중 API 요청/응답을 디버깅하는 데 유용합니다.
POST http://localhost:8080/api/products
Content-Type: application/json

{
  "name": "상품 A",
  "price": 10000
}

2.2 API 테스트 자동화

  • 요청을 컬렉션(Collection)으로 관리하여 반복 테스트 가능

  • 환경(Environment) 설정으로 dev/staging/prod API 주소 쉽게 전환

  • Pre-request Script, Test 스크립트(JavaScript)로 테스트 자동화 가능

2.3 API 문서화

  • API 스펙을 정리하고 팀원이나 외부에 공유 가능

2.4 Mock Server 및 시나리오 구성

  • 실제 서버가 없을 때 가상의 응답 생성

  • 여러 요청 순차 실행 워크플로우 구성 가능

3. Postman과 API 서버의 관계

Postman에서 호출하는 API는 실제 백엔드 서버에서 동작하는 엔드포인트입니다.

즉, Postman은 클라이언트 역할을 하며, API 요청을 보내고 백엔드 서버가 처리한 결과를 응답받는 구조입니다.

[Postman (클라이언트)] ---> [백엔드 API 서버] ---> [DB 또는 외부 서비스]

예시 요청과 흐름:

POST http://localhost:8080/api/products
Content-Type: application/json

{
  "name": "노트북",
  "price": 1200000
}

  1. Postman에서 HTTP 요청 전송

  2. 백엔드 서버가 요청 수신 후 처리

  3. DB 저장, 비즈니스 로직 수행

  4. 처리 결과를 Postman에 응답

  5. Postman에서 응답 데이터 확인

4. 환경 관리 개념

Postman의 환경은 API 요청 시 사용하는 변수(호스트, 포트, 토큰 등)를 환경별로 구분해 관리하는 기능입니다.

예를 들어:

변수명local 환경 값
protocolhttp\://
urllocal.marketbilli.com
port8080

이걸 local이라는 환경에 저장해 둡니다.

실무에서는 보통 이렇게 환경을 분리합니다:

환경 이름protocolurlport
localhttp\://local.marketbilli.com8080
devhttps\://dev.api.marketbilli.com443
prodhttps\://api.marketbilli.com443

이렇게 설정하면 API 호출 시에 {{protocol}}, {{url}}, {{port}} 변수를 참조해서 해당 환경에 맞는 값으로 자동 대체되므로,

  • 개발 중에는 local 환경

  • 통합 테스트/QA 시에는 dev 환경

  • 실제 운영 시에는 prod 환경

BO(Back Office) 배포 정책

  • 원칙: BO는 가급적 배포하지 않음

  • 이유:

    	- 대부분 스키마 변경, 설정 수정으로 반영 가능

	- 불필요한 위험 방지

  • 예외:

    	- 로그인 페이지 UI 변경

	- System 계정 로그인 시 초록불 표시 등 직접 코드 변경이 필요한 경우
profile
myo
풀스택 개발자로 성장해가기 위한 개발 지식과 문제 해결을 위해 직접 경험해본 내용을 기록합니다.
다음 포스트

20250824 TIL - [DevOps & Tools] Jenkins Pipeline 구조와 주요 기능 정리

0개의 댓글