회사에서 참여하게 된 프로젝트로 인해 CI/CD를 공부 해야겠다는 생각이 들었다.
프로젝트에서 나는 A 서비스를 제공하는 웹서버(간단하게 A서버라고하자)를 구축하고 수정해야 했다. ( 물론 내가 다하진 않는다. 나의 기여도는 개미 눈물만큼? )
근데 A 서비스 서버는 대략 8개 ..? 정도 되는 서비스로 이루어져 있었다. (자세히는 모르지만 이게 MSA?)
그래서 소스코드를 수정하고 테스트 서버에서 수정사항이 반영됐는지 확인하기 위해서는 1번 서비스에서 war 파일을 생성해서 옮기고…
2번 서비스에서는 jar 파일을 생성해서 올리고…
엔진엑스를 다시 실행시키고 ..
어쩌구 저쩌구 하는 상당히 복잡한 과정 ,, 워드로 두, 세장이 작성될 만큼에 서버 구축 과정이 다시 수행되어야 한다.. ( 물론 생략하는 부분도 생기겠지.. )
아무튼 이걸 설명을 듣고 이게 맞나..
자동화 되는 게 있을 거 같은데 라는 생각을 하게 되었고 그게 CI/CD 의 과정이라는 것을 깨닫게 되었다.
+) 아무래도 프로젝트가 너무 커서 프로젝트에는 ci/cd를 적용하지는 못할 듯 싶다..
빌드, 테스트의 자동화
CI/CD의 CI 는 “지속적인 통합”을 의미한다.
코드에 변경사항이 있을 경우 자동으로 빌드, 테스트 되어 공유 레포지토리에 통합된다.
마틴 파울러는 CI의 4가지 규칙이 있다고 언급하였다. 규칙은 다음과 같다.
CI 과정이 자동화로 수행된다면 Git에 push, merge를 하게 될 경우 정상적으로 빌드가 되는 지 테스트 과정을 자동으로 확인하고 빌드가 성공적으로 이루어지면 수정된 코드가 받아들여지게 된다.
배포의 자동화
CD는 두가지 의미가 있다.
지속적인 제공과 지속적인 배포이다.
지속적인 제공(Delivery)는 CI 과정을 거치게 되면 레포지토리에 자동으로 업로드 되는 것을 말한다. 그렇게 레포지토리에 업로드된 코드가 문제가 없는지 검증 후에 수동으로 배포해야한다.
여기서 더 나아간 게 지속적인 배포 (Deployment)이다.
이게 바로 내가 하고 싶은 작업이다.
레포지토리에 수정이 반영된 버전으로 서버에 자동으로 배포하는 과정을 말한다.
Jenkins, Buildkite, Github Actions, GitLab CI/CD, Bitbucket Pipelines, Circleci 등이 있다. 이 중에서 가장 많이 사용되는 것은 Jenkins이다.
📎 참고 링크
응원해요~