Github Actions 와 CI/CD 란?

CI / CD

CI 지속적인 통합(Continuous Integration)과 지속적인 배포(Continuous Deployment) 또는지속적인 전달(Continuous Delivery)을 의미한다. 소프트웨어개발과 배포 프로세스를 자동화하고 효율적으로 관리하는 개발 관행이다.

소프트웨어 개발에서 코드의 품질을 유지하고, 변경 사항을 빠륵 ㅔ배포하며, 신속한 피드백을 제공하는 데 중요한 역할을 한다.

 

1. 지속적인 통합 (Continuous Integration, CI)

• 지속적인 통합은 개발자들이 작성한 코드를 자주(일반적으로 하루에 여러 번) 공유된 코드베이스에 통합하는 개발 방식이다.
• CI는 코드를 공유 레포지토리에 푸시할 때마다 자동으로 빌드하고, 자동화된 테스트를 실행하여 코드가 정상적으로 동작하는지 확인합니다. 이를 통해 개발자들이 각자의 작업을 자주 병합할 수 있도록 하고, 코드 충돌 및 버그를 조기에 발견할 수 있다.

CI 의 주요 목적

• 코드의 품질을 지속적으로 확인하고, 버그를 빠르게 발견하여 해결하는 것
• 여러 개발자가 동시에 작업할 때 발생할 수 있는 충돌을 최소화하고, 더 안정적인 코드베이스를 유지

 

2. 지속적인 통합 (Continuous Integration, CI)

• 지속적인 배포는 코드가 CI 프로세스를 통과하면 자동으로 프로덕션 환경에 배포되는 프로세스
• 이 과정은 완전 자동화되어 있어서, 개발자가 수동으로 배포하지 않고도 코드가 자동으로 배포
• 지속적인 배포는 매번 코드를 푸시하면 실시간으로 서비스에 반영되므로 빠르고 안정적인 배포가 가능

CD의 주요 목적

• 코드 변경을 빠르게 실시간 서비스에 반영할 수 있어 사용자에게 신속하게 새로운 기능이나 버그 수정을 제공
• 배포 과정의 오류를 줄이고, 배포 주기를 단축하여 더 자주 배포할 수 있도록 한다.

 

3. 지속적인 전달 (Continuous Delivery, CD)

• 지속적인 전달은 지속적인 배포와 비슷하지만, 프로덕션 환경에 배포되기 전에 승인 단계가 포함된다.
• 코드가 자동으로 빌드되고, 테스트되고, 스테이징 환경에 배포되며, 마지막 배포 단계에서 사람의 승인이 필요
• 지속적인 전달은 배포가 자동으로 준비되지만, 수동 승인이 필요한 점에서 지속적인 배포와 다르다

CD의 주요 목적

• 프로덕션에 배포할 준비가 된 코드를 항상 스테이징 환경에 배포하여, 수동 승인만 받으면 언제든지 배포할 수 있도록 한다.

 

---

 

GitHub Actions 

Github에서 제공하는 CI/CD 서비스로 GithHub 리포지토리와 연동하여 다양한 자동화 작업을 처리할 수 있다.

워크플로 (workflow)를 사용하여 CI/CD 프로세스를 정의하고 , 트리거 이벤트( 예: 코드 푸시, PR 생성 등)에 따라 자동으로실행된다.

 

주요 개념

• 워크플로 ( workflow )
  
  • 워크플로는 자동화된 빌드, 테스트, 배포 등의 프로세스를 정의한 것 
  • .github/workflows/ 디렉터리에 YAML 파일로 정의
  • 워크플로는 하나 이상의 작업(job) 을 포함하며, 특정 이벤트나 조건에 의해 실행
• 이벤트 ( Event )
  • 이벤트는 워크플로를 트리거하는 동작입니다.
  • 예시
    • push
    • pull_request
    • schedule
• 작업 ( Job )
  • 작업은 워크플로 내에서 실행되는 독립적인 단위
  • 여러 작업을 정의할 수 있으며, 각 작업은 다른 환경에서 독립적으로 실행
  • 작업은 runs-on 속성으로 실행 환경(예: Ubuntu, Windows 등)을 정의
• 단계( Step )
  • 단계는 각 작업 내에서 실행되는 개별적인 명령어입니다. 각 단계는 run 명령어 또는 uses 명령어로 실행
  • 소스 코드를 체크아웃하거나, 테스트를 실행하거나, Docker 이미지를 빌드하는 등의 작업이 단계에 해당
• 액션( Action )
  • 액션은 GitHub Actions에서 실행되는 코드로, 다양한 자동화 작업을 수행
• 러너( Runner )
• 러너는 작업을 실제로 실행하는 서버입니다. GitHub에서 제공하는 호스팅 러너(예: ubuntu-latest, windows-latest, macos-latest)를 사용할 수 있으며, 자체 호스팅 러너를 설정하여 개인 서버에서 실행할 수도 있다

 

워크플로 예시

name: CI/CD Pipeline  # 워크플로 이름

on:
  push:
    branches:
      - master  # master 브랜치에 푸시될 때 실행
  pull_request:
    branches:
      - develop  # develop 브랜치로의 PR 생성 시 실행

jobs:
  build:
    runs-on: ubuntu-latest  # 우분투 최신 버전 환경에서 실행
    steps:
      - name: Checkout Code
        uses: actions/checkout@v2  # 코드를 체크아웃하는 액션 사용
      - name: Set up JDK 17
        uses: actions/setup-java@v2  # JDK 17 설정
        with:
          java-version: '17'
      - name: Build with Gradle
        run: ./gradlew build  # Gradle 빌드 명령어 실행

 

주요 문법

• name: 워크플로의 이름을 지정
• on: 워크플로를 트리거하는 이벤트를 정의합니다. 여러 이벤트를 정의할.
  • push: 특정 브랜치로 코드가 푸시될 때
  • pull_request: PR이 열릴 때
  • schedule: 주기적인 실행 (Cron 형식 사용)
  • workflow_dispatch: 수동 실행
• jobs: 워크플로 내에서 실행될 작업을 정의
  • 각 작업은 runs-on을 사용해 실행 환경을 지정 (예: ubuntu-latest, windows-latest, macos-latest).
• steps: 작업 내에서 실행될 명령어 단계입니다. 각 단계는 name, uses, run 등을 통해 정의
  • uses: 외부 액션을 사용할 때 사용
  • run: 쉘 명령어를 실행할 때 사용
  • with: 액션에 인자를 전달할 때 사용