CI/CD 의 개념, 적용해본 후기

개요

얼마 전, SNS를 보다가 재미있는 글을 읽은 적이 있습니다. 이 글은 이상적인 프로그래머의 삶이 어떤 것인지를 그린듯한 글이었습니다. 출근과 퇴근이 자유롭고 소스코드 관리가 잘 되어있어서 버그는 간단하게 3줄 정도를 고치면 된다는 등 꽤나 흥미로운 내용이니 궁금하신 분은 여기서 읽어보시길 바랍니다. 캡처본이 여기저기 돌아다니니 한 번쯤 읽어 보신 분들도 꽤 많을 거 같네요. 

 

CI/CD는 위에 있는 글에서 한마디로 정의하고 있습니다. 개발 - 빌드 - 테스트 - 배포까지의 전 과정을 자동화하는 것이 바로 CI/CD의 핵심 개념입니다.

 

CI, CD의 개념

짧게 개념잡기

CI (Continuous Integration)란

여러 개발자가 작성하거나 수정한 소스를 지속적으로 통합하고 테스트하는 것을 뜻합니다

 

CD (Continuous Delivery/Deployment)란

개발, 통합, 배포, 릴리즈, 테스트를 자동화하여 지속적으로 배포하는 것을 뜻합니다.

 

CI를 적용할 때의 흐름

1. 개발자는 자신이 개발한 소프트웨어의 소스코드를 공통된 버전 관리시스템(github 등)에 저장합니다.
2. 소스코드상에 변동이 생기면 버전 관리 시스템에서는 CI 툴 (Jenkins)로 소스코드 변경을 알립니다.
3. CI툴에서는 변경된 소스코드를 대상으로 Build, Test, Merge를 진행합니다. 이 과정들이 완료되면 슬랙, 카카오톡, 메일 등을 통해 통합 결과를 알립니다. 

 

CI 툴

Jenkins를 가장 많이 사용하는 것 같습니다. CI와 CD를 모두 구현할 수 있으며 사용할 수 있는 여러 플러그인들이 있어서 CI/CD를 구현하는 것을 편리하게 할 수 있습니다. 단지 CI 전용 서버를 따로 구축해야 한다는 부담은 있습니다.

최근에 나온 Github Action에서는 따로 CI서버를 구축할 필요 없이 CI를 구현하게 해주고 있습니다. 아래 내용과 같은 파일을 만드는 것으로 CI 전략을 설정할 수 있습니다.

on: push
jobs:
  test:
    strategy:
      matrix:
        platform: [ubuntu-latest, macos-latest, windows-latest]
    runs-on: ${{ matrix.platform }}
    steps:
    - uses: actions/checkout@v1
    - uses: actions/setup-node@v1
      with:
        version: 12
    - run: npm install-ci-test
    - uses:

 

CI의 장점

하나의 소프트웨어에 대해 수많은 개발자들이 동시에 개발을 진행하고 이 소스코드를 정기적으로 통합하는 회사라면 소스코드의 병합은 상당히 많은 공수를 요구하는 일이 될 것입니다. CI를 적용한다면 소스코드의 변동이 생길 때마다 지속적으로 개발자들의 코드를 병합하고 테스트를 진행합니다. 변경한 소스코드가 문제가 발생하지 않는지 테스트를 실행하고 일련의 과정 중 코드의 충돌, 테스트의 실패 등이 발생하면 즉각적으로 알림을 전송합니다. 이 과정을 통해 아래 장점을 얻을 수 있습니다.

• 개발의 편의성이 증가합니다.
• 변경된 코드에 대한 즉각적 피드백과 검증이 가능합니다.
• 소스코드의 통합과 검증에 들어가는 시간 단축합니다.

 

CD를 적용했을 때의 흐름

CI를 통해 검증된 소스코드를 지속적으로 배포해야 하기 때문에, CD를 구현하기 위해서는 CI가 우선적으로 진행되어야 합니다.

1. CI를 통해 소스코드를 검증합니다.
2. 검증된 소프트웨어를 실제 프로덕션 환경으로 배포합니다.

 

CD의 장점

• CD의 장점은 실제 배포할 애플리케이션의 서버가 여러 대일 때, 배포할 작업물이 여러 개일 때 나타납니다. 수작업으로 여러 작업물을 여러 서버에 배포할 때 발생하기 쉬운 실수를 방지할 수 있습니다.
• '원클릭으로 빌드, 테스트, 배포 자동화'를 진행할 수 있습니다. 즉 소스코드 변경부터 배포까지의 작업을 자동화할 수 있기 때문에 수작업으로 할 때의 불편함을 줄일 수 있습니다.
• 개발자는 개발에만 집중할 수 있게 됩니다.

 

실제 사용 사례

제가 작성한 토이 프로젝트인 DelFood에서 CI/CD를 구현하였습니다. DelFood는 아래 사진과 같은 구조로 설계한 애플리케이션 서버입니다. 빌드 - 테스트 - 배포까지의 과정이 너무 귀찮아서 CI와 CD를 구현한 제 사례를 이야기해보고 싶습니다.

DelFood의 CI/CD 전략

1. Github에 소스코드를 푸시하면 Github에서는 Jenkins로 Web Hook을 날립니다.
2. Jenkins에서 빌드-테스트를 진행하고 검증된 소스코드로 도커 이미지를 만듭니다.
3. Jenkins 내부에 설정된 스크립트로 만들어진 도커 이미지를 Docker hub로 푸시합니다.
4. Jenkins에서 프로덕션 서버로 스크립트 실행 명령을 날립니다. 해당 스크립트를 받은 운영서버는 Docker hub에서 이미지를 다운로드한 후 애플리케이션을 배포합니다.

소스코드를 Github에 푸시하는 것 만으로 빌드, 테스트, 배포까지 모두 자동으로 진행되도록 설정해두었고 같이 협업하던 동료들의 소스코드가 병합될 때 오류가 발생하면 바로바로 알아챌 수 있어서 무척 편리했습니다.

 

CI/CD를 구현하게 된 계기는 불편함 때문이었습니다. 직접 수작업으로 배포할 때는 애플리케이션을 Jar파일로 묶어준 후 FTP를 통해 운영 서버에 Jar파일을 옮겨 실행해야만 했습니다. 변경되기 전 버전의 Jar파일을 옮기는 실수를 하기도 했고, 옮긴 후 실행을 시키지 않아서 변경사항이 적용되지 않은 적도 많았습니다. 이 작업이 매우 귀찮은 작업이었기 때문에 소스코드를 변경하고 실 운영서버에 배포하는 작업을 잘 안 하게 되기도 했습니다. CI/CD의 존재를 알게 된 이후에는 소스코드를 커밋할 때마다 자동으로 모든 작업이 진행되니 더 이상 제가 손댈 일이 없어져서 참 좋았습니다.

 

조금 더 자세한 내용은 여기를 참고해주세요.

[Delfood] CI/CD 서버 구축과 첫 배포

 

 

마치며

아직 CI/CD가 구축된 개발을 진행해보지 않았다면 꼭 자동화된 CI/CD를 구축해보시기를 강력하게 추천드립니다. CI/CD의 장점을 위에 여러 개 나열해보았지만 가장 큰 장점은 귀찮은 작업이 사라진다는 것입니다. 푸시 한 번으로 모든 작업이 완료되는 편리함은 개발자가 개발에만 집중할 수 있게 해 주고, 업무 능률의 증가로 이어집니다. CI/CD에 대한 소개는 여기에서 마치겠습니다.

 

 

 

 

References

https://www.redhat.com/ko/topics/devops/what-is-ci-cd

CI/CD(지속적 통합/지속적 제공): 개념, 방법, 장점, 구현 과정