개발을 하다보면 CI/CD에 대한 이야기를 종종 듣게 됩니다. CI/CD란 무엇이며 왜 중요할까요? 오늘은 CI/CD에 알아보며 제가 구성한 CI/CD 시나리오도 함께 이야기해 보도록 하겠습니다.
CI/CD란?
CI (Continuous Integration)
CI는 지속적 통합을 의미하며 기능 추가, 버그 수정 등 코드가 수정된 후에 빌드, 테스트를 통해 운영 브랜치에 통합되는 것을 의미합니다. 이 때 빌드, 테스트와 같은 프로세스를 자동화하여 변경된 코드에 문제가 있는 경우 빠르게 파악하고 수정할 수 있습니다. 이로 인해 효율적이고 안정적인 환경 속에서 개발에 집중할 수 있게 됩니다.
CD (Continuous Delivery or Continuous Deployment)
CD는 지속적 제공 혹은 지속적 배포를 의미합니다. 두 용어 모두 변경된 코드가 배포되는 것을 의미하며 지속적 제공은 수동 배포, 지속적 배포는 자동 배포를 뜻합니다.
그리고 CI/CD가 물 흐르듯 자동으로 진행될 수 있도록 하는 프로세스를 CI/CD 파이프라인이라고 합니다.
핵심은 자동화
CI/CD 파이프라인의 핵심 목적은 자동화입니다. 개발자가 수정한 코드가 배포되는 일련의 과정이 자동화되어 효율적인 개발 환경을 구축하는데 그 목적이 있습니다.
만약 코드가 변경될 때마다 수동으로 테스트하고 배포해야 한다면 어떻게 될까요?
파일질라 화면, 변경된 파일을 직접 옮겨 배포
실제로 제가 처음 퍼블리싱을 배웠을 때와 회사에 아직 CI/CD 파이프라인이 구축되지 않았을 때는 파일질라를 사용하여 배포했습니다. (회사에서는 배포 권한이 없었습니다😅)
개발자가 변경된 파일을 수동으로 배포하는 작업은 비효율적이며 휴먼 에러가 발생하기도 쉽습니다. CI/CD 파이프라인을 구축해 둔다면 개발 외의 불필요한 작업으로 시간이 소모되는 것을 막을 수 있고 안정적으로 프로젝트를 운영해 나갈 수 있게 됩니다.
무엇으로 CI/CD 파이프라인을 구축할까?
제가 CI/CD 파이프라인을 구축하기 위해 사용한 도구는 Github Actions입니다. Github을 사용하고 있다면 추가적인 설치 작업 없이 Github에서 발생하는 이벤트(PR, push, issue 등)를 기반으로 작업을 트리거 할 수 있으며 마켓 플레이스에서 공유되는 액션을 사용할 수 있다는 장점이 있습니다.
Jet Brain 설문 결과, 전체적으로는 Jenkins가 1위이지만 Github Actions가 새로운 1위로 떠오르고 있음
또한 Jet Brain에서 2024년 가장 많이 사용하는 CI 도구를 설문한 결과. Github Actions가 새로운 1위로 떠오르고 있으며 개인 프로젝트에서 가장 인기 있는 도구라고 합니다. (1위는 못 참지)
위와 같은 이유로 저는 Github Actions를 선택하게 되었습니다. 추후에 Github Actions에서 사용하는 워크플로우 파일 구성에 대해서도 포스트를 작성해 보겠습니다.
CI/CD 시나리오
Github Actions를 도입하며 구성한 CI/CD 시나리오는 위와 같습니다. (참고로 저는 브랜치 관리 전략으로 GitLab Flow를 사용하고 있습니다. 브랜치 전략 포스트 보러 가기)
1. PR 생성 및 업데이트
feature 브랜치에서 코드 변경이 마무리되어 PR이 생성되고 업데이트 될 때 자동으로 테스트가 실행됩니다. 사실 혼자 작업하고 있기에 PR의 필요성에 대해 고민하기도 했지만 코드 변경 사항을 기록하고 테스트를 통과한 커밋한 배포 브랜치에 통합 될 수 있도록 PR 생성 및 업데이트 상황을 시나리오에 추가하였습니다.
2. main, production 브랜치에 push
main, production 브랜치에 커밋이 push되면 테스트 ➡️ 배포 ➡️ 슬랙 알림 작업이 일어납니다. main 브랜치에서는 Vercel에서 제공하는 preview 환경에 배포하여 QA를 진행할 수 있게 하였고 QA가 완료된 후 production 브랜치에 merge되면 production 환경으로 배포됩니다. 이 때 각 환경에서는 배포 성공, 실패 유무에 관계 없이 슬랙 알림이 오도록 시나리오를 구성했습니다.
이미 테스트를 통과한 커밋만 배포 브랜치에 merge되는데 또 다시 테스트를 실행하는 것이 중복 작업이라는 생각이 들었지만 혹여나 배포 브랜치에 바로 커밋을 push하여 테스트를 통과하지 않은 코드가 배포되는 상황을 방지하기 위해 테스트 단계를 추가하였습니다.
포스팅을 마무리하며
사실 CI/CD에 대한 이야기를 많이 들어왔지만 막연한 개념으로 느껴졌습니다. 하지만 코드 변경, 테스트, 배포까지의 시나리오를 구성하고 Github Actions로 자동화 해보며 "아, 이런 게 CI/CD구나" 라고 감을 잡을 수 있었습니다. 업무의 효율을 높이는 방법을 이야기 할 때 항상 빠지지 않는 것이 바로 자동화인데요. 불필요한 수동 작업에서 벗어나 집중해야 할 부분에 더 집중할 수 있도록 CI/CD 파이프라인을 구축해 보면 좋을 것 같습니다👍