CI/CD

in Web-Programming on Server


개요

개발이 아무리 좋아도 마지막 과정을 안거치면 개발 실력, 솜씨 등을 증명을 하지 못한다. 그것을 증명하려면 개발의 마지막 단계까지 온전히 마쳐야 한다. 바로 배포이다. 토의 - 설계 - 개발 - 테스트를 걸쳐 마무리 일격을 하는 단계가 바로 배포로서, 개발한 것을 공개로 또는 특정인에게 보여주는 단계이다. 그리고 뭔가 또 이상하다 싶으면 다시 고쳐서 다시 배포를 하게 된다. 이러한 반복적인, 지속적인 개발 루프를 일컬어 CI/CD라 한다. 작성자 본인도 이전 직장에서 젠킨스로 매일매일 솔루션 빌드하고 내뱉는 과정을 뜯어본 적이 있고, 최근엔 백앤드 팀 프로젝트에서도 github action, docker, aws ec2를 이용해 배포를 거쳐간 적이 있다. 이제 정확한 CI/CD의 의미를 파해쳐본다.

CI/CD

  • CI (Continuous Integration)
    • 개발자가 변경한 코드를 자주 통합하고, 이 코드가 전체 시스템과 잘 어우러지는지 자동으로 테스트하는 프로세스
    • 코드 변경이 발생할 때마다 빌드 및 테스트를 수행하여 코드 품질을 유지하고 문제를 조기에 발견
  • CD (Continuous Deployment)
    • CI의 결과물을 사용자에게 자동으로 배포하는 프로세스를 포함. 코드 변경이 통합되고 테스트를 통과하면, 이를 자동으로 스테이징 환경 또는 프로덕션 환경에 배포
    • 지속적인 배포(Continuous Deployment)는 CI/CD의 확장 개념으로, 승인 절차 없이 자동으로 프로덕션 환경에 배포하는 것을 의미
  • CI/CD 장점
    • 빠른 피드백: 코드 변경 후 즉각적인 빌드 및 테스트 결과를 확인, 개발자가 문제를 빠르게 인지하고 수정가능
    • 자동화된 프로세스: 빌드, 테스트, 배포 과정이 자동화되어 수동 작업을 줄이고, 인적 오류를 방지
    • 일관된 배포: 동일한 배포 프로세스를 통해 모든 환경(개발, 테스트, 스테이징, 프로덕션)에서 일관된 결과를 보장
    • 높은 품질 유지: 코드 품질을 지속적으로 검증하고, 잠재적인 문제를 조기에 발견하여 품질을 유지
    • 개발 속도 향상: 자동화된 파이프라인을 통해 개발 주기를 단축하고, 새로운 기능을 빠르게 사용자에게 제공

요약하자면, 개발한 것을 지속적으로 반영하고 배포하는 자동화 프로세스인 것이다. 이러한 프로세스를 설정을 하면 우리는 딸깍하나로 개발한 것을 바로 반영하고 보여줄수가 있다는 것이다.

CI/CD 도구

내가 사용했던 도구는 Jenkins와 github actions이다. 그외 다른 도구들도 있지만, 일단 사용했던 것만 알려준다.

  • Jenkins
    오픈 소스 CI/CD 도구로, 플러그인을 통해 다양한 기능을 확장할 수 있는 도구
    • 높은 커스터마이징 가능
    • 다양한 플러그인 지원
    • 분산 빌드 및 다중 플랫폼 지원
    • 대규모 프로젝트에 적합
    • 러닝 커브 높음 = 설정 복잡
  • github actions
    GitHub 저장소에 직접 통합되어 있는 CI/CD 도구로, YAML 파일을 사용하여 워크플로우를 정의
    • GitHub 저장소와의 강력한 통합
    • 다양한 이벤트 기반 트리거
    • 풍부한 커뮤니티 및 Marketplace 지원
    • 무료 사용 가능 (제한된 런타임 제공)
    • YAML 파일 워크플로우로 설정 가능 = 이것만 알면 거의 설정 다 됨됨

대략적인 ci/cd 흐름

어떤 저장소 A가 있다고 가정한다. 그리고 CI/CD 도구가 Jenkins 또는 github actions이라 가정한다.

  • Jenkins
    1. 젠킨스 워크스페이스 설정에서 저장소 A와 연결을 설정한다.
    2. 젠킨스 워크스페이스 설정에서 실행 주기 및 시점을 설정한다.
    3. 젠킨스 워크스페이스 설정에서 A에 대한 빌드 명령어를 설정한다.
    4. 젠킨스 워크스페이스 설정에서 A에 대한 테스트 명령어를 설정한다.
    5. 젠킨스 워크스페이스 설정에서 A에 대한 배포 명령어를 설정한다.
      • 웹 프로젝트라면 배포 URL(AWS EC2를 제공받는 가정)로 설정하여 최종 배포
      • 솔루션이라면 빌드 후 아티팩트로 남겨놓아 다운
    6. 젠킨스 워크스페이스 설정을 마친 후 시작(주기적인 설정이라면 자동 시작 될 것)
    7. 젠킨스 작업 관찰 (오류시 체크 / 성공 여부 확인)
  • github actions
    1. github에서 Action를 눌러 원하는 workflow 양식을 찾는다.
    2. 예를 들어 Docker Image를 검색한다면 저장소의 workflow폴더 내 yml파일로 설정 과정을 편집할 수 있다.
    3. yml 설정 과정은 적절한 검색을 이용하여 설정을 해놓는다.
      • 언제 발동되는가?
      • 어느 브랜치 위주로 빌드되는가?\
      • 어떤 과정을 거쳐서 테스트하고 빌드하고 배포하는가?
    4. github action 설정이후 github에서 조건부로 코드가 반영할 때 반영(예: PR이후 develop에 merge시)
    5. github action의 작동 과정 관찰 (오류시 체크 / 성공 여부 확인)

여기서 Jenkins든 github actions이든 설정된 과정을 실행하는 곳은 내 컴퓨터 저장 공간이 아니다. 배포용으로 따로 가상환경에서 돌아가는 것이고 이 가상환경도 설정해줘야 한다. 주로 AWS EC2나 네이버 클라우드 플랫폼등도 있다.

한줄로 요약하자면, 다음과 같다.

시작 > AWS 가상환경 내 실행 > 설정 과정대로 진행 > 가상환경 내 배포 또는 아티팩트로 배포 > 끝