프로젝트를 진행하며 로컬에서 작업한 코드를 서버에 적용하려면 아래와 같은 과정이 필요했다.
- 로컬에서 작성된 코드를 빌드 및 테스트
- 로컬에서 Git 원격 저장소로 Push
- 원격 저장소에서 브랜치 Merg
- 개발 서버에서 Git 원격 저장소로부터 Pull
- 개발 서버 런타임 재실행
그렇게 어렵고 큰 일은 아니지만, 자고로 뛰어난 개발자가 되려면 항상 모든 일을 귀찮게 여기고 효율적으로 자동화할 수 있는 업무를 만들어야 한다고 들었다. 🥸
그래서 그냥 흘러듣기만 했던 CI/CD를 이참에 진행하는 외주 프로젝트에 적용해보았고, 그 과정과 CI/CD의 개념에 대해 알아보려고 한다.
CI/CD의 배경
개발자가 코드를 작성하고 빌드, 테스트까지 한 다음 배포를 하려면 꽤나 시간이 소요된다. 코드를 작성하는 일이야 개발자가 해야하는 일이지만 만약에 빌드와 테스트, 그리고 배포를 다른 누군가가 해준다면 개발자의 업무 부담은 훨씬 줄어들 것이다.
이를 위해 등장한게 CI/CD이다. 엄밀히 말하면 CI와 CD는 별개의 개념이지만 이 둘은 항상 붙어다녀서 거의 한 쌍으로 여겨진다. 두 개의 과정이 하나로 이루어지다보니 보통 CI/CD 파이프라인이라고도 한다.
CI (Continuous Integration)
지속적 통합을 의미하는 CI는 빌드와 테스트의 자동화 과정이다. 애플리케이션에 대한 새로운 코드 변경 사항이 정기적으로 빌드 및 테스트되어 원격 저장소에 통합하는 과정으로 구현된다.
여러 명의 개발자가 동시에 애플리케이션 개발과 관련된 코드 작업을 할 경우 충돌할 수 있는 문제를 줄일 수 있다.
CD (Continuous Delivery/Development)
지속적인 배포인 CD는 배포의 자동화 과정이다. Delivery와 Development는 공용으로 사용되므로 어떤 것으로 쓰는 상관없다.
CI의 과정에서 테스트까지 성공적으로 마쳤다면 실제 운영 서버 혹은 개발 환경에 바로 배포할 수 있게 구현된다. 특별한 문제가 발견되지 않으면 배포가 완료되고 로컬에서 작업한 애플리케이션이 바로 사용자가 사용할 수 있는 서버에 적용된다.
위 그림에서 빨간색 박스를 친 부분에 대한 과정을 수행하며 이 때 옵션과 상황에 따라 수동으로 배포하는 기능을 켤 수도 있다.
CI/CD 종류
CI/CD를 할 수 있게 만들어주는 많은 도구들이 있다. 그 중 대표적인 것들만 적어본다.
- Jenkins
- Github Actions
- Gitlab Runner
- CircleCI
- TravisCI
주의사항
사용하는 원격 저장소가 Public이냐 Private이냐에 따라 환경변수나 노출되지 말아야 할 secret 정보에 대해 조심해야 한다.
Github나 Gitlab 같은 경우에는 Public 원격 저장소에 아이디나 비밀번호와 같은 중요 키값이 들어가있으면 개발자에게 알람을 주거나 배포 거절될 수 있다.
그리고 배포 할 때 다운로드 되는 경로가 내가 원하는 경로와 다른 곳일 수 있어 필요하면 일일이 설정해줘야 하는 점도 있다.
결론
위 주의사항에도 불구하고 직접 개발자가 빌드/테스트 후 배포하는 것보다 CI/CD 도구들의 도움을 받는 것이 훨씬 효율적이고 에러도 덜 날 수 있다.
아무래도 컴퓨터는 거짓말을 하지 않으니, 내가 발견하지 못한 에러를 미리 발견해서 일일이 디버그 하는 일을 줄여주기도 한다!
다음에는 가장 최근에 사용한 Gitlab Runner를 사용하는 방법에 대해 적어보겠다.
