CI/CD 툴 결정

<aside> 💡

</aside>

채팅 서비스를 개발하며, 지속적인 통합(CI)과 지속적인 배포(CD)의 필요성을 인지했습니다.

코드의 통합을 자동화하여 개발 초기 단계부터 문제를 발견하고자 했고, 배포 과정을 자동화하여 배포 사이클을 빠르고 효율적으로 만들기를 원했기에 CI/CD 도구의 도입을 결정했습니다.

<aside> 💡 Jenkins vs GitHub Actions

</aside>

우리팀은 CI/CD 툴로 자주 언급되는 Jenkins와 GihubActions를 비교 후 선택하였습니다

• Jenkins

  장점	단점
  • 다양한 플러그인으로 확장이 가능하여 확장성이 높다.
  • 관련한 큰 커뮤니티가 형성되어 있어 참고할 자료가 많다	• 설정과 관리를 직접 해줘야해서, 초기 설정에 시간이 많이 소요된다.
  • 학습 커버리지가 있다.

• Github Actions

  장점	단점
  • GitHub 저장소에 내장되어 있어, 손쉽게 CI/CD를 구성할 수 있다
  • 학습 커버리지가 적다.	• 비교적 최근에 나온 거라 자료가 적다.

<aside> 💡 GitHub Actions를 선택한 이유

</aside>

1. Github과의 통합성
   1. 프로젝트의 Repository로 GitHub을 사용중이었기에, 추가적인 연동 작업 없이 바로 CI/CD 파이프라인을 구성하고 실행하기 위해 GitHub Actions를 선택했습니다.
2. 사용 용이성
   1. 1개월동안 진행되는 프로젝트인만큼 CI / CD 환경을 빠르게 구성해야 했기에 사용자 친화적 UI를 갖고 있고, 학습 커버리지가 적은 GitHub Actions를 선택했습니다.

배포 과정에서 AWS 서비스 사용

<aside> 💡 대규모 트래픽 환경을 고려한 인프라 설계 필요

</aside>

동시에 많은 사용자가 접속하는 채팅서비스의 특성상, 서비스의 확장성과 안정성은 중요한 과제였습니다.

트래픽의 급격한 변화에 유연하게 대응할 수 있는 인프라 설계가 필요하다 생각하여 자동 배포를 위한 서비스 등을 찾게 되었습니다.