✏️ CI/CD에 대해 알아보자 With Github Actions

박상민·2024년 10월 1일

CI/CD github actions 업무 자동화

개념 정리!

목록 보기

18/18

⭐️ 서론

나의 이번년도 공부 목표 중 하나는 CI/CD이다.
CI/CD 무엇인지는 조금이나마 알고 있다. 3월쯤에 간단히 작성한 글도 있고, 프로젝트에 적용을 고민하기도 했었기 때문이다.

이전에 작성했던 CI/CD
https://velog.io/@pp8817/CICD란

그러나 프로젝트에는 적용하지 못했고, 한동안 이론과 AWS Cloud 공부를 하다보니 실무로 적용할 경험이 없다보니 CI/CD 공부가 점점 밀리는 것이 느껴졌다.
이를 깨달은 지금 CI/CD를 자세히 정리하고, 사용할 툴을 정해 혼자서라도 프로젝트에 적용시켜보려고 한다.

⭐️ CI/CD?

CI(Continuous Integration): 지속적인 통합
CD(Continuous Delivery or Deployment): 지속적인 제공/배포

CI/CD는 반드시 같이 사용해야 되는 개념은 아니다.
CI/CD를 소개하는 글, 영상을 보면 둘은 항상 묶여있길래 하나의 개념인줄 알았다.
그러나 CI, CD는 자동화를 통해 업무 속도의 향상을 돕는다는 것은 같지만, 자동화의 분야가 다르다. 이는 차차 뒤에서 소개할 예정이다.

📌 CI(Continuous Integration)

CI는 Continuous Integration. 즉, 지속적인 통합이라는 의미이다.

지속적인 통합?

어플리케이션의 새로운 코드 변경 사항이 정기적으로 빌드 및 테스트 되어 공유 레포지토리에 통합(Merge)되는 것을 의미

CI가 필요한 환경 조건

다수의 개발자가 형상관리 툴을 공유하여 사용하는 환경
- 형산관리 툴(Git, SVN 등)은 대부분의 개발자가 사용을 한다.
  지속적으로 서비스해야 하는 어플리케이션이나 현재 개발중인 어플리케이션은 기능 추가 시마다 commit, PR 등을 날려 Repository에 버전 업데이트를 한다.
  다수의 개발자가 한 팀으로 작업할 경우, 공유 Repository에 수많은 커밋이 쌓이게 된다. 그럴 때마다, 기능별로 빌드/테스트/병합까지 하려면 상당히 번거롭다.
  이런 상황에서, 자동화된 빌드&테스트는 원천 소스 코드의 충돌 등을 방어하는 이점을 제공할 수 있다.
MSA(Micro Service Archietecture) 환경
-IT 업계에 떠오른 아키텍처 모델
- 기존의 어플리케이션이 모든 기능을 포함하는 하나의 거대한 서비스였다면, MSA는 작은 기능별로 서비스를 잘게 쪼개어 개발하는 형태를 의미한다.
  MSA 환경에서는 대부분 Agile 방법론(소규모 기능 단위로 빠르게 개발 & 적용을 반복하는 개발방법론)이 적용되기 때문에, 기능 추가가 매우 빈번하게 발생한다.
  또한, 작은 micro service의 긴밀한 동작 테스트도 중요해진다.
  이런 상황에서, CI의 적용은 기능 충돌 방지 등의 이점을 제공할 수 있다.

CI의 핵심 목표

버그를 신속하게 찾아 해결
소프트웨어의 품질을 개선
새로운 업데이트의 검증 및 릴리즈의 시간을 단축시키는 것

📌 CD(Continuous Delivery/Deployment)

CD는 Continuous Delivery & Continuous Deployment 두 용어의 축약어이다.
해석하자면 지속적인 서비스 제공 혹은 지속적인 배포라는 의미이다.

Continuous Delivery

공유 Repository로 자동으로 Release 하는 것

Continuous Deployment

Production 레벨까지 자동으로 deploy 하는 것

정리하자면, CI가 새로운 소스코드의 빌드, 테스트, 병합까지를 의미했는데, CD는 개발자의 변경 사항이 Repository를 넘어, 고객의 Production 환경까지 릴리즈 되는 것을 의미한다.

CI에서 예로 든 MSA와 같은 환경에서 Agile 방법론이 적용될 경우, 서비스의 사용자는 최대한 빠른 시간 내에 최신 버전의 Production을 제공받을 필요가 있다.
이런 경우 소프트웨어가 언제든지 신뢰 가능한 수준의 버전을 유지할 수 있도록 support 하는 것이 CD라고 할 수 있다.

이는 서비스의 개발팀과 비즈니스팀 간의 커뮤니케이션 부족 문제를 해결해 주고, 개포에 이르기까지의 노력을 최소한으로 단축시켜 준다는 이점을 제공한다.

📌 일반적인 CI/CD 툴

CI/CD 툴은 팀이 개발, 배포, 테스트를 자동화하도록 지원한다.

Jenkins: 단순 CI 서버에서 완전한 CD 허브까지 모든 것을 처리하도록 설계된 툴
Github Actions
Tekton Pipelines: 표준 클라우드 네이티브 CI/CD 경험과 컨테이너를 제공하는 쿠버네티스(k8s) 플랫폼을 위한 CI/CD 프레임워크이다.
Spinnaker: 멀티클라우드 환경을 위해 구축된 CD 플랫폼
GoCD: 모델링 및 시각화에 중점을 둔 CI/CD 서버
Concourse: 지속적인 오픈소스 작업 툴
Screwdriver: CD용으로 설계된 빌드 플랫폼
GitLab, CircleCI ...

CI/CD 툴 선택
나는 Jenkins와 Github Actions 중 어떤 툴을 사용할까 고민했다.
Jenkins는 전세계적으로 가장 많이 사용하는 툴이고, 전통 강자이다.
Github Actions는 Jenkins에 비해서는 인기가 덜하지만 CI/CD 툴 시장 점유율 2위이고, 클라우드로 동작하기에 별도의 서버가 필요없다.

고민을 했지만 아래 다른 분이 작성하신 CI/CD 툴 비교를 보고 Github Actions를 사용하기로 결정했다.

Github Actions으로 결정한 이유

별도의 설치가 필요없다.
Public Repository에 한해서 무료이다.
초기 설정이 간단하다.

물론 아직 연습 단계이기에 툴은 별로 중요하지 않다고 생각한다. 결국 중요한 것은 CI/CD 파이프라인을 올바르고 효율적으로 구축하는 것이라고 생각하기 때문이다.
Github Actions를 통해 CI/CD 파이프라인 구축을 실습해보고 Jenkins 또한 사용해볼 예정이다.

📌 Github Actions

공식 문서 가이드: https://docs.github.com/ko/actions/writing-workflows/quickstart
도움이 되는 템플릿: https://github.com/actions/starter-workflows

Github Actions Core 개념
Github Action을 이해하기 위해서 알아야 하는 개념은 Workflow, Event, Job, Step, Action, Runner 등이 있다.

우선 이해를 위해 공식 가이드에서 예시로 제공되는 github-actions-demo.yml 파일을 읽고 시작하자.

yml

name: GitHub Actions Demo
run-name: ${{ github.actor }} is testing out GitHub Actions 🚀
on: [push]
jobs:
  Explore-GitHub-Actions:
    runs-on: ubuntu-latest
    steps:
      - run: echo "🎉 The job was automatically triggered by a ${{ github.event_name }} event."
      - run: echo "🐧 This job is now running on a ${{ runner.os }} server hosted by GitHub!"
      - run: echo "🔎 The name of your branch is ${{ github.ref }} and your repository is ${{ github.repository }}."
      - name: Check out repository code
        uses: actions/checkout@v4
      - run: echo "💡 The ${{ github.repository }} repository has been cloned to the runner."
      - run: echo "🖥️ The workflow is now ready to test your code on the runner."
      - name: List files in the repository
        run: |
          ls ${{ github.workspace }}
      - run: echo "🍏 This job's status is ${{ job.status }}."

Workflow
- 최상위 개념
- 여러 Job으로 구성되고, Event에 의해 트리거될 수 있는 자동화된 프로세스
- Workflow 파일은 YAML으로 작성되고, Github Repository의 .github/workflows 폴더 아래에 저장된다.
Event
- Workflow를 Trigger(실행)하는 특정 활동이나 규칙
- 예를 들어 다음과 같은 상황을 사용할 수 있다.
  - 특정 branch로 push
  - 특정 branch로 PR(Pull Request)
  - 특정 시간대에 반복(Corn)
  - Webhook을 사용해 외부 이벤트를 통해 실행
    
    자세한 내용: Events that trigger workflows
Job
- Job은 여러 Step으로 구성되고, 가상 환경의 인스턴스에서 실행된다.
- 다른 Job에 의존 관계를 가질 수 있고, 독립적으로 병렬 실행도 가능하다.
Step
- Task들의 집합으로, 커맨드를 날리거나 action을 실행할 수 있다.
Action
- Workflow의 가장 작은 블럭(smallest portable building block)
- Job을 만들기 위해 Step들을 연결할 수 있다.
- 재사용이 가능한 컴포넌트
- 개인적으로 만든 Action을 사용할 수도 있고, Marketplace에 있는 공용 Action을 사용할 수도 있다.
  
  Github Marketplace, Github Actions Repository
Runner
- Github Action Runner Applicatin이 설치된 머신으로, Workflow가 실행될 인스턴스
- Github에서 호스팅해주는 Github-hosted runner와 직접 호스팅하는 Self-hosted runner으로 나뉜다.
- Github-hosted runner는 Azure의 Standard_DS2_v2로 vCPU 2, 메모리 7GB, 임시 스토리지 14GB
  
  Self-hosted runners

출처

박상민

스프링 백엔드를 공부중인 대학생입니다!

이전 포스트