CI/CD: 지속적 통합과 지속적 배포

지속적 통합(Continuous Integration, CI)과 지속적 배포(Continuous Delivery, CD)는 프로그래머들이 소프트웨어를 코딩하고 나서 이를 최종 배포까지 하는 과정에서 진해되는 일들을 말한다.

이러한 과정들을 "자동화" 한다는 의미로 사용된다.

먼저 CI는 지속적 통합, 소프트웨어들은 여러 프로그래머로 구성된 팀에 의해서 개발되는 경우가 많다.

보통 Git과 같은 버전 컨트롤 시스템을 사용해서 각자가 작업한 코드들을 출시할 결과물로 통합을 한다. 이 과정에서 각 구성원의 코드를 받아와 합치기 전에 코드에 문제가 없는지 확인하는 과정이 없으면 실제 서비스로 배포되고 나서 문제가 발생할 수가 있다. 

작성한 코드 자체에 결함이 있어서 오류가 날 수도 있고 다른 인원이 새로 작업한 코드와 엇갈리는 부분 때문에 코드를 다 합쳐봐야 발견할 수 있는 에러가 있을 수도 있다.

하지만 이러한 과정을 코드 테스트라는 과정을 거치는 것이 FM이고 이상적이라고 할 수 있지만 현실적으로는 어렵고 귀찮은 일이다. 

소규모 소프트웨어에서는 그럴 수도 있지만, 규모가 커질수록 사람이 수작업으로 테스트를 진행하는데에는 무리가 있다.

그리고 여러 사람이 작업함으로 인한 문제들을 방지하려면 이런 통합 작업을 수시로, 지속적 - continuous 하게 해야 하는데 때에 따라 이런 테스트 과정을 매번 거치기는 번거롭다.

그렇기 때문에 이러한 CI의 자동화를 구현해주는 다양한 도구와 서비스들이 있는 것이다.

 

CD는 지속적 "배포"이다. 배포란 소프트웨어를 코딩한 결과를 최종 사용자에게 넘겨주는, 실행 가능하도록 하는 단계를 말한다. 모바일 앱으로 치면 앱스토어에 올리는 거고 백엔드 서비스라면 코드를 배포용 파일로 빌드를 하고 그 빌드된 결과물을 서버에 전송한 다음에 커맨드로 실행까지 해주는 것 등을 말한다.

C, Couninuous가 붙는다는 것은 코딩을 마칠 때마다 지속적으로 해준다는 것을 말한다.

그래서 CI가 성공적으로 이뤄지고 나면 이 CD가 진행되는거라고 생각하면 된다. 

이 전반적 과정을 CI/CD라고 한다.

이러한 CI/CD 자동화에 관련된 툴을 제시하고자 한다.

먼저 설치형으로는 대표적으로 젠킨스가 있다.

윈도우, 맥, 리눅스에 모두 설치 가능하다.

젠킨스를 깔아서 실해아혐, 해당 컴퓨터나 서버의 주소로 크롬 등의 브라우저로 접속할 수 있는 웹사이트가 열린다. 서버의 아이피주소에, 젠킨스 기본 포트 8080으로 접속하고 지정해 둔 아이디랑 비밀번호를 입력하면 다양한 CI/CD 작업들을 세팅할 수 있는 페이지가 나온다. 

이 웹사이트가 CI/CD를 설정하기 위한 작업 콘솔이다.

매크로를 만드는 화면이 열린다고 생각하면 된다.

그리고 이전 단계들에서 문제가 없다면 실행되도록 설정한 다음 작업들에서 프로젝트를 배포용 파일로 빌드한 다음 원하는 폴더로 옮겨서 돌고 있던 서비스를 중지하고 이 파일로 새 서비스를 실행하는 명령어를 스크립트로 실행하도록 하는 것이다. 이제 개발자는 코딩을 마친 후 이를 Git에서 푸시하기만 하면 이걸 서버로 옮겨서 테스트하고 문제 없을시 빌드해서 배포하고 테스트 실패시 보고를 해주는것까지 젠킨스가 자동적으로 해준다.

이 과정은 터미널 보듯 젠킨스에서 진행해준다.

Travis CI나 Circle CI, Team City 같은 클라우드형 서비스도 있다.

Team City와 같은 종류는 젠킨스처럼 설치형으로도 쓸 수 있지만 기본적으로 클라우드로 컴퓨팅 공간을 제공하는데 여기서 자동화 작업들을 설정할 수 있다. 

사용방법들은 비슷하다. Github 등의 Git 저장소 계정과 연동을 하고 나서 레포지토리 중에 CI/CD를 진행할 프로젝트를 선택하고 거기서 자동화로 처리할 작업들을 세팅한다.

Travis로 예를 들자면, Github에 Node.js로 만든 프로젝트를 올려두면 이 저장소를 Travis랑 연동시킬 수 있다.

그 프로젝트 최상위 폴더에 .travis,yaml이란 파일을 만들고 거기에 Travis에서 지정한 형식대로 어떤 자동화 작업들을 진행할지 작성해두게 된다. 

지정한 브랜치에 푸시가 들어오면 코드를 Github로부터 Travis의 서버로 당겨와서 Node.js의 지정된 버전으로 테스트를 돌린 다음 성공이나 실패 여부를 이메일로 보내도록 한다. 이제 이 프로젝트를 그 브랜치에 푸시하면 테스트 결과를 메일로 받아볼 수 있게 되는 것이다.

클라우드 서버에서 테스트를 마치고 빌드를 한 다음 배포할 서버로 전송하는 기능으로 CD도 가능하다. 온프레미스 서버일 경우 파일들을 보낸다음 AWS의 기능들과 연동하거나, Heroku에 바로 올릴 수도 있다.

Heroku는 서버 설정할 필요 없이 코드만 커밋하면 알아서 웹사이트 API든 실행해주는 서비스이다. 이것을 PaaS라 한다.

이 클라우드 서비스들은 유료이거나 제한적으로 무료이다. 

개인적으로 가볍게는 무료로 이용할 수 있지만 상업용 규모로 넘어가면 이용료를 지불해야 한다. 

 

Github이나 Bitbucket, Gitlab 등에서 자체적으로 제공을 해준다.

많이 쓰이는 걸로 Github actions가 있다.

GitLab에도 CI/CD, Bitbucket에도 Pipelines라고 제공하는 서비스들이다.

Github에서 자기 프로젝트가 있는 레포지토리에 들어가보 상단에 재생버튼이랑 같으 Actions란 탭이 있다.

여기서 각 언어별로, 또는 AWS나 Azure 등의 배포처별로 소스코드를 빌드하고 테스트하고 배포 등을 할 수 있는 "워크플로우"들의 다양한 템플릿들이 있다.

여기서 필요한 것들을 골라서 원하는 매크로를 조립해도 되고 개발자가 직접 yml 파일로 작성해도 되고 다른 사람들이 작성해서 마켓플레이스에 올려놓은 워크플로우들을 다운받아서 쓸 수도 있다.

소스에 푸시되는 등 지정된 이벤트가 발생하면 깃헙에서 제공하는 클라우드 컨테이너 공간에서 이 빌다나 테스트, 슬랙 메시지 등의 작업들 그리고 배포 등이 진행이 된다. 

https://www.youtube.com/watch?v=UbI0Q_9epDM

참고자료