CI/CD Overview 스따뜨

퍼플아이오에서 처음 시작하게된 된 업무가 생겼습니다. 어플리케이션을 빌드해서 원격지 서버에 배포하는 부분입니다

젠킨스가 있다는 것은 알았지만 구축된 환경을 사용만 했기 때문에 직접 빌드나 배포를 수정하는 것은 알지 못했고 아.. 이것도 내가 알아야 하는 과목이구나 하지만.. 아직 미뤄둔 숙제 같은 느낌입니다

제가 처음 Gitlab-CI 를 수정하게 된 이유는 Local Test Case 를 서비스에 따라 각각 약 100개~300개 정도 돌리는데 어디 하나 수정이 되어 나갈때

혹시나 딱 눈에 보이는 곳만 테스트하는 개발자 셀프 테스트만 되어 전체 테스트 코드를 돌리지 않고 나갈때

이때 수정 사항이 잠재적인 버그가 되지 않기 위해 CI 에서 꼭 테스트 되어야 게으르고 꼼꼼하지 않는 제가 발 뻗고 잘 수 있는 방화벽을 만들어야 겠다 하는 바람이었습니다

이때 삽질을 좀 겪으면서 어찌저찌 추가하게 되었고 가끔 CI 테스트 실패를 겪으면 꼼꼼하지 못한 저에게 채찍질을 할 명분이 되었습니다

운이 좋게 이번에 스터디가 열리면서 다양한 파트의 다양한 직군의 사람들과 각각의 처한 환경과 다양한 배포 환경을 접하게되었습니다

서론이 길었는데 CI/CD에 대해 연구를 시작하게 되었고 스터디 산출물들이 업무에 적용되어 기존의 불편함이 하나 둘씩 반영될 예정입니다. 개선된 내용이 이어질 2탄~ 3탄 기대해주세요 Coming Soon!

그 전에!! 핵심용어와 현재 상황과 개선점에 대해 공유하고자 해당 포스팅을 하게 되었습니다

일단 지속적 소프트웨어 개발 방법이란 무엇일까요?

바로 답 부터! 반복적인 코드 변경사항을 지속적으로 빌드, 테스트, 배포할 수 있습니다

이 반복적인 프로세스는 버그가 있거나 실패한 이전 버전에서 테스트를 반복하며 리뷰를 하고 완성형의 코드를 배포시키는데 도움이 됩니다.

이 방법을 사용하면 새 코드 개발부터 배포까지 사람의 개입을 줄이거나 전혀 개입하지 않으려고 노력합니다

즉 지속적인 반복에 대해 자동화를 한다는 것 입니다

 

지속적 통합(Continuous Integration, CI)

GitLab의 Git 저장소에 코드가 저장된 애플리케이션을 생각해 보십시오. 개발자는 매일, 하루에 여러 번 코드 변경사항을 푸시합니다.

리포지토리에 푸시할 때마다 애플리케이션을 자동으로 빌드하고 테스트할 수 있습니다.

이 자동화된 스크립트는 애플리케이션에 오류가 발생할 가능성을 줄일 수 있습니다.

이 방법을 지속적 통합이라고 합니다.

애플리케이션에 제출된 각 변경사항은 운영 뿐만 아니라 개발 브랜치에도 자동으로 지속적으로 빌드되고 테스트됩니다.

이러한 정책과 분산 환경의 변경사항이 애플리케이션에 대해 설정한 모든 테스트, 지침 및 코드 준수 표준을 통과하도록 보장합니다.

지속적 전달(Continuous Delivery, CD)

지속적 전달은 지속적 통합을 넘어서는 단계입니다.

코드 변경이 코드베이스에 푸시될 때마다 애플리케이션이 빌드되고 테스트될 뿐만 아니라 애플리케이션도 지속적으로 배포됩니다. 그러나 지속적 전달을 사용하면 배포를 수동으로 트리거합니다.

지속적 전달은 코드를 자동으로 확인하지만 변경사항의 배포를 수동으로 전략적으로 트리거하려면 사람의 개입이 필요합니다.

지속적 배포(Continuous Deployment, CD)

지속적 배포는 지속적 전달과 유사한 지속적 통합을 넘어서는 또 다른 단계입니다.

차이점은 애플리케이션을 수동으로 배포하는 대신 자동으로 배포되도록 설정한다는 것입니다.

사람의 개입이 필요하지 않습니다.

Gitlab-CI 에서 알아야 하는 용어

• Pipeline
  파이프라인은 지속적 통합, 전달 및 배포의 최상위 구성 요소
• Jobs
  파이프라인 구성은 Job으로 시작됩니다. Job은 .gitlab-ci.yml 파일의 가장 기본적인 요소입니다.
• Variable
  CI/CD 변수는 환경 변수의 한 유형입니다.
  • 사전 정의된 CI/CD 변수의 기본 세트
• Environments
  환경은 코드가 배포되는 위치를 설명합니다.
• Runners
  GitLab CI/CD에서 러너는 .gitlab-ci.yml에 정의된 코드를 실행합니다.
  • 공유 러너(Shared runners)는 GitLab 인스턴스의 모든 그룹 및 프로젝트에서 사용할 수 있습니다.
  • 그룹 러너(Group runners)는 그룹의 모든 프로젝트와 하위 그룹에서 사용할 수 있습니다.
  • 특정 러너(Specific runners)는 특정 프로젝트와 연결됩니다. 일반적으로 특정 러너는 한 번에 하나의 프로젝트에 사용됩니다.
• Artifacts
  단계(Stages) 간에 전달되는 단계 결과에 사용합니다.
• Cache
  프로젝트 의존성(Dependencies)을 저장하는 데 사용합니다.

.gitlab-ci.yml 파일 생성

.gitlab-ci.yml 파일은 GitLab CI/CD에 대한 특정 지침을 구성하는 YAML 파일입니다.

이 파일에서 다음을 정의합니다.

• 러너가 실행해야 하는 작업(Job)의 구조와 순서
• 특정 조건이 발생할 때 러너가 내려야 하는 결정

사전 조건

• 프로젝트에서 사용할 수 있는 하나 이상의 Runner가 등록되어 있어야 합니다.
  • Settings > CI/CD의 Runners 섹션에서 확인

Gitlab-CI 에서 사용하는 러너

Gitlab-Ci.yml 파일은 선언형 방식으로 코드를 추가해 나갑니다 상세 내용은 gitlab 회사의 공식문서에 나온 용어 부터 시작해서 뻗어나가는 것을 추천합니다

 

CI Build 에 대한 방식

• Build 프로세스에서 Docker Image 로 생성하고 활용하는 것을 적극적으로 사용하고 있습니다

우리가 사용하는 방식

• Spring Boot App
  • gradle plugin (현재 CRM 파트에서 사용하는 형태)
    • Jib로 자바 컨테이너 빌드

./gradlew jibDockerBuild

• Dockerfile 생성
  • Dockerfile을 생성합니다
  • gitlab-ci.yml 파일에 Docker 이미지 빌드 단계 추가
• Docker Registry Service
  • AWS ECR 서비스

CI Process 에 대한 방식

1. 각자 작업한 branch 에서 push 후 Merge Request 를 요청합니다
2. MR 리뷰 후 -> 담당자가 MR을 머지하면 CI가 자동으로 동작합니다
3. CI가 동작한다는 것은 Build - (test) 과정을 진행하고 Deploy Stage 가 진행됩니다
4. 현재 프로젝트에서 Deploy 되는 것은 AWS ERC 에 올리는 것으로 지속적 전달(CD)로 진행됩니다
5. ArgoCD에 접속해서 로그인 후 해당 어플리케이션의 상대를 Refresh 하고 Sync 를 맞춥니다
6. 배포가 되었으면 각각의 환경에 맞게 스테이지/운영 테스트를 진행 합니다

 

개발환경에 대한 고민

저는 개발환경이 각각의 외부 연동과 협업 상황에 맞게 분리되어야 한다고 생각합니다. (4~5개 정도)

이 내용을 얘기하면 길어 질 것 같고 글로벌 서비스가 아니라 Admin 개발에 오버엔지니어링 일 수 있다는 반론도 수용되기 때문에 관련 링크만 첨부합니다. (조대협 - 개발환경)

• 환경이 많아지면 Git Flow 방식도 고려 대상이 됩니다 환경에 따라 각각 Branch Main Stream 이 구분되어 생성될 수 있습니다

• Development
  • Code
  • Commit
• CI Pipeline
  • Build
  • Test
    • Unit Test
    • Integration Test
• CD Pipeline
  • QA
    • Staging
      • Review
  • Deploy
    • Production

대신 그림으로 보자면 이 일련의 과정이 수행되는 환경이 구분이 분명 될 것이고 자동화된 CI는 개발자에게 새벽 배포가 아닌 충분한 숙면을 줄 수 있을 것입니다.

 

본문으로 생각한 내용은 여기까지고 추후에 이어질 성능개선 된 CI/CD 내용도 같이 기대해주세요

• 힌트는 기울여진 글씨들에 있습니다
• ArgoCD 와 성능 개선된 부분에 대해서는 다시 게시될 예정입니다