사이드 프로젝트 진행 전 기술 스텍을 정하기 위한 나의 생각을 정리한다.
세 번째로 CI/CD 툴을 무엇을 사용 할 것인가에 대해 정리해본다.
CI/CD가 뭔데 ?
CI (지속적 통합) : 개발자들이 작성한 코드를 자동으로 빌드하고 테스트하는 과정으로 새로운 코드 변경 사항이 이전 코드와 충돌할 가능성이 있는지 미리 확인하여 문제를 방지할 수 있도록 하는 것을 말한다.
CD (지속적 제공, 지속적 배포)
- 지속적 제공 : CI의 작업을 거친 후, 레포지토리에 자동으로 업로드 되는 것
- 지속적 배포 : AWS와 같은 서비스를 통해 배포를 자동화 한 것
나름의 정의를 가져와서 적었지만 사실 지속적 제공에 관한 정의는
애매모호하고 명확한 이해가 안되는 것 같다.
깃허브에 특정 브랜치(Release)와 같은 공간에 CI가 마무리된 작업들을 모아두고 QA와 같은 테스트를 진행하고 수동 배포하는 것을 의미하는건지
이것이 맞다면 QA테스트를 하려면 개발 서버와 같은 별도 공간에 배포를 해야할텐데 그럼 이건 지속적 배포가 아닌지
그게 아니라면 말 그대로 특정 브랜치(Release)와 같은 공간에 CI가 마무리된 작업들을 모아두는 행위 자체만을 이야기 하는것인지 매우 어렵다..ㅎ
주변에도 물어봤는데 의견이 생각보다 여러가지 인 것 같다.
배포하는 환경에 따라서 분리해서 생각하는 경우가 있었다.
스테이징과 같은 브랜치를 두고 QA를 위한 배포는 지속적 제공
스테이징에서 테스트가 끝난 후 운영에 자동 배포 하는 경우는 지속적 배포
쉽게 말해 운영을 위한 배포가 아닌 다른 목적의 배포는 지속적 제공이다 라는 의견
CI/CD 파이프라인을 자연스럽게 봤을 때는 지속적 배포가 좀 더 와닿는 것 같고
CD를 어떻게 구성하느냐에 따라서 다른 것 같으니 지속적 배포로 이해 해보려고 한다.
그래서 어떤 툴로 할껀데?
우선 CI/CD 툴이 여러가지 있겠지만 나는 비교적 래퍼런스가 많고 가장 많이 이용하는
Jenkins와 GitHub Actions을 후보에 두고 비교 해보려고 한다.
Jenkins / GitHub Actions 뭐가 다른데 ?
우선 Jenkins 와 GitHub Actions의 차이점을 검색했을 때 가장 대표적으로 나오는 표를 가져와봤다.
| Jenkins | GitHub Actions |
|---|---|
| 서버 설치가 필요 자체 서버에서 사용하기 때문에 비교적 성능 좋음 | 클라우드에서 동작하므로 어떤 설치도 필요 없음 클라우드를 통해서 동작하기 때문에 비교적 성능 낮음 |
| 작업이 동기적으로 일어나므로, 제품을 시장까지 배포하는 데에 더 많은 시간이 소요됨 | 비동기 CI/CD 가능함 |
| 계정과 트리거에 기반하고 있으며 GitHub 이벤트를 처리할 수 없음 | 모든 GitHub 이벤트에 대해 GitHub Actions을 제공하고 있으며 많은 언어와 프레임워크도 지원함 |
| 환경 호환성을 위해 Docker 이미지에서 동작해야 함 | 모든 환경에 호환됨 |
| 캐싱 기법을 위해 플러그인을 제공하고 있음. | 캐싱이 필요하다면 직접 캐싱 메커니즘을 작성해야 함 |
| 공유할 수 있는 기능을 제공하고 있지 않음 | GitHub 마켓플레이스를 통해 공유할 수 있음 |
그래서 넌 뭘 쓰고 싶은데 ?
결론 : GitHub Actions
나는 젠킨스를 사용해 본 경험은 없고 깃헙 액션만 사용 했던 경험이 있다.
나의 경험을 토대로 좀 더 와닿는 내용으로 깃헙 액션의 장점을 작성해 본다.
1. 별도의 서버가 필요 없다. 즉 비용이 사실상 나가지 않는다 ( 프로젝트 규모가 작은 경우 한정 )
현재 근무 하고 있는 회사의 프로젝트의 경우 한 회사에서 내부적으로 사용하는 프로젝트 또는 B2B 서비스 이지만 아직까지 고객이 많지 않은 서비스로 이뤄져 있어서 배포가 잦은 프로젝트가 아니며 테스트 코드 문화가 아직 자리잡지 않아 빌드 시간도 오래 걸리지 않는다.
또한 QA 직무의 인원이 존재하지 않기 때문에 별도의 QA를 위한 서버도 존재하지 않아서 더더욱 배포 횟수가 줄어든다.
이와 같이 규모가 작은 프로젝트들의 경우 깃헙 레포를 프라이빗으로 만들었다고 하더라도 깃헙 액션이 제공 해주는 무료 플랜 ( Storage 500MB, 월별 2000분 )으로도 아직까지 한 번도 비용을 지불 했던 적이 없다.
하지만 젠킨스를 사용 할 경우 아무리 작은 프로젝트라도 클라우드 서버를 사용하던 온프레미스를 사용하던 서버 관리 비용이 지출된다.
상황에 따라서 금전적인 비용보다 성능이 중요해지는 순간이 올 수 있다고 생각한다. 하지만 현재 진행하려는 것은 포트폴리오를 위한 비교적 작은 프로젝트이기에 성능이 부족해서 생산성이 떨어지거나 불편함을 느낄 경우는 정말 희박한 경우이며 만약 발생한다면 우리 프로젝트가 의도치 않게 포트폴리오보다 높은 가치를 가지게 됐다는 것이니 기쁜마음으로 전환해도 늦지 않는다고 생각한다.
2. 다른 사람이 잘 만들어 놓은 워크 플로우 파일만 훔쳐오면 큰 무리 없이 CI/CD 파이프라인이 구축된다.
젠킨스는 표에 나와있는대로 설정을 공유 할 수 없지만 오랜 기간 사용해온 툴이기 때문에 방대한 양의 래퍼런스는 존재한다.
하지만 설정이 복잡한 만큼 내 상황에 맞는 래퍼런스를 찾는 과정 그리고 찾았다고 하더라도 딱 들어맞지 않는 한 오류를 잡아가면서 구축해야된다는 점이 매우 어렵다고 생각한다.
깃헙액션은 내가 사용 할 비슷한 워크 플로우 파일을 어디서든 구해와서 비교적 간단한 문법들만 이해하고 있다면 내 상황에 맞게 커스텀하여 매우 빠른 시간안에 구축이 가능하다.
결국 이 부분의 내용도 다른 글에서 이야기 했던 우리가 진행하는 프로젝트의 목적에 집중하려면 부가적인 인프라와 같은 부분은 가능한 간단하고 비용이 적게 드는 방향으로 채택했다.
3. 관리 포인트가 깃허브 한 곳으로 밀집된다.
이것이 꽤나 큰 장점이라고 생각한다. 우리는 그리고 현재 대부분의 프로젝트는 깃허브에서 관리하게 된다.
그런데 젠킨스를 통한 CI/CD를 구축 할 경우 우리는 젠킨스 대시보드와 같은 페이지를 또 봐야 하고 관리를 해주어야 한다.
하지만 깃헙 액션에 경우 깃허브 PR, 특정 코멘트 등 깃허브의 이벤트로 인한 CI를 구축할 수 있으며 파이프라인 자체를 수정하거나 오류가 있을 때도 우리는 깃허브 페이지 하나만 보면 된다.
물론 찾아보니 젠킨스 대시보드가 깃헙액션에 비해 UI 적으로 뛰어나다는 부분도 봤던 것 같다. 하지만 그렇다고 깃헙 액션이 못 봐줄 수준이라고 느낀적은 없으며 그 관점에서 봤을 때 페이지를 넘나 들며 다른 곳에서 관리하는 것보다 한 페이지 안에서 관리 하는 것이 개인적으로 매우 편리했다.
