어쩌다 글을 쓰게 됐을까?
서버 배포를 끝내고 신나게 뒹굴거리면서 놀다 한 통의 디스코드 문자가 오게됐다.
??? : 요한아, 이거 백엔드쪽 pr merge 했으니까 빌드하고 배포해줘
Ops 파트를 맡은 나는 당연히 해야되는 일이라 생각하여 빌드와 배포를 마치고 다시 신나게 뒹굴기 시작했다. 근데 위와 같은 문자가 몇 주째 계속 왔고
bastion 접속 -> 메인 서버 접속 -> sudo su -> yarn build -> yarn pm2 kill -> yarn pm2 start긴 시간은 아니였지만 2분,3분걸리는 무지성 반복적인 작업으로 제대로된 휴식을 즐기지 못해 화가 난 나머지 나 대신 해줄 사람없나하고 열심히 찾아보다가 CICD라는 것을 알게되었고 그것에 대한 개념들만 간단하게 공유하려고한다.(사실 위의 이야기의 절반은 지어낸 이야기다)
CI란?
빌드, 테스트의 자동화라고 할 수 있다. 지속적 통합(Continuous Integration)을 의미하며, CI를 잘 구현했다면 프로젝트의 코드를 수정 -> 깃허브에 업로드 -> 그 작성한 코드의 변경사항들을 빌드 및 테스트를 하여 그것이 성공했다면 리포지토리에 통합되는 식으로 진행되기에 코드의 신뢰성을 좀 더 높일 수 있다.
CD란?
배포 자동화 과정라고 할 수 있다. 지속적 배포(Continuous Deployment)를 의미하며 코드의 변경이 CI등의 파이프라인의 단계들을 모두 거쳐 성공적으로 통과 된다면 해당 변경 사항이 리포지토리등에 자동 배포됩니다.
하루에 한 번, 두 번 배포한다면 이런 CI/CD가 없어도되겠지만 프로젝트를 배포하고, 서비스하다보면 많게는 하루에 수십 번도 배포가 되기때문에 꼭 필요한 과정입니다.
적용 전과 후가 어떻게 다를까?
적용 전
- 개발 후, 각자의 개발 브랜치에 코드를 push 합니다.
- 각자의 코드를 git에 올리고 merge합니다.
- 이후 pull을 받고 다시 작업을 하는데 에러가 나는 상황 발생.
- 어느부분에서 에러가 나는지 정확히 알지 못하기에 찾기 힘듭니다.
- 어찌저찌 에러 해결했으면 배포를 시작. 하지만 배포도 개발자가 직접 배포과정을 수동으로 진행해야하기 때문에 많은 시간을 소요합니다.
코드의 양이 적다면 금방금방 찾을 수 있겠지만 수 백줄의 단위라면 음.. 상상도 하기 싫네요.
적용 후
- 개발 후, 각자의 개발 브랜치에 코드를 push합니다.
- 각자의 코드를 git에 올리면 그게 Trigger되어 CI서버에서 알아서 Build, Test 등을 실행하고 결과를 전송합니다.
- CI 실패 => 오류 메세지를 읽고 오류를 수정합니다.
- CI 성공 => CD서버에서 알아서 Deploy 과정을 수행합니다.
이런식으로 반복적인 행동들을 간편하게 빌드,테스트,배포까지 진행할 수 있다. 이런 CI/CD 를 진행할 수 있는 툴은
- Git Action
- Jenkins
- Argo CD
- AWS Code Series
등등 여러가지 툴이있으며 자신의 프로젝트와 맞는 툴을 사용하면 된다.
다음 글은 내가 프로젝트에서 AWS Code 시리즈를 사용하여 CI/CD 를 어떤식으로 적용하였는지 적어볼려고한다.
참고
