Skip to main content

이 버전의 GitHub Enterprise는 다음 날짜에 중단되었습니다. 2024-09-25. 중요한 보안 문제에 대해서도 패치 릴리스가 이루어지지 않습니다. 더 뛰어난 성능, 향상된 보안, 새로운 기능을 위해 최신 버전의 GitHub Enterprise Server로 업그레이드합니다. 업그레이드에 대한 도움말은 GitHub Enterprise 지원에 문의하세요.

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

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

Note

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_abuild_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

자세한 내용은 서비스 컨테이너 정보을(를) 참조하세요.