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