최근 백엔드 일경험을 시작하게 되었다. 꽁꽁 얼어붙은 취업 시장에서 일경험이라도 할 수 있음에 감사하고 있는 요즘, 회사에서 사용하고 있는 깃랩에 대해 공부를 해보려 한다.
GitLab은 개발 및 협업을 위한 웹 기반 DevOps 플랫폼이다. 프로젝트를 효율적으로 배포하기 위해 도움이되는 다양한 도구와 기능을 제공한다.
GitLab CI/CD는 GitLab의 일부로 소프트웨어 개발 및 배포 프로세스를 통합적으로 관리할 수 있다.
소프트웨어 생명 주기 전반을 관리하기 때문에 소스코드와 CI/CD 파이프라인을 한 곳에서 관리함으로써 불필요한 설정을 하지 않고 효율적인 개발 및 배포를 지원한다.
로컬에서 작업 후 변경사항을 GitLab 브랜치에 푸시하면 프로젝트의 CI/CD 파이프라인이 트리거 되어 GitLab CI/CD가 자동화된 스크립트를 실행한다.
구현이 예상대로 동작하면 코드를 검토하고 승인한다.
파이프라인은 지속적 통합, 전달 및 배포의 최상위 구성 요소로 두가지로 구성된다.
한 단계의 모든 Job이 성공할 경우 파이프라인은 다음 단계로 넘어가고 실패할 경우 일반적으로 다음 단계는 실행되지 않고 파이프라인이 일찍 종료된다.
Job은 .gitlab-ci.yml 파일의 가장 기본적인 요소이며 Runner가 실행해야 하는 명령 모음이다.
<주의할 점>
job, stage의 총 갯수와 job 간의 종속성에 따라 파이프라인의 총 런타임 시간에 영향을 미친다. 만일 정의 갯수를 무지성으로 사용하게 된다면 아주 비효율적인 파이프라인이 될 것이다.이를 해소하기 위해서는 병렬로 실행하는 여러 항목의 job을 동일한 stage에서 실행하는 것으로 전체 런타임을 줄일 수 있다. 단, 병렬 작업을 지원하기 위해서는 더 많은 Runner가 동시에 실행되어야 한다.
job1:
script: "execute-script-for-job1"
job2:
script: "execute-script-for-job2"
변수를 사용하여 하드 코딩을 방지하고 재사용성을 높일 수 있다.
파이프라인(.gitlab-ci.yml)에 정의된 작업을 실행하는 에이전트이다.
GitLab 리포지토리에 코드 변경사항을 푸시하면 GitLab은 하나 이상의 작업이 포함된 파이프라인을 실행
GitLab Runner는 주기적으로 GitLab 서버에서 실행할 새 작업 확인
작업이 실행되면 실시간 업데이트, 로그 등 생성된 모든 아티팩트를 GitLab 서버로 보냄
작업 완료시 최종 상태를 GitLab 서버에 보고
아티팩트는 빌드 출력, 테스트 결과, 로그 등 작업 실행중에 생성되는 파일이다.
캐싱은 파이프라인 실행 간에 파일 또는 종속성을 재사용하여 작업 실행 속도를 높이는데 사용할 수 있다.
환경은 배포를 관리 및 추적하고 애플리케이션을 모니터링하여 롤백 관리에 도움이 된다.
GitLab CI/CD 파이프라인은 .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