CD(Continuous Deployment) 기본 개념, CD 도구 선택의 이유

2023. 11. 20. 15:12Project 해축갤/CI CD

728x90

지금까지의 이야기

2023.11.17 - [해축갤 프로젝트/CI CD] - 원큐에 끝내는 GitHub Actions 를 이용한 CI 구축 : 기본 실습 가이드

 

원큐에 끝내는 GitHub Actions 를 이용한 CI 구축 : 기본 실습 가이드

안녕하세요! 지난 번에는 CI(Continuous Integration) 프로세스와 도구 선택에 대해 알아보았습니다. 2023.11.14 - [해축갤 프로젝트/CI CD] - CI(Continous Integration) 도구 선택 고민 원큐에 끝내기 CI(Continous Integr

xpmxf4.tistory.com

저번까지는 CI(Continuous Integration) 를 도입한 과정을 공유했습니다.

테스트 코드를 작성후 GitHub Actions를 활용한 CI 파이프라인을 구축했는데,

이제는 CI 하면 바로 따라오는 CD(Continuous Deployment)를 구축할 차례입니다!

 

예전의 글처럼,

2023.11.14 - [해축갤 프로젝트/CI CD] - CI(Continous Integration) 도구 선택 고민 원큐에 끝내기

 

CI(Continous Integration) 도구 선택 고민 원큐에 끝내기

2023.11.14 - [해축갤 프로젝트/CI CD] - CI(Continuous Integration) 개념, 개인 CI vs 팀 CI CI(Continuous Integration) 개념, 개인 CI vs 팀 CI 2023.10.31 - [해축갤 프로젝트/테스트 코드] - postman 띡띡딸깍 귀찮아서 테스트

xpmxf4.tistory.com

CD의 도구는 여러 가지가 있고, 이 중 어떤 도구가

나의 프로젝트에 가장 적합한 도구인지 알고 선택할 수 있는지 알아보겠습니다 😃

CD의 개념과 중요성

CI/CD 파이프라인

개발자의 변경 사항을 repository에서 고객이 사용 가능한
프로덕션 환경까지 자동으로 릴리스하는 것을 의미합니다.
이는 애플리케이션 제공 속도를 저해하는 수동 프로세스로 인한 운영팀의 프로세스 과부하 문제를 해결합니다.

[출처] : https://www.redhat.com/ko/topics/devops/what-is-ci-cd?cicd=32h281b

 

프로덕션 환경에 자동으로 릴리스라는 게 핵심이고,

이를 Spring Boot 적으로 바꿔 말하면 

jar 파일을 알아서 만들고 실행 환경(저나 보통의 경우 EC2)에 보내

spring을 실행시키는 거라고 보면 되겠죠!

CD 도구 선택 시 고려사항

언제나 그렇듯 기술을 선택하는 데 있어서 항상 다양한 기준이 있고

본인의 상황에 더 적합한 기술을 선택해야 합니다.

 

그렇기에 CD 의 도구 선택 시 고려사항을 한 반 알아보겠습니다.

  1. 기존 시스템과 통합성
    • RedHat의 문서에서 나오듯 CD 를 구축하려면 이에 앞서 Continuous Integration, Delivery 가 끝난 상태여야 합니다.
    • 이때 Integration, Delivery 를 구축하는 데 있어 사용한 시스템들이 있고
    • 이 시스템과의 호환성 및 통합성을 고려해야 합니다.
  2. 지원 가능 환경
    • 배포하는 환경이 cloud 인지, On-premise 인지
  3. 사용자 친화성
    • 사용하기 쉬운 UI 및 설정의 용이성
  4. 가격 정책
    • 무료인지 아닌지...! (사실 제일 중요)

 

CD 도구의 여러 종류

CI 와 마찬가지로 CD를 구축하는 도구도 다양하게 존재합니다.

Jenkins, GitHub Actions, AWS CodeDeploy, Tekton Pipelines, Spinnaker, GoCD, Concourse, Screwdriver,... etc

등등이 있는 데 이 중 가장 많이 사용되는 3 가지 Jenkins, GitHub Actions, AWS CodeDeploy에 대해 알아보자면

  • GitHub Actions: 이미 CI 과정에 적용되어 있으며, GitHub 저장소와의 통합성이 뛰어납니다.
  • Jenkins: 강력한 커스터마이징과 풍부한 플러그인 생태계를 갖추고 있습니다.
  • AWS CodeDeploy: AWS 기반의 프로젝트에 최적화된 배포 도구입니다.

GitHub Actions 선택 이유

이 중 저는 GitHub Actions를 선택했고 그 이유는 다음과 같습니다.

  1. 기존 CI 통합: 이미 CI 프로세스에 GitHub Actions를 사용하고 있기 때문에, 동일한 시스템을 CD에도 적용하는 것이 효율적입니다.
  2. GitHub 저장소와의 통합: GitHub Actions는 GitHub 저장소와 긴밀하게 통합되어 있어, 소스 코드 관리와 배포가 용이합니다.
  3. 사용의 용이성: GitHub Actions는 사용자 친화적인 인터페이스를 제공하며, 기존 GitHub 사용자에게 친숙한 환경을 제공합니다.
  4. 비용 효율성: GitHub Actions 공개 리포지토리에 대해 무료 사용량을 제공하기에 비용 효율적입니다

AWS CodeDeploy vs GitHub Actions?

이번 글을 쓰면서 AWS CodeDeploy와 GitHub Actions 중 어떤 것을 선택할지가 가장 고민이었습니다.

저의 현재 배포 환경은 AWS EC2 이기 때문에

 

 

CodeDeploy 같이 AWS 기반의 프로젝트에 최적화된
배포 도구를 사용해야 하지 않나? 

라는 고민이 들었죠.

 

하지만 다음과 같은 이유들로 CodeDeploy 보단 GitHub Actions를 선택했습니다.

  1. GitHub Actions 로도 EC2에 배포 가능
  2. CI 시스템(GitHub Actions) 와의 호환 및 통합성
  3. 추후 CodeDeploy와 함께 사용도 가능 -> 확장성

위 3가지가 핵심인 이유이지만 또한 찾아봤던 근거로는

  1. GitHub Actions는 다양한 환경에 대한 배포를 지원하기에,
    EC2 가 아니라 다른 클라우드 서비스나 온프레이스 서버로의 배포도 가능하다.

이럴 일이 있나라고 생각하실 수도 있는 데

현재 진행 중인 우아한 남형제들 프로젝트에서는 팀원분이 EC2로 돈내기 싫으시다고

별도의 홈서버를 구축하시고 배포하자는 의견이 나왔습니다. 

 

이런 경우에는 CodeDeploy 보다는 GitHub Actions 가 적합하겠죠!

 

결론

언제나 프로젝트의 요구사항에 따라 기술선택을 해야 합니다.

그래서 저는 다음과 같은 이유들로 이번에도 GitHub Actions를 선택했고, 

  1. 기존 CI 통합
  2. GitHub 저장소와의 통합
  3. 사용의 용이성
  4. 비용 효율성

다음 글에서는 실제로 적용하기를 보여드리겠습니다!

728x90