소개
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 Cloud 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@v4
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
자세한 내용은 서비스 컨테이너 정보을(를) 참조하세요.