Enterprise Server 3.15 은(는) 현재 릴리스 후보로 제공됩니다.

GitLab CI/CD에서 GitHub Actions로 마이그레이션

GitHub Actions 및 GitLab CI/CD는 여러 구성 유사성을 공유하므로 GitHub Actions로 마이그레이션하는 것이 비교적 간단합니다.

이 문서의 내용

참고: GitHub 호스트 실행기는 현재 GitHub Enterprise Server에서 지원되지 않습니다. GitHub public roadmap에 예정된 향후 지원에 대해 자세히 알아볼 수 있습니다.

소개

GitLab CI/CD 및 GitHub Actions를 사용하면 코드를 자동으로 빌드, 테스트, 게시, 릴리스 및 배포하는 워크플로를 만들 수 있습니다. GitLab CI/CD 및 GitHub Actions는 워크플로 구성에서 몇 가지 유사점을 공유합니다.

  • 워크플로 구성 파일은 YAML로 작성되며 코드의 리포지토리에 저장됩니다.
  • 워크플로에는 하나 이상의 작업이 포함됩니다.
  • 작업에는 하나 이상의 단계 또는 개별 명령이 포함됩니다.
  • 작업은 관리형 컴퓨터 또는 자체 호스팅 컴퓨터에서 실행할 수 있습니다.

몇 가지 차이점이 있으며 이 가이드에서는 워크플로를 GitHub Actions로 마이그레이션할 수 있도록 중요한 차이점을 보여 줍니다.

작업

GitLab CI/CD의 작업은 GitHub Actions의 작업과 매우 유사합니다. 두 시스템 모두에서 작업은 다음과 같은 특징을 갖습니다.

  • 순차적으로 실행되는 일련의 단계 또는 스크립트를 포함합니다.
  • 별도의 컴퓨터 또는 별도의 컨테이너에서 실행할 수 있습니다.
  • 기본적으로 동시에 실행되지만 순차적으로 실행되도록 구성할 수 있습니다.

작업에서 스크립트 또는 셸 명령을 실행할 수 있습니다. GitLab CI/CD에서 스크립트 단계는 script 키를 사용하여 지정됩니다. GitHub Actions에서 모든 스크립트는 run 키를 사용하여 지정됩니다.

다음은 각 시스템에 대한 구문의 예입니다.

작업에 대한 GitLab CI/CD 구문

job1:
  variables:
    GIT_CHECKOUT: "true"
  script:
    - echo "Run your script here"

작업에 대한 GitHub Actions 구문

jobs:
  job1:
    steps:
      - uses: actions/checkout@v4
      - run: echo "Run your script here"

실행기

실행기는 작업이 실행되는 컴퓨터입니다. GitLab CI/CD 및 GitHub Actions는 실행기의 관리형 및 자체 호스팅 변형을 제공합니다. GitLab CI/CD에서 tags는 다른 플랫폼에서 작업을 실행하는 데 사용되지만 GitHub Actions에서는 runs-on을 통해 작업을 수행합니다.

다음은 각 시스템에 대한 구문의 예입니다.

실행기에 대한 GitLab CI/CD 구문

windows_job:
  tags:
    - windows
  script:
    - echo Hello, %USERNAME%!

linux_job:
  tags:
    - linux
  script:
    - echo "Hello, $USER!"

실행기에 대한 GitHub Actions 구문

windows_job:
  runs-on: windows-latest
  steps:
    - run: echo Hello, %USERNAME%!

linux_job:
  runs-on: ubuntu-latest
  steps:
    - run: echo "Hello, $USER!"

자세한 내용은 "GitHub Actions에 대한 워크플로 구문"을 참조하세요.

Docker 이미지

GitLab CI/CD 및 GitHub Actions는 모두 Docker 이미지에서 실행 작업을 지원합니다. GitLab CI/CD에서 Docker 이미지는 image 키를 통해 정의되지만 GitHub Actions에서는 container 키를 통해 수행됩니다.

다음은 각 시스템에 대한 구문의 예입니다.

Docker 이미지에 대한 GitLab CI/CD 구문

my_job:
  image: node:20-bookworm-slim

Docker 이미지에 대한 GitHub Actions 구문

jobs:
  my_job:
    container: node:20-bookworm-slim

자세한 내용은 "GitHub Actions에 대한 워크플로 구문"을 참조하세요.

조건 및 식 구문

GitLab CI/CD는 rules를 사용하여 특정 조건에 대한 작업을 실행할지 여부를 결정합니다. GitHub Actions는 조건이 충족되지 않는 한 작업이 실행되지 않도록 if 키워드를 사용합니다.

다음은 각 시스템에 대한 구문의 예입니다.

조건 및 식에 대한 GitLab CI/CD 구문

deploy_prod:
  stage: deploy
  script:
    - echo "Deploy to production server"
  rules:
    - if: '$CI_COMMIT_BRANCH == "master"'

조건 및 식에 대한 GitHub Actions 구문

jobs:
  deploy_prod:
    if: contains( github.ref, 'master')
    runs-on: ubuntu-latest
    steps:
      - run: echo "Deploy to production server"

자세한 내용은 "워크플로 및 작업에서 식 평가"을 참조하세요.

작업 간의 종속성

GitLab CI/CD와 GitHub Actions를 사용하면 작업에 대한 종속성을 설정할 수 있습니다. 두 시스템 모두 작업은 기본적으로 동시에 실행되지만 GitHub Actions의 작업 종속성은 needs 키를 통해 명시적으로 지정할 수 있습니다. 또한 GitLab CI/CD에는 한 스테이지의 작업이 동시에 실행되는 stages 개념도 있지만, 이전 스테이지의 모든 작업이 완료되면 다음 스테이지가 시작됩니다. GitHub Actions에서 needs 키를 사용하여 이 시나리오를 다시 만들 수 있습니다.

다음은 각 시스템에 대한 구문의 예입니다. 워크플로는 build_a 및 build_b라고 명명된 병렬로 실행되는 두 개의 작업으로 시작하며, 이 작업이 완료되면 test_ab라는 다른 작업이 실행됩니다. 마지막으로 test_ab가 완료되면 deploy_ab 작업이 실행됩니다.

작업 간 종속성에 대한 GitLab CI/CD 구문

stages:
  - build
  - test
  - deploy

build_a:
  stage: build
  script:
    - echo "This job will run first."

build_b:
  stage: build
  script:
    - echo "This job will run first, in parallel with build_a."

test_ab:
  stage: test
  script:
    - echo "This job will run after build_a and build_b have finished."

deploy_ab:
  stage: deploy
  script:
    - echo "This job will run after test_ab is complete"

작업 간 종속성에 대한 GitHub Actions 구문

jobs:
  build_a:
    runs-on: ubuntu-latest
    steps:
      - run: echo "This job will be run first."

  build_b:
    runs-on: ubuntu-latest
    steps:
      - run: echo "This job will be run first, in parallel with build_a"

  test_ab:
    runs-on: ubuntu-latest
    needs: [build_a,build_b]
    steps:
      - run: echo "This job will run after build_a and build_b have finished"

  deploy_ab:
    runs-on: ubuntu-latest
    needs: [test_ab]
    steps:
      - run: echo "This job will run after test_ab is complete"

자세한 내용은 "GitHub Actions에 대한 워크플로 구문"을 참조하세요.

워크플로 예약

GitLab CI/CD 및 GitHub Actions를 사용하면 특정 간격으로 워크플로를 실행할 수 있습니다. GitLab CI/CD에서 파이프라인 일정은 UI를 사용하여 구성되지만 GitHub Actions에서는 “켜기” 키를 사용하여 예약된 간격으로 워크플로를 트리거할 수 있습니다.

자세한 내용은 "워크플로를 트리거하는 이벤트"을 참조하세요.

변수 및 비밀

GitLab CI/CD 및 GitHub Actions는 파이프라인 또는 워크플로 구성 파일에서 변수를 설정하고 GitLab 또는 GitHub Enterprise Server UI를 사용하여 비밀을 만드는 작업을 지원합니다.

자세한 내용은 "변수에 정보 저장" 및 "GitHub Actions에서 비밀 사용"을(를) 참조하세요.

캐싱

GitLab CI/CD 및 GitHub Actions는 구성 파일에서 워크플로 파일을 수동으로 캐시하는 메서드를 제공합니다.

다음은 각 시스템에 대한 구문의 예입니다.

캐싱에 대한 GitLab CI/CD 구문

image: node:latest

cache:
  key: $CI_COMMIT_REF_SLUG
  paths:
    - .npm/

before_script:
  - npm ci --cache .npm --prefer-offline

test_async:
  script:
    - node ./specs/start.js ./specs/async.spec.js

캐싱에 대한 GitHub Actions 구문

jobs:
  test_async:
    runs-on: ubuntu-latest
    steps:
    - name: Cache node modules
      uses: actions/cache@v3
      with:
        path: ~/.npm
        key: v1-npm-deps-${{ hashFiles('**/package-lock.json') }}
        restore-keys: v1-npm-deps-

Artifacts

GitLab CI/CD 및 GitHub Actions는 작업에서 만든 파일 및 디렉터리를 아티팩트로 업로드할 수 있습니다. GitHub Actions에서 아티팩트가 여러 작업에 걸쳐 데이터를 유지하는 데 사용할 수 있습니다.

다음은 각 시스템에 대한 구문의 예입니다.

아티팩트에 대한 GitLab CI/CD 구문

script:
artifacts:
  paths:
    - math-homework.txt

아티팩트에 대한 GitHub Actions 구문

- name: Upload math result for job 1
  uses: actions/upload-artifact@v3
  with:
    name: homework
    path: math-homework.txt

자세한 내용은 "워크플로에서 데이터 저장 및 공유"을(를) 참조하세요.

데이터베이스 및 서비스 컨테이너

두 시스템 모두 데이터베이스, 캐싱 또는 기타 종속성에 대한 추가 컨테이너를 포함할 수 있습니다.

GitLab CI/CD에서 작업에 대한 컨테이너는 image 키로 지정되고 GitHub Actions는 container 키를 사용합니다. 두 시스템 모두에서 추가 서비스 컨테이너가 services 키로 지정됩니다.

다음은 각 시스템에 대한 구문의 예입니다.

데이터베이스 및 서비스 컨테이너에 대한 GitLab CI/CD 구문

container-job:
  variables:
    POSTGRES_PASSWORD: postgres
    # The hostname used to communicate with the
    # PostgreSQL service container
    POSTGRES_HOST: postgres
    # The default PostgreSQL port
    POSTGRES_PORT: 5432
  image: node:20-bookworm-slim
  services:
    - postgres
  script:
    # Performs a clean installation of all dependencies
    # in the `package.json` file
    - npm ci
    # Runs a script that creates a PostgreSQL client,
    # populates the client with data, and retrieves data
    - node client.js
  tags:
    - docker

데이터베이스 및 서비스 컨테이너에 대한 GitHub Actions 구문

jobs:
  container-job:
    runs-on: ubuntu-latest
    container: node:20-bookworm-slim

    services:
      postgres:
        image: postgres
        env:
          POSTGRES_PASSWORD: postgres

    steps:
      - name: Check out repository code
        uses: actions/checkout@v4

      # Performs a clean installation of all dependencies
      # in the `package.json` file
      - name: Install dependencies
        run: npm ci

      - name: Connect to PostgreSQL
        # Runs a script that creates a PostgreSQL client,
        # populates the client with data, and retrieves data
        run: node client.js
        env:
          # The hostname used to communicate with the
          # PostgreSQL service container
          POSTGRES_HOST: postgres
          # The default PostgreSQL port
          POSTGRES_PORT: 5432

자세한 내용은 "서비스 컨테이너 정보" 항목을 참조하세요.