CI/CD 구성 요소 예시

Tier: Free, Premium, Ultimate

Offering: GitLab.com, Self-managed, GitLab Dedicated

구성 요소 테스트

구성 요소의 기능에 따라, 구성 요소 테스트는 리포지토리에 추가 파일이 필요할 수 있습니다.

예를 들어, 특정 프로그래밍 언어로 소프트웨어를 린트하고, 빌드하고, 테스트하는 구성 요소는 실제 소스 코드 샘플이 필요합니다.

소스 코드 예제, 구성 파일 및 유사한 파일을 동일한 리포지토리에서 가질 수 있습니다.

예를 들어, 코드 품질 CI/CD 구성 요소에는 여러 테스트용 코드 샘플이 포함되어 있습니다.

예시: Rust 언어 CI/CD 구성 요소 테스트

구성 요소의 기능에 따라, 구성 요소 테스트는 리포지토리에 추가 파일이 필요할 수 있습니다.

Rust 프로그래밍 언어의 다음 “hello world” 예시는 단순함을 위해 cargo 툴 체인을 사용합니다:

  1. CI/CD 구성 요소의 루트 디렉토리로 이동합니다.

  2. cargo init 명령어를 사용하여 새로운 Rust 프로젝트를 초기화합니다.

    cargo init

    해당 명령은 src/main.rs “hello world” 예제를 포함하여 모든 필수 프로젝트 파일을 생성합니다.

    이 단계는 cargo build를 사용하여 구성 요소 작업에서 Rust 소스 코드를 빌드하는 데 충분합니다.

    tree
.
├── Cargo.toml
├── LICENSE.md
├── README.md
├── src
│   └── main.rs
└── templates
    └── build.yml

  3. 구성 요소에 Rust 소스 코드를 빌드하는 작업이 있는지 확인합니다. 예를 들어,

    templates/build.yml에 다음과 같이 작성합니다:

    spec:
  inputs:
    stage:
      default: build
      description: 'Defines the build stage'
    rust_version:
      default: latest
      description: 'Specify the Rust version, use values from https://hub.docker.com/_/rust/tags Defaults to latest'
---

"build-$[[ inputs.rust_version ]]":
  stage: $[[ inputs.stage ]]
  image: rust:$[[ inputs.rust_version ]]
  script:
    - cargo build --verbose

    이 예제에서:

    • stage 및 rust_version 입력은 기본값에서 수정이 가능합니다.

      CI/CD 작업은 build- 접두사로 시작하며 rust_version 입력에 따라 동적으로 이름을 생성합니다.

      cargo build --verbose 명령은 Rust 소스 코드를 컴파일합니다.

  4. 프로젝트의 .gitlab-ci.yml 구성 파일에서 구성 요소의 build 템플릿을 테스트합니다:

    include:
  # 현재 SHA에서 현재 프로젝트에 위치한 구성 요소 포함
  - component: $CI_SERVER_FQDN/$CI_PROJECT_PATH/build@$CI_COMMIT_SHA
    inputs:
      stage: build

stages: [build, test, release]

  5. 테스트 및 기타를 실행하기 위해, Rust 코드에 추가 기능과 테스트를 추가하고 templates/test.yml에 cargo test를 실행하는 구성 요소 템플릿과 작업을 추가합니다.

    spec:
  inputs:
    stage:
      default: test
      description: 'Defines the test stage'
    rust_version:
      default: latest
      description: 'Specify the Rust version, use values from https://hub.docker.com/_/rust/tags Defaults to latest'
---

"test-$[[ inputs.rust_version ]]":
  stage: $[[ inputs.stage ]]
  image: rust:$[[ inputs.rust_version ]]
  script:
    - cargo test --verbose

  6. test 구성 요소 템플릿을 포함하여 파이프라인에서 추가 작업을 테스트합니다:

    include:
  # 현재 SHA에서 현재 프로젝트에 위치한 구성 요소 포함
  - component: $CI_SERVER_FQDN/$CI_PROJECT_PATH/build@$CI_COMMIT_SHA
    inputs:
      stage: build
  - component: $CI_SERVER_FQDN/$CI_PROJECT_PATH/test@$CI_COMMIT_SHA
    inputs:
      stage: test

stages: [build, test, release]

CI/CD 구성 요소 마이그레이션 예제

이 섹션은 재사용 가능한 CI/CD 구성 요소로 CI/CD 템플릿 및 파이프라인 구성을 마이그레이션하는 실제 예제를 보여줍니다.

CI/CD 구성 요소 마이그레이션 예제: Go

소프트웨어 개발 라이프사이클을 위한 전체 파이프라인은 여러 작업 및 단계로 구성될 수 있습니다.

프로그래밍 언어를 위한 CI/CD 템플릿은 단일 템플릿 파일에 여러 작업을 제공할 수 있습니다.

관행으로, 다음 Go CI/CD 템플릿이 마이그레이션 되어야 합니다.

image: golang:latest

stages:
  - test
  - build
  - deploy

format:
  stage: test
  script:
    - go fmt $(go list ./... | grep -v /vendor/)
    - go vet $(go list ./... | grep -v /vendor/)
    - go test -race $(go list ./... | grep -v /vendor/)

compile:
  stage: build
  script:
    - mkdir -p mybinaries
    - go build -o mybinaries ./...
  artifacts:
    paths:
      - mybinaries
note
모든 작업 대신 하나의 작업만 마이그레이션하는 것으로 시작할 수도 있습니다. 아래 지침을 따르고, 첫 번째 반복에서 build CI/CD 작업만 마이그레이션합니다.

CI/CD 템플릿 마이그레이션에는 다음 단계가 포함됩니다:

  1. CI/CD 작업 및 종속성을 분석하고 마이그레이션 작업 정의하기:
    • image 구성은 전역이며, 작업 정의로 이동해야 합니다.
    • format 작업은 하나의 작업에서 여러 go 명령을 실행합니다. go test 명령은 파이프라인 효율성을 높이기 위해 별도의 작업으로 이동해야 합니다.
    • compile 작업은 go build를 실행하며 build로 이름을 변경해야 합니다.
  2. 더 나은 파이프라인 효율성을 위한 최적화 전략 정의하기.
    • stage 작업 속성은 서로 다른 CI/CD 파이프라인 소비자가 가능하도록 구성 가능해야 합니다.
    • image 키는 하드코딩된 이미지 태그 latest를 사용합니다. 더 유연하고 재사용 가능한 파이프라인을 위해 기본값 latest로 golang_version을 입력으로 추가합니다. 입력은 Docker Hub 이미지 태그 값과 일치해야 합니다.
    • compile 작업은 하드코딩된 대상 디렉터리 mybinaries에 바이너리를 빌드하며, 이는 동적 입력 및 기본값 mybinaries로 향상될 수 있습니다.

  3. 새 구성 요소를 위한 디렉토리 구조 템플릿을 생성합니다, 각 작업에 대해 하나의 템플릿을 기반으로 합니다.

    • 템플릿의 이름은 go 명령을 따르며, 예를 들어 format.yml, build.yml, 및 test.yml입니다.
    • 새 프로젝트를 생성하고, Git 저장소를 초기화하고, 모든 변경 사항을 추가/커밋하고 원격 원점을 설정한 후 푸시합니다. CI/CD 구성 요소 프로젝트 경로에 대한 URL을 수정합니다.
    • 구성 요소 작성 지침에 따라 추가 파일을 생성합니다: README.md, LICENSE.md, .gitlab-ci.yml, .gitignore. 다음 셸 명령은 Go 구성 요소 구조를 초기화합니다:
    git init

mkdir templates
touch templates/{format,build,test}.yml

touch README.md LICENSE.md .gitlab-ci.yml .gitignore

git add -A
git commit -avm "Initial component structure"

git remote add origin https://gitlab.example.com/components/golang.git

git push
  4. 템플릿으로 CI/CD 작업을 생성합니다. build 작업부터 시작합니다.
    • spec 섹션에 다음 입력을 정의합니다: stage, golang_version 및 binary_directory.
    • 동적 작업 이름 정의를 추가하여 inputs.golang_version에 접근합니다.
    • 동적 Go 이미지 버전에 대해서도 유사한 패턴을 사용하여 inputs.golang_version에 접근합니다.
    • 단계를 inputs.stage 값에 할당합니다.
    • inputs.binary_directory로 바이너리 디렉터리를 생성하여 go build에 매개변수로 추가합니다.

    • 아티팩트 경로를 inputs.binary_directory로 정의합니다.

      spec:
  inputs:
    stage:
      default: 'build'
      description: 'Defines the build stage'
    golang_version:
      default: 'latest'
      description: 'Go image version tag'
    binary_directory:
      default: 'mybinaries'
      description: 'Output directory for created binary artifacts'
---

"build-$[[ inputs.golang_version ]]":
  image: golang:$[[ inputs.golang_version ]]
  stage: $[[ inputs.stage ]]
  script:
    - mkdir -p $[[ inputs.binary_directory ]]
    - go build -o $[[ inputs.binary_directory ]] ./...
  artifacts:
    paths:
      - $[[ inputs.binary_directory ]]

    • format 작업 템플릿은 동일한 패턴을 따르지만 stage 및 golang_version 입력만 필요합니다.

      spec:
  inputs:
    stage:
      default: 'format'
      description: 'Defines the format stage'
    golang_version:
      default: 'latest'
      description: 'Golang image version tag'
---

"format-$[[ inputs.golang_version ]]":
  image: golang:$[[ inputs.golang_version ]]
  stage: $[[ inputs.stage ]]
  script:
    - go fmt $(go list ./... | grep -v /vendor/)
    - go vet $(go list ./... | grep -v /vendor/)

    • test 작업 템플릿은 동일한 패턴을 따르지만 stage 및 golang_version 입력만 필요합니다.

      spec:
  inputs:
    stage:
      default: 'test'
      description: 'Defines the format stage'
    golang_version:
      default: 'latest'
      description: 'Golang image version tag'
---

"test-$[[ inputs.golang_version ]]":
  image: golang:$[[ inputs.golang_version ]]
  stage: $[[ inputs.stage ]]
  script:
    - go test -race $(go list ./... | grep -v /vendor/)

  5. 구성 요소를 테스트하기 위해 .gitlab-ci.yml 구성 파일을 수정하고 테스트를 추가합니다.

    • build 작업에 대한 golang_version의 다른 값을 입력으로 지정합니다.

    • CI/CD 구성 요소 경로에 대한 URL을 수정합니다.

      stages: [format, build, test]

include:
  - component: $CI_SERVER_FQDN/$CI_PROJECT_PATH/format@$CI_COMMIT_SHA
  - component: $CI_SERVER_FQDN/$CI_PROJECT_PATH/build@$CI_COMMIT_SHA
  - component: $CI_SERVER_FQDN/$CI_PROJECT_PATH/build@$CI_COMMIT_SHA
    inputs:
      golang_version: "1.21"
  - component: $CI_SERVER_FQDN/$CI_PROJECT_PATH/test@$CI_COMMIT_SHA
    inputs:
      golang_version: latest

  6. CI/CD 구성 요소를 테스트하기 위해 Go 소스 코드를 추가합니다. go 명령은 루트 디렉터리에 go.mod 및 main.go가 있는 Go 프로젝트를 기대합니다.

    • Go 모듈을 초기화합니다. CI/CD 구성 요소 경로에 대한 URL을 수정합니다.

      go mod init example.gitlab.com/components/golang

    • 기본 함수가 Hello, CI/CD component를 출력하는 main.go 파일을 생성합니다. 팁: 코드 주석을 사용하여 GitLab Duo 코드 제안을 사용하여 Go 코드를 생성하세요.

      // 패키지를 지정하고 필요한 패키지를 가져옵니다
// 메인 함수를 생성합니다
// 메인 함수 내부에서 "Hello, CI/CD Component"를 출력합니다

package main

import "fmt"

func main() {
  fmt.Println("Hello, CI/CD Component")
}

    • 디렉토리 트리는 다음과 같아야 합니다:

      tree
.
├── LICENSE.md
├── README.md
├── go.mod
├── main.go
└── templates
    ├── build.yml
    ├── format.yml
    └── test.yml

남은 단계는 CI/CD 템플릿을 구성 요소로 변환하는 섹션을 따라 마이그레이션을 완료합니다:

  1. 변경 사항을 커밋하고 푸시한 후 CI/CD 파이프라인 결과를 확인합니다.
  2. 구성 요소 작성 지침에 따라 README.md 및 LICENSE.md 파일을 업데이트합니다.
  3. 구성 요소 배포하고 CI/CD 카탈로그에서 확인합니다.
  4. CI/CD 구성 요소를 스테이징/프로덕션 환경에 추가합니다.

GitLab에서 유지 관리하는 Go 구성 요소는 입력 및 구성 요소 모범 사례로 강화된 Go CI/CD 템플릿에서 성공적으로 마이그레이션한 예를 제공합니다. Git 기록을 조사하여 더 자세히 알아볼 수 있습니다.