0. 들어가며

지금까지 여러 프로젝트를 진행하면서 개발은 수차례 했지만, 제대로된 배포를 해본 적이 없었습니다.

그렇기에 배포가 어떻게 진행되는지도 모르고 빌드 조차 하지 않은 채 yarn start 와 같은 방법으로 구동시켜 접속되도록 했었죠...(대놓고 야매).. 이런 방법은 잘못된 방법인 것을 알고 있었지만 그저 개발 경험하는 토이프로젝트 인데 빌드하고 배포까지 해야 할까? 하는 아주 잘못된 생각을 가지고 있었기에 배포를 위해서 무언갈 알아보진 않았었습니다.. 하하

하지만 공부를 하면서 배포의 필요성은 더욱 높아졌습니다. 아래와 같은 깨달음으로..

• 배포 및 배포 후 기능 추가 같은 사후 관리가 없는 프로젝트 경험이면 그저 화면만 개발하는 퍼블리싱 개발자로 남을 것이란 느낌
• 배포를 하여 내가 만든 프로젝트를 사람들에게 보여주고 싶음
• 배포를 제대로 한 적이 한번도 없었기에 프로젝트 마무리를 제대로 못했다는 느낌이 마음 한 구석을 불편하게 함
• 더더욱이 기업에서 배포경험이 있는 개발자를 우대하기 때문
• 다른 비개발자와의 프로토타입 공유를 위해서라도 임시 배포는 필요함

그렇기에 !! 배포 관련 경험을 가지고 가면 정말 좋은 경험이 될 것이라 생각이 들었습니다.

이번 프로젝트는 성공적인 서비스를 위해! 설계부터 제대로 하고 프로젝트 사후 관리를 어떻게 할 것인지에 대해 방향을 잡은 뒤 기능 개발을 시작하자고 팀원과 계획을 했습니다.

처음 사용 해 보는 것이니 미숙하더라도 실패하고 풀어내서 얻어가는 것이 있도록...

위 단계에서 잘 모르는 기술 여러개 보였는데, 이 글에서는 차례로 CI/CD, 테스트 자동화, 자동 배포 입니다. 이 글에서는 위 용어들을 알아보고, 진행중인 프로젝트의 배포를 위한 환경 구축을 어떻게 진행할 것인지 정하고자 합니다!

1. CI/CD란?

프로젝트 계획을 하면서, 팀원이 계속 언급했던 것이 CI/CD 였는데, 이 용어.. 낯설기도 하면서 몇 번 접해봤었다. 정보처리기사 공부할 때 한번 쯤 봤고? 학부때 소프트웨어 공학 강의때 봤었다. 이제는 정확히 알아야지...👀

개발 > 빌드 > 테스트 > 릴리즈 > 배포

일반적인 애플리케이션의 개발단계 입니다. 지금까지 위 단계에서 개발 까지만 했었습니다 😅 개발부터 배포까지 확실하게 하기위해 CI/CD를 구축하고자 합니다.

CI/CD는 지속적 통합(Continuous Integration)/지속적 배포(Continuous Deployment) 또는 지속적 제공 (Continuous Delivery) 의 줄임말로, CI는 한마디로 빌드 및 테스트 자동화 과정, CD는 배포 자동화 과정을 뜻합니다.

CI - 지속적인 통합으로, 새로운 코드가 작성되었을 때 주기적으로 빌드 및 테스트가 진행되면서 공유되는 repository에 merge 되는 것
CD - 지속적인 배포(제공)으로, CI단계를 거친 코드를 실제 운영 서버에 자동 배포 하는 것

한 문장으로, 개발, 빌드, 테스트, 배포까지 모든 단계를 자동화 하여 사용자에게 빠르게 배포하는 것

2. CI 단계에서,

개발자는 github와 같은 형상관리 시스템에 계속 커밋하고 통합합니다. 통합한 코드를 빌드하고 테스트하여 버그가 발생하면 버그를 해결합니다. 이 과정에서 빌드와 테스트를 자동으로 진행 해주면 아래와 같은 장점이 있습니다.

• 여러 개발자가 관련된 코드를 작업하여 발생하는 충돌 문제를 해결할 수 있다.
• 커밋 할 때 마다 빌드와 자동 테스트가 이루어져 잘못된 merge를 예방할 수 있다.
• 코드 검증에 들어가는 시간이 줄어들며, 개발 편의성이 좋아진다.

repository의 특정 브랜치에 push가 되었거나, PR을 요청하였을 때를 확인하여 코드 테스트 및 통합을 할 수 있도록 합니다.

2. CD 단계에서,

공유 repository에 통합된 코드가 CI 단계를 마쳤다면 해당 코드는 배포할 준비가 되었습니다. 이 코드를 자동으로 배포하여 사용자는 항상 최신 버전의 서비스를 사용할 수 있게 됩니다. 배포를 자동화 함으로써 일일이 deploy하지 않아도 되며, 배포보다 개발에 집중할 수 있게 됩니다.

하지만, Delivery와 Deployment는 약간 다릅니다.

• 지속적 제공 (Continuous Delivery)
  - CI를 마치고 릴리즈가 가능한 상태라면 배포까지 자동으로 해주는 것
• 지속적 배포 (Continuous Deployment)
  - CI를 마치고 릴리즈가 가능한 상태라면 사람의 검증을 통해 수동으로 배포하는 것
  

3. CI/CD 툴 결정

CI/CD 툴은 주로, Jenkins, Github Action, CircleCI,TeamCity 등등.. 을 사용한다고 합니다. 여러개가 있는데, 저는 Github Action을 사용하여 프론트엔드 CI/CD 를 구축해 볼 예정입니다.

Github Action 이란?

Github Action은 Github에서 제공하는 CI/CD 툴입니다. 주로 개발 코드를 Github에서 관리하기 때문에 Github에 등록된 Repository 라면 CI/CD 관리가 정말 쉽습니다.

Repository에서 어떤 이벤트가 발생했을 때 실행할 작업을 설정할 수 있습니다.

• 누군가 PR을 생성하였다면 코드 변경분에 대하여 테스트
• 누군가 develop 브랜치에 push 하였다면 빌드하고 배포
• 등ㄷ등....

Github Action 공식문서
자세한 GithubAction 사용법

저의 경우는, 정식 릴리즈 전 서비스 프로토타입을 배포하기위해 develop 브랜치에 push 또는 PR이 들어오게 되면 코드에 대해 검증을 하고 호스팅 환경으로 deploy 하는 것 까지 구축하려 합니다.

4. 마치며

이 글을 작성하면서 CI/CD에 대한 기초 개념은 확실히 잡혔습니다. 필요성도 더더욱이요. 코드 변경이 있을 때 마다 일일이 명령어를 입력하여 빌드하고 테스트 하고 배포 .. 정말 지옥일 것 같았거든요 😅 CI/CD를 잘 구축하여 배포 상황에서 오류를 최소화 하고 문제 상황을 잘 해결할 수 있도록 노력해야 될 것 같습니다.!!

다음 글에는, 실 배포 과정을 담아보려 합니다. 프로젝트가 Next.js 프로젝트 이기 때문에 SSR 환경을 지원하는 배포 환경을 알아보고 고른 뒤, Github Action 으로 빌드, 배포 과정을 자동화 해보려 합니다.!! 추후에는 테스트도 ...

공부하며 작성한 글이기 때문에 부족한 부분이나 궁금한 점이 있으시다면 댓글 자유롭게 남겨주세요 😊 감사합니다!

출처

• https://jud00.tistory.com/entry/CICD%EB%9E%80-%EB%AC%B4%EC%97%87%EC%9D%BC%EA%B9%8C
• https://seosh817.tistory.com/104
• https://kih0902.tistory.com/52
• https://jujeol-jujeol.github.io/2021/10/29/Github_Action%EC%9D%84_%EC%9D%B4%EC%9A%A9%ED%95%9C_%ED%94%84%EB%A1%A0%ED%8A%B8%EC%97%94%EB%93%9C_%EB%B9%8C%EB%93%9C_%EB%B0%8F_PR%EC%8B%9C_%ED%85%8C%EC%8A%A4%ED%8A%B8_%EC%9E%90%EB%8F%99%ED%99%94/
• https://wooncloud.tistory.com/79