[GitLab] GitLab CI/CD 알아보기

2해승·2024년 5월 28일
0

최근 백엔드 일경험을 시작하게 되었다. 꽁꽁 얼어붙은 취업 시장에서 일경험이라도 할 수 있음에 감사하고 있는 요즘, 회사에서 사용하고 있는 깃랩에 대해 공부를 해보려 한다.

GitLab 이란?

GitLab은 개발 및 협업을 위한 웹 기반 DevOps 플랫폼이다. 프로젝트를 효율적으로 배포하기 위해 도움이되는 다양한 도구와 기능을 제공한다.

GitLab 주요 기능

  • Git 리포지토리 관리
  • 프로젝트 관리
  • CI/CD

GitLab CI/CD

GitLab CI/CD는 GitLab의 일부로 소프트웨어 개발 및 배포 프로세스를 통합적으로 관리할 수 있다.

소프트웨어 생명 주기 전반을 관리하기 때문에 소스코드와 CI/CD 파이프라인을 한 곳에서 관리함으로써 불필요한 설정을 하지 않고 효율적인 개발 및 배포를 지원한다.

GitLab CI/CD Workflow

로컬에서 작업 후 변경사항을 GitLab 브랜치에 푸시하면 프로젝트의 CI/CD 파이프라인이 트리거 되어 GitLab CI/CD가 자동화된 스크립트를 실행한다.

  • 애플리케이션 빌드/테스트
  • 리뷰 앱에서 변경사항 확인

구현이 예상대로 동작하면 코드를 검토하고 승인한다.

  • 브랜치 병합 및 변경사항을 프로덕션 환경에 자동으로 배포

GitLab CI/CD 용어 및 개념

Pipeline

파이프라인은 지속적 통합, 전달 및 배포의 최상위 구성 요소로 두가지로 구성된다.

  • Jobs: 수행할 작업 정의(컴파일/테스트)
  • Stages: 작업 실행 시기 정의

한 단계의 모든 Job이 성공할 경우 파이프라인은 다음 단계로 넘어가고 실패할 경우 일반적으로 다음 단계는 실행되지 않고 파이프라인이 일찍 종료된다.

Jobs

Job은 .gitlab-ci.yml 파일의 가장 기본적인 요소이며 Runner가 실행해야 하는 명령 모음이다.

  • 최소한 script 절을 포함해야하고 정의할 수 있는 수에는 제한이 없음

<주의할 점>
job, stage의 총 갯수와 job 간의 종속성에 따라 파이프라인의 총 런타임 시간에 영향을 미친다. 만일 정의 갯수를 무지성으로 사용하게 된다면 아주 비효율적인 파이프라인이 될 것이다.

이를 해소하기 위해서는 병렬로 실행하는 여러 항목의 job을 동일한 stage에서 실행하는 것으로 전체 런타임을 줄일 수 있다. 단, 병렬 작업을 지원하기 위해서는 더 많은 Runner가 동시에 실행되어야 한다.

Job example

job1:
  script: "execute-script-for-job1"

job2:
  script: "execute-script-for-job2"

Variables

변수를 사용하여 하드 코딩을 방지하고 재사용성을 높일 수 있다.

Runners

파이프라인(.gitlab-ci.yml)에 정의된 작업을 실행하는 에이전트이다.

Runner Workflow

  • GitLab 리포지토리에 코드 변경사항을 푸시하면 GitLab은 하나 이상의 작업이 포함된 파이프라인을 실행

  • GitLab Runner는 주기적으로 GitLab 서버에서 실행할 새 작업 확인

    • .gitlab-ci.yml에 정의된 작업 단계 실행
  • 작업이 실행되면 실시간 업데이트, 로그 등 생성된 모든 아티팩트를 GitLab 서버로 보냄

    • 파이프라인 및 해당 작업의 진행 상태를 모니터링
  • 작업 완료시 최종 상태를 GitLab 서버에 보고

Artifacts and Caching

아티팩트는 빌드 출력, 테스트 결과, 로그 등 작업 실행중에 생성되는 파일이다.

캐싱은 파이프라인 실행 간에 파일 또는 종속성을 재사용하여 작업 실행 속도를 높이는데 사용할 수 있다.

Environments and Deployments

환경은 배포를 관리 및 추적하고 애플리케이션을 모니터링하여 롤백 관리에 도움이 된다.

Pipeline 예제

GitLab CI/CD 파이프라인은 .gitlab-ci.yml 이라는 파일로 구성되는데 다음 내용을 정의한다.

  • 파이프라인의 구조와 순서를 정의
  • GitLab Runner 를 사용하여 실행할 항목
  • 특정 상황이 발생했을 때 실행할 항목

이제 테스트 스크립트를 돌려서 정상적으로 실행되는 과정을 한번 확인해보자.

.gitlab-ci.yml

stages: # List of stages for jobs, and their order of execution
    - build
    - test
    - deploy

build-job: # This job runs in the build stage, which runs first.
    stage: build
    script:
        - echo "Compiling the code..."
        - echo "Compile complete."
unit-test-job: # This job runs in the test stage.
    stage: test
    script:
        - echo "Running unit tests..."

deploy-job: # This job runs in the deploy stage.
    stage: deploy
    script:
        - echo "Deploying application..."
        - echo "Application successfully deployed."

스크립트 파일을 프로젝트의 루트 경로에 푸시하면 별도의 작업을 거치지 않고 자동으로 트리거 되어 파이프라인이 실행된다.


GitLab CI/CD를 공부하며 지난번에 활용했던 Github-Jenkins와는 다르게 과정이 비교적 간단하다고 느꼈다. 아무래도 외부 서비스를 직접 통합하는 것보다 통합 관리가 되는 서비스를 사용하는게 편할 수 밖에 없는듯.

기업이 깃허브보다 깃랩을 선호하는 이유를 알 것 같다. 하지만 지금 일경험 회사는 깃랩을 코드 저장소 용도로만 사용하고 있어서 아쉬웠다. 어차피 백엔드 개발을 혼자서 다 하는거라면 기존 배포 프로세스에서 GitLab CI/CD를 구축해보면 많은 공부가 될 것이다.

다음 포스팅에서는 냅다 실무에 적용하는 것이 아닌 테스트 서버에 express를 올리고 배포해보는 것으로 돌아오겠다! 아듀!!!!!




[참고]
https://workshop.infograb.io/gitlab-ci/11_introduction-to-gitlab-cicd/
https://somaz.tistory.com/202

profile
Node 백엔드 개발자 / 데브옵스 취준생

0개의 댓글

관련 채용 정보