[DevOps/번역글] Github Actions냐 Jenkins냐! 올바른 선택을 해봅시다

시작하기에 앞서, 본 포스트는 "Github Actions or Jenkins? Making the Right Choice for You" 를 읽고 한국어로 정리하기 위해 쓴 번역 글입니다. 오역이 있거나 미숙한 번역이 있을 수 있습니다. 많은 지적질 부탁드립니다!

지난 몇 년간, DevOps는 소프트웨어 생명 주기에 필수적인 부분이 되었습니다. 이는 곧 현재 주도적인 많은 DevOps 도구와 경험을 만들었습니다. CI/CD 프로세스를 지원하는 다양한 도구를 찾을 수 있겠지만, Jenkins와 GitHub Actions는 그 중에서도 압도적으로 우뚝 선 도구입니다.

이 글에서는 GitHub Actions와 Jenkins를 비교해서 올바른 선택을 할 수 있도록 인사이트를 제공하고자 합니다.

Jenkins와 GitHub Actions 개론

Jenkins로 시작해볼까요? 다음은 Jenkins의 간략한 소개입니다.

Jenkins는 무료 오픈 소스 자동화 서버입니다. Jenkins는 빌드, 테스트, 배포와 관련된 소프트웨어 개발 부분을 자동화하고, 지속적인 통합과 지속적인 배포를 제공하는 데 도움을 줍니다. - Wikipedia

GitHub Actions도 마찬가지로 GitHub에서 SaaS 제품으로 제공하는 최신 기능입니다.

GitHub Actions를 사용하면, Linux, macOS, Windows 를 포함한 모든 플랫폼에서의 프로젝트 빌드, 테스트, 배포를 쉽게 자동화할 수 있습니다. 여러분의 워크플로우를 컨테이너나 가상 머신에서 실행하세요. - GitHub blog

Jenkins에서 GitHub Actions로의 전환을 결정하기 전에, 어떤 경우에 이러한 고민을 해야 하는지 먼저 생각해 볼 필요가 있습니다.

Jenkins를 떠나야 할까요?

여러분의 프로젝트가 Jenkins를 잘 사용하고 있고, 그 어떤 문제도 겪고 있지 않다면, Jenkins를 쭉 사용하는 것이 좋습니다.

반면, GitHub을 소스 관리 플랫폼으로 이용하고 있으며 Jenkins 설정 등에 그다지 만족하지 못하거나 다른 더 나은 대안을 찾고 있다면 GitHub Actions가 여러분의 첫 번째 고려 대상이 될 수 있습니다.

GitHub Actions는 GitHub이 완전 관리하는 서비스이기 때문에, 워크플로우를 실행하기 위해 인프라를 어떻게 확장할지, 어떻게 운영할지 몰라도 됩니다.

필자는 이러한 이유에서 Jenkins를 떠났습니다. 필자의 CI/CD 파이프라인을 통해 어떤 일이 일어나고 있는지 완전히 통제하고 있지 못했기 때문입니다.

Jenkins를 사용하면서 필자가 겪었던 문제는 이렇습니다.

• 플러그인을 항상 최신 상태로 유지해야 하는 것.
• 단일 Jenkins 서버를 이용한 빌드는 빌드를 실행하지 않더라도 비용이 많이 듦.
• 동시 빌드 환경에서 일관성을 제공하지 않음.
• 때때로, 업데이트를 해주지 않으면 정상 동작하지 않는 여러 플러그인에 의존해야 했음.

위와 같은 문제 중 일부는 Jenkins에서 해결이 가능하다는 점을 알고는 있었지만, 이미 충분히 겪었고, Jenkins를 떠나 관리형 플랫폼으로 이동하게 되었습니다.

이러한 사항들이 여러분에게 해당하는 경우, GitHub Actions로 전환할 것을 고려해보면 좋겠습니다. 이제 이 전환을 고려해보기 위해 GitHub Actions에서 제공하는 기능을 살펴 보겠습니다.

설치의 간편함 - 모든 것은 GitHub에서 관리한다.

GitHub Actions가 Jenkins 에 비해 가장 첫 번째로 갖는 장점은 GitHub Actions의 설정이 더 쉽다는 것입니다. GitHub Actions는 클라우드에서 작동합니다. 물론 Runner라 부르는 컴포넌트를 로컬에서 실행할 수도 있습니다. 반면에 Jenkins는 공식적으로 관리하는 서비스를 제공하고 있지 않습니다.

그리고 Jenkins를 운용하는 타사 제품을 사용하기엔 보안적인 측면에서 위험하다고 생각했습니다.

이러한 이유로 Jenkins 서버는 설치가 필요하지만, GitHub Actions는 그렇지 않습니다. 결과적으로 GitHub Actions의 설정 과정이 훨씬 쉽습니다. 게다가, GitHub Actions는 일련의 docker run으로 구성됩니다. 즉, docker build와 docker run 만을 필요로 합니다. 따라서, 실행과 디버깅이 매우 쉽습니다.

GitHub과의 긴밀한 결합 - 원활하게 이어지는 경험

처음에는 Jenkins가 GitHub Actions보다 더 유연해보였습니다. Jenkins는 계정과 트리거를 기반으로 하고 있으며, 빌드를 중심으로 동작합니다. 이는 GitHub 이벤트를 준수하고 있지 않습니다. 반면에 GitHub Actions는 모든 GitHub 이벤트를 통해 수행될 수 있습니다.

GitHub Actions는 많은 언어와 프레임워크를 지원하고 있고, YAML로 작성할 수 있습니다. 따라서 일반적인 코드를 작성하듯 편집, 재사용, 공유, 포킹할 수 있습니다.

레포지토리를 포킹하면 작업이 자동으로 포킹되기 때문에 GitHub과 함께 사용하는 것이 매우 쉽게 느껴집니다. 이를 통해서 프로젝트를 매우 효율적으로 테스트하고 빌드할 수 있으며, 개발자 친화적으로 실행할 수도 있습니다. 또한 GitHub API에 쉽게 접근할 수 있으므로 개발자들에겐 더 인기가 있습니다.

(역주 : 원문에 소개된 Bit에 관한 내용은 생략했습니다.)

코디네이터와 빌드 노드 - 확장을 위한 빌드

기본적으로 GitHub Actions는 Jenkins가 제공하는 순차 파이프라인 패턴이 아닌, 마스터-슬레이브(코디네이터 및 빌드 노드) 패턴을 따릅니다.

그러나, Jenkins에서도 유사한 설정이 가능합니다만, 이 방식으로 설정하고 실행하기 위해선 추가적인 노력과 지식이 필요하다는 점에 유의해주세요.

작업을 실행하기 위해 함께 동작하는 여러 개의 GitHub Actions 구성 요소를 소개한 이미지(출처 : 원문)

Jenkins를 사용하는 경우, 초기 설정대로 실행하면, 배포 파이프라인의 각 단계를 동기적으로 실행합니다. 예를 들어, 단위 테스트, 통합 테스트 및 몇몇의 Sonar 검증을 실행해야 하는 경우, 단일 서버 환경에서 실행해야 합니다. 서버에서 사용 가능한 자원의 양에 따라 실행이 지연되는 경우도 있을 수 있습니다. 또한 파이프라인을 안정적으로 구축하기 위해 추가적인 노력도 필요합니다. (원문은 필요가 없다고 소개하는데, 흐름상 필요하다는 의미로 사용한 것으로 보여 이렇게 의역했습니다. 혹시라도 원문 내용과 다를 경우 댓글 부탁드립니다!)

GitHub Actions를 사용하면, 이 작업들을 위 이미지처럼 병렬화 할 수 있습니다. 예를 들면, Job 1은 단위 테스트와 통합 테스트를 진행하는 단위가 될 수 있고, Job 2는 Sonar 검증 과정이 될 수 있습니다.

요약

지금까지 GitHub Actions가 Jenkins에 비해 갖는 장점을 비판적으로 알아보았습니다. 더욱이 GitHub Actions는 GitHub 마켓플레이스에 출시되는 수 천 개의 GitHub Actions를 보면, Jenkins보다 빠르게 성장하고 있음을 알 수 있습니다. 거기다 GitHub Actions 전용 레포지토리가 있는 곳에서도 관련 커뮤니티가 성장하고 있습니다. 이는 많은 사람들이 GitHub Actions에 호감을 갖게 되었다는 것을 의미합니다.

이제 마무리 요약을 위한 비교를 살펴보겠습니다.

Jenkins	GitHub Actions
서버 설치가 필요	클라우드에서 동작하므로 어떤 설치도 필요 없음
작업이 동기적으로 일어나므로, 제품을 시장까지 배포하는 데에 더 많은 시간이 소요됨	비동기 CI/CD 가능함
계정과 트리거에 기반하고 있으며 GitHub 이벤트를 처리할 수 없음	모든 GitHub 이벤트에 대해 GitHub Actions를 제공하고 있으며 많은 언어와 프레임워크도 지원함
환경 호환성을 위해 Docker 이미지에서 동작해야 함	모든 환경에 호환됨
캐싱 기법을 위해 플러그인을 제공하고 있음.	캐싱이 필요하다면 직접 캐싱 메커니즘을 작성해야 함
공유할 수 있는 기능을 제공하고 있지 않음	GitHub 마켓플레이스를 통해 공유할 수 있음

하지만, 프로젝트에서 GitHub Actions을 사용할지 또는 Jenkins를 사용할지는 여러분에게 달려있습니다. 현재 GitHub Actions는 Public 레포지토리에 대해선 무료로 사용할 수 있습니다. 반면 Private 레포지토리의 경우 사용한만큼 지불해야 합니다.

GitHub Actions가 주로 유연성 덕분에 Jenkins보다 더 나은 선택이라는 것을 여러분이 캐치하셨기를 바랍니다. 새로운 프로젝트를 시작하거나 GitHub을 소스 관리 플랫폼으로 활용하고 있는 사람들에게는 GitHub Actions로 이동하는 것이 정말 쉽습니다.

GitHub Actions에 처음인 사람들을 위해 GitHub 문서는 한 단계 한 단계 정확한 내용을 제공하고 있습니다. GitHub Actions를 위한 워크플로우 문법은 여기에서 찾을 수 있습니다.

이 글을 읽는 동안 여러분이 즐거웠기를 바랍니다. 읽어주셔서 감사합니다!!

참고

• https://blog.bitsrc.io/github-actions-or-jenkins-making-the-right-choice-for-you-9ac774684c8
• https://docs.github.com/en/actions/learn-github-actions/migrating-from-jenkins-to-github-actions
• https://docs.github.com/en/actions/reference/workflow-syntax-for-github-actions

마무리

여기까지 따라오시느라 고생이 많으셨습니다. 만약 이 글이 도움이 되셨다면 글 좌측 하단의 하트❤를 눌러주시면 감사하겠습니다.

혹시라도 글에 이상이 있거나, 오역, 이상한 번역이 있거나, 이해가 가지 않으시는 부분, 또는 추가적으로 궁금하신 내용이 있다면 주저 마시고 댓글💬을 남겨주세요! 빠른 시간 안에 답변을 드리겠습니다 😊