Close

GitLab으로 ImageLabeller 배포

Warren Marusiak 얼굴 사진
Warren Marusiak

선임 기술 에반젤리스트

Jira Software 및 다양한 연결된 도구를 사용하여 애플리케이션을 개발, 배포 및 관리하는 방법을 보여주기 위해 저희 팀에서는 머신러닝을 사용하여 이미지에 레이블을 적용하는 간단한 AWS 기반 데모 애플리케이션인 ImageLabeller를 만들었습니다.

이 페이지에서는 GitLab으로 ImageLabeller를 배포하는 방법을 다룹니다. 시작하기 전에 컨텍스트를 알아보도록 ImageLabeller 아키텍처AWS SageMaker 설정 페이지를 읽어보는 것이 좋습니다.

필수 조건

아직 GitLab 그룹이 없다면 GitLab 가이드의 단계에 따라 처음부터 만들어 보세요.

ImageLabeller 코드가 있는 공개 GitHub 리포지토리

https://github.com/AtlassianOpenDevOpsGuides

Jira GitLab 통합 데모 비디오

Jira 및 GitLab 통합

Jira에서 보드, , GitLab을 차례로 클릭합니다.

GitLab으로 이동하는 Jira Software 드롭다운 메뉴 스크린샷

지금 받기를 클릭합니다.

Jira Software의 GitLab 앱 모달

을 클릭한 다음 앱 관리를 클릭합니다.

드롭다운 메뉴가 있는 Jira Software의 GitLab 앱 모달

Jira용 GitLab을 펼칩니다.

Jira Software의 앱 관리 화면에서 GitLab 펼치기

네임스페이스 추가를 클릭합니다.

GitLab Jira Software 구성에 네임스페이스를 추가하는 화면

기존 네임스페이스를 선택하고 링크를 클릭합니다. 이 가이드에서는 이미 기존 GitLab 계정과 GitLab 그룹이 있다고 가정합니다.

Jira Software에서 GitLab 네임스페이스 연결

GitLab에 SSH 키 추가

오른쪽 상단에 있는 프로필 아이콘을 클릭하고 기본 설정을 클릭합니다.

GitLab의 드롭다운 메뉴를 사용하여 기본 설정으로 이동

SSH 키를 클릭하고 안내에 따라 새 SSH 키를 생성하거나 기존 SSH 키를 사용하세요.

AWS S3 인프라용 리포지토리 만들기

표준 개발자 루프에는 보통 개발자가 Jira에서 작업을 가져와서 진행 중인 작업으로 이동하고 개발 작업을 하는 것이 포함됩니다. Jira 이슈 ID는 개발 작업을 Jira 이슈와 연결해주는 열쇠입니다. 두 시스템 간의 핵심적인 통합 컴포넌트입니다.

Jira로 이동하여 GitLab에 AWS S3 인프라 리포지토리를 추가하기 위한 새 이슈를 만듭니다. 이슈 ID를 기록해 두세요. 이 예에서는 IM-5입니다.

Jira Software에서 보드에 대한 새 이슈 만들기

GitLab으로 이동하여 새 프로젝트를 클릭합니다.

GitLab에서 "새 프로젝트"를 만들기 위해 탐색

빈 프로젝트 만들기를 클릭합니다.

GitLab에서 새 프로젝트 만들기

프로젝트 이름을 추가하고 프로젝트 URL에서 적절한 그룹을 선택합니다. 프로젝트 만들기를 클릭하여 진행합니다.

새 프로젝트 만들기- GitLab의 자세한 화면

터미널에서 s3_infra 리포지토리로 이동하고 다음을 실행하여 AWS CloudFormation template.yml 파일을 GitLab으로 푸시합니다.

git add --all
git commit -m "IM-5 add s3_infra repository to gitlab"
git remote add origin git@gitlab.com:pmmquickstartguides/s3_infra.git
git branch -m mainline
git push -u origin mainline

AWS 액세스 키 추가

설정을 클릭한 다음 CI/CD를 클릭합니다. 아래로 스크롤하여 변수를 펼칩니다. 변수 추가를 클릭합니다.

GitLab의 CI/CD 설정 페이지

변수를 두 개 만듭니다. 하나는 AWS 액세스 키 ID, 다른 하나는 AWS 암호 액세스 키를 위한 변수입니다.

GitLab에서 AWS 키를 추가하기 위한 "변수 추가" 모달

변수를 보호된 브랜치에서 실행되는 파이프라인과 태그에서만 사용하도록 보호합니다. AWS 액세스 키와 연결된 IAM 사용자에게 AdministratorAccess를 제공합니다. 개별 AWS 액세스 정책을 선택해서 더 세밀한 액세스 제어를 사용할 수도 있습니다.

GitLab의 CI/CD 설정 페이지의 "변수" 섹션에 나열된 AWS 키

보호되는 변수에 접근할 수 있도록 보호되는 브랜치 구성

설정을 클릭한 다음 리포지토리를 클릭합니다. 아래로 스크롤하여 보호되는 브랜치를 펼칩니다.

Jira 이슈 ID 접두사와 *를 입력합니다.

이 예에서 Jira 이슈 ID는 IM-5, IM-6과 같습니다. 접두사는 IM-입니다.

IM-*를 입력하고 보호를 클릭합니다.

GitLab에서 보호되는 브랜치 구성

메인 라인과 IM-*가 보호 브랜치로 표시됩니다.

배포 환경 설정

배포를 클릭한 다음 환경을 클릭합니다. 새 환경을 추가하려면 새 환경을 클릭합니다. 이 예에는 US-WEST-1 및 US-EAST-2에 테스트 환경, US-WEST-2, US-EAST-1, CA-CENTRAL-1에 프로덕션 환경이 있습니다.

GitLab에서 배포 환경 설정

AWS에 배포하기 위한 .gitlab-ci.yml

터미널에 있는 s3_infra 리포지토리로 이동하여 Jira 이슈 ID의 이름을 딴 브랜치를 만듭니다.

git checkout -b IM-5

다음 yaml로 .gitlab-ci.yml 파일을 만듭니다. 이것은 테스트, 스테이징, 프로덕션 환경을 위한 배포 워크플로를 정의합니다.

stages:
  - merge-request
  - test-us-west-1
  - test-us-east-2
  - production-us-west-2
  - production-us-east-1
  - production-ca-central-1

merge-request-pipeline-job:
  stage: merge-request
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
  script:
    - echo "This pipeline always succeeds and enables merges during merge requests"
    - echo true

deploy-test-us-west-1:
  stage: test-us-west-1
  environment: test-us-west-1
  rules:
    - if: $CI_COMMIT_BRANCH != $CI_DEFAULT_BRANCH && $CI_PIPELINE_SOURCE != "merge_request_event"
  image: registry.gitlab.com/gitlab-org/cloud-deploy/aws-base:latest
  script:
    - export AWS_ACCESS_KEY_ID=$AWS_ACCESS_KEY_ID
    - export AWS_SECRET_ACCESS_KEY=$AWS_SECRET_ACCESS_KEY
    - aws cloudformation deploy --region us-west-1 --template-file template.yml --stack-name OpenDevOpsS3Infra

deploy-test-us-east-2:
  stage: test-us-east-2
  environment: test-us-east-2
  rules:
    - if: $CI_COMMIT_BRANCH != $CI_DEFAULT_BRANCH && $CI_PIPELINE_SOURCE != "merge_request_event"
  image: registry.gitlab.com/gitlab-org/cloud-deploy/aws-base:latest
  script:
    - export AWS_ACCESS_KEY_ID=$AWS_ACCESS_KEY_ID
    - export AWS_SECRET_ACCESS_KEY=$AWS_SECRET_ACCESS_KEY
    - aws cloudformation deploy --region us-east-2 --template-file template.yml --stack-name OpenDevOpsS3Infra

deploy-production-us-west-2:
  stage: production-us-west-2
  environment: production-us-west-2
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH && $CI_PIPELINE_SOURCE != "merge_request_event"
  image: registry.gitlab.com/gitlab-org/cloud-deploy/aws-base:latest
  script:
    - export AWS_ACCESS_KEY_ID=$AWS_ACCESS_KEY_ID
    - export AWS_SECRET_ACCESS_KEY=$AWS_SECRET_ACCESS_KEY
    - aws cloudformation deploy --region us-west-2 --template-file template.yml --stack-name OpenDevOpsS3Infra

deploy-production-us-east-1:
  stage: production-us-east-1
  environment: production-us-east-1
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH && $CI_PIPELINE_SOURCE != "merge_request_event"
  image: registry.gitlab.com/gitlab-org/cloud-deploy/aws-base:latest
  script:
    - export AWS_ACCESS_KEY_ID=$AWS_ACCESS_KEY_ID
    - export AWS_SECRET_ACCESS_KEY=$AWS_SECRET_ACCESS_KEY
    - aws cloudformation deploy --region us-east-1 --template-file template.yml --stack-name OpenDevOpsS3Infra

deploy-production-ca-central-1:
  stage: production-ca-central-1
  environment: production-ca-central-1
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH && $CI_PIPELINE_SOURCE != "merge_request_event"
  image: registry.gitlab.com/gitlab-org/cloud-deploy/aws-base:latest
  script:
    - export AWS_ACCESS_KEY_ID=$AWS_ACCESS_KEY_ID
    - export AWS_SECRET_ACCESS_KEY=$AWS_SECRET_ACCESS_KEY
    - aws cloudformation deploy --region ca-central-1 --template-file template.yml --stack-name OpenDevOpsS3Infra

.gitlab-ci.yml 파일 이해하기

스테이지

GitLab 파이프라인의 실행 순서를 정의하려면 스테이지 블록을 추가합니다. 스테이지는 스테이지 블록에 정의된 순서대로 실행됩니다. 스테이지와 관련된 작업은 병렬로 실행됩니다.

stages:
  - merge-request
  - test-us-west-1
  - test-us-east-2
  - production-us-west-2
  - production-us-east-1
  - production-ca-central-1

작업

작업은 스테이지와 연결되고 환경과 연결될 수 있습니다. 규칙은 특정 작업이 실행될지 여부를 제어합니다. 이 예제의 규칙은 파이프라인 브랜치가 기본 브랜치가 아닌지, 파이프라인이 병합 요청의 일부로 자동으로 실행되지 않는지 확인합니다.

작업마다 다른 이미지를 지정할 수 있습니다. 작업 스크립트에 필요한 도구로 이미지를 설정할 수 있습니다. 스크립트 섹션은 작업이 실행될 때 이루어지는 일련의 단계를 정의합니다.

deploy-test-us-west-1:
  stage: test-us-west-1
  environment: test-us-west-1
  rules:
    - if: $CI_COMMIT_BRANCH != $CI_DEFAULT_BRANCH && $CI_PIPELINE_SOURCE != "merge_request_event"
  image: registry.gitlab.com/gitlab-org/cloud-deploy/aws-base:latest
  script:
    - export AWS_ACCESS_KEY_ID=$AWS_ACCESS_KEY_ID
    - export AWS_SECRET_ACCESS_KEY=$AWS_SECRET_ACCESS_KEY
    - aws cloudformation deploy --region us-west-1 --template-file template.yml --stack-name OpenDevOpsS3Infra

병합 요청 파이프라인

병합 요청이 승인되면 GitLab에서 파이프라인을 자동으로 실행합니다. 규칙을 추가하여 이 파이프라인에 대한 작업을 만들 수 있습니다. 이 예에서는 작업이 항상 성공합니다.

merge-request-pipeline-job:
  stage: merge-request
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
  script:
    - echo "This pipeline always succeeds and enables merges during merge requests"
    - echo true

기능 브랜치로 푸시

명령줄에서 다음을 실행하여 s3_infra 리포지토리의 IM-5 브랜치로 변경 사항을 푸시합니다. 커밋 메시지에 Jira 이슈 ID 및 브랜치 이름을 포함하면 Jira GitLab 통합이 프로젝트 진행 상황을 추적하도록 할 수 있습니다.

git add --all
git commit -m "IM-5 add .gitlab-ci.yml to s3_infra"
git push -u origin IM-5

CI/CD를 클릭한 다음 파이프라인을 클릭하여 파이프라인이 실행되는 것을 확인합니다.

GitLab의 CI/CD 파이프라인 화면

실행 중인 파이프라인의 파이프라인 ID를 클릭합니다.

GitLab에서 실행 중인 파이프라인의 파이프라인 ID

자세한 내용을 확인하려면 작업을 클릭하세요.

GitLab에서 실행 중인 파이프라인의 상세 작업 화면

병합 요청 만들기

병합 요청을 만들려면 병합 요청을 클릭한 다음 병합 요청 만들기를 클릭합니다.

GitLab의 병합 요청 화면

기능 브랜치를 소스 브랜치로 선택하고 브랜치 비교 및 계속을 클릭합니다.

GitLab에서 소스 브랜치와 타겟 브랜치 비교

담당자검토자를 선택합니다.

GitLab에서 병합 요청을 위한 검토자 선택

병합 요청 만들기를 클릭합니다.

GitLab에서 "병합 요청 만들기" 버튼 선택

코드 변경 사항을 검토한 다음 승인을 클릭합니다.

GitLab에서 변경 사항을 검토할 수 있는 병합 요청 자세한 화면

CI/CD를 클릭한 다음 파이프라인을 클릭하여 병합 요청 파이프라인이 실행되는 것을 확인합니다.

GitLab에서 "파이프라인" 화면으로 이동하여 병합 실행 요청 확인

파이프라인 ID를 클릭합니다. 실행된 유일한 작업은 merge-request-pipeline-job이라는 점에 주목하세요.

GitLab에서 merge-request-pipeline-job만 실행된 것을 보여주는 "파이프라인" 세부 정보 페이지

병합 요청을 클릭한 다음 활성 병합 요청을 클릭하고 병합을 클릭하여 병합 요청으로 돌아갑니다. 그러면 또다른 파이프라인이 시작됩니다.

GitLab에서 활성 병합 요청 병합

CI/CD를 클릭한 다음 파이프라인을 클릭합니다. 파이프라인 ID를 클릭합니다.

"브랜치 'IM-5'를 '메인 라인'으로 병합"하는 GitLab의 파이프라인 세부 정보 페이지

SystemTests용 리포지토리 만들기

Jira로 이동하여 GitLab에 SystemTests 리포지토리를 추가하기 위한 Jira 이슈를 만듭니다. Jira 이슈 ID를 기록해 두세요. 이 예에서는 IM-7입니다.

"SubmitImage AWS Lambda용 GitLab 리포지토리를 추가"하기 위해 Jira Software에 이슈 만들기

프로젝트 이름을 추가하고 프로젝트 URL에서 적절한 그룹을 선택합니다. 프로젝트 만들기를 클릭하여 진행합니다.

GitLab에서 새 프로젝트를 만들 때 프로젝트 세부 정보 입력

터미널에서 SystemTests 리포지토리로 이동하고 다음을 실행하여 코드를 GitLab으로 푸시합니다.

git add --all
git commit -m "IM-7 add SystemTests repository to gitlab"
git remote add origin git@gitlab.com:pmmquickstartguides/systemtests.git
git branch -m mainline
git push -u origin mainline

SystemTests 리포지토리에는 .gitlab-ci.yml 파일이 필요하지 않습니다. 기타 파이프라인의 실행을 위한 테스트를 제공하므로 자체 파이프라인이 없습니다. SystemTests의 원격 URL을 기록해 두세요. SubmitImage, GetImageLabel, InvokeLabeller CI/CD 파이프라인을 호출하면 테스트 단계에서 SystemTests 리포지토리가 복제됩니다. 이후 리포지토리의 gitlab-ci.yml을 올바른 URL로 업데이트해야 합니다.

배포 토큰 추가

다른 파이프라인 실행 중에 이 리포지토리를 복제하려면 배포 토큰을 추가해야 합니다. 설정을 클릭한 다음 리포지토리를 클릭합니다. 아래로 스크롤하여 배포 토큰을 펼치세요.

GitLab의 "토큰 배포"에 예제 이름 'cloneMe' 입력

이름을 입력하고 read_repository를 확인하고 배포 토큰 만들기를 클릭합니다.

GitLab의 "토큰 배포" 설정 페이지에서 "read_repository" 확인란 선택

배포 토큰 사용자 이름은 자동으로 생성됩니다. 배포 토큰 비밀번호는 만들 때 한 번 제공됩니다. 나중에 참조할 수 있도록 암호 관리 도구에 추가하세요. 가이드의 뒷부분에서 배포 토큰 사용자 이름은 gitlab_deploy_token으로 참조되며 배포 토큰 비밀번호는 gitlab_deploy_password로 참조됩니다.

토큰 배포 사용자 이름과 비밀번호가 표시된 GitLab의 토큰 배포 화면

SubmitImage AWS Lambda용 리포지토리 만들기

Jira로 이동하여 GitLab에 SubmitImage AWS Lambda 리포지토리를 추가하기 위한 새 이슈를 만듭니다. 이슈 ID를 기록해 두세요. 이 예에서는 IM-8입니다.

Jira Software의 Imagelabeller 보드 - 이슈 "IM-8 SubmitImage AWS Lambda를 위한 GitLab 리포지토리 추가" 강조 표시

GitLab으로 이동하여 새 프로젝트를 클릭한 다음 빈 프로젝트 만들기를 클릭합니다. 프로젝트 이름을 추가하고 프로젝트 URL에서 적절한 그룹을 선택합니다. 프로젝트 만들기를 클릭하여 진행합니다.

GitLab에서 새 프로젝트 "submitimage"를 만드는 스크린샷

터미널에서 SubmitImage 리포지토리로 이동하고 다음을 실행하여 코드를 GitLab으로 푸시합니다.

git add --all
git commit -m "IM-8 add SubmitImage to gitlab"
git remote add origin git@gitlab.com:pmmquickstartguides/submitimage.git
git branch -m mainline
git push -u origin mainline

AWS 액세스 키를 추가하고 보호되는 브랜치를 구성하고 배포 환경을 설정해야 합니다.

그런 다음 SystemTests 리포지토리에서 배포 키를 추가하여 SubmitImage GitLab 파이프라인이 SystemTests를 다운로드하고 실행할 수 있도록 합니다.

마지막으로 AWS 계정 ID를 CI/CD 변수로 추가합니다.

GitLab의 변수 화면 스크린샷

AWS에 배포하기 위한 .gitlab-ci.yml

터미널에 있는 SubmitImage 리포지토리로 이동하여 Jira 이슈 ID의 이름을 딴 브랜치를 만듭니다.

git checkout -b IM-8

다음 yaml로 .gitlab-ci.yml 파일을 만듭니다. 이것은 테스트, 스테이징, 프로덕션 환경을 위한 배포 워크플로를 정의합니다. SystemTests가 SystemTests 리포지토리가 되려면 git clone 라인을 업데이트해야 합니다.

stages:
  - merge-request
  - run-unit-tests
#US-WEST-1
  - deploy-us-west-1
  - test-us-west-1
#US-EAST-2
  - deploy-us-east-2
  - test-us-east-2
#US-WEST-2
  - deploy-us-west-2
  - test-us-west-2
#US-EAST-1
  - deploy-us-east-1
  - test-us-east-1
#CA-CENTRAL-1
  - deploy-ca-central-1
  - test-ca-central-1

merge-request-pipeline-job:
  stage: merge-request
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
  script:
    - echo "This pipeline always succeeds and enables merge"
    - echo true

run-unit-tests:
  stage: run-unit-tests
  image: golang:buster
  rules:
    - if: $CI_COMMIT_BRANCH != $CI_DEFAULT_BRANCH && $CI_PIPELINE_SOURCE != "merge_request_event"
  script:
    - cd submitImage
    - go test ./opendevopslambda/...

#US-WEST-1
deploy-us-west-1:
  stage: deploy-us-west-1
  environment: test-us-west-1
  image: python:latest
  rules:
    - if: $CI_COMMIT_BRANCH != $CI_DEFAULT_BRANCH && $CI_PIPELINE_SOURCE != "merge_request_event"
  before_script:
    - pip3 install awscli --upgrade
    - pip3 install aws-sam-cli --upgrade
    - wget https://golang.org/dl/go1.16.6.linux-amd64.tar.gz
    - rm -rf /usr/local/go && tar -C /usr/local -xzf go1.16.6.linux-amd64.tar.gz
    - export PATH=$PATH:/usr/local/go/bin
    - go version
  script:
    - export AWS_ACCESS_KEY_ID=$AWS_ACCESS_KEY_ID
    - export AWS_SECRET_ACCESS_KEY=$AWS_SECRET_ACCESS_KEY
    - sam build
    - sam package --output-template-file submit-image-packaged.yaml --s3-bucket open-devops-code-us-west-1-$AWS_ACCOUNT_ID --region us-west-1
    - sam deploy --template-file submit-image-packaged.yaml --stack-name OpenDevOpsSubmitImage  --s3-bucket open-devops-code-us-west-1-$AWS_ACCOUNT_ID --capabilities CAPABILITY_IAM --region us-west-1 --no-fail-on-empty-changeset

      #test-us-west-1:
      #  stage: test-us-west-1
      #  environment: test-us-west-1
      #  image: golang:buster
      #  rules:
      #    - if: $CI_COMMIT_BRANCH != $CI_DEFAULT_BRANCH && $CI_PIPELINE_SOURCE != "merge_request_event"
      #  script:
      #    - export AWS_ACCESS_KEY_ID=$AWS_ACCESS_KEY_ID
      #    - export AWS_SECRET_ACCESS_KEY=$AWS_SECRET_ACCESS_KEY
      #    - git clone https://${gitlab_deploy_token}:${gitlab_deploy_password}@gitlab.com/pmmquickstartguides/systemtests.git
      #    - cd systemtests
      #    - go test -v ./... -aws_region=us-west-1

#US-EAST-2
deploy-us-east-2:
  stage: deploy-us-east-2
  environment: test-us-east-2
  image: python:latest
  rules:
    - if: $CI_COMMIT_BRANCH != $CI_DEFAULT_BRANCH && $CI_PIPELINE_SOURCE != "merge_request_event"
  before_script:
    - pip3 install awscli --upgrade
    - pip3 install aws-sam-cli --upgrade
    - wget https://golang.org/dl/go1.16.6.linux-amd64.tar.gz
    - rm -rf /usr/local/go && tar -C /usr/local -xzf go1.16.6.linux-amd64.tar.gz
    - export PATH=$PATH:/usr/local/go/bin
    - go version
  script:
    - export AWS_ACCESS_KEY_ID=$AWS_ACCESS_KEY_ID
    - export AWS_SECRET_ACCESS_KEY=$AWS_SECRET_ACCESS_KEY
    - sam build
    - sam package --output-template-file submit-image-packaged.yaml --s3-bucket open-devops-code-us-east-2-$AWS_ACCOUNT_ID --region us-east-2
    - sam deploy --template-file submit-image-packaged.yaml --stack-name OpenDevOpsSubmitImage  --s3-bucket open-devops-code-us-east-2-$AWS_ACCOUNT_ID --capabilities CAPABILITY_IAM --region us-east-2 --no-fail-on-empty-changeset

      #test-us-east-2:
      #  stage: test-us-east-2
      #  environment: test-us-east-2
      #  image: golang:buster
      #  rules:
      #    - if: $CI_COMMIT_BRANCH != $CI_DEFAULT_BRANCH && $CI_PIPELINE_SOURCE != "merge_request_event"
      #  script:
      #    - export AWS_ACCESS_KEY_ID=$AWS_ACCESS_KEY_ID
      #    - export AWS_SECRET_ACCESS_KEY=$AWS_SECRET_ACCESS_KEY
      #    - git clone https://${gitlab_deploy_token}:${gitlab_deploy_password}@gitlab.com/pmmquickstartguides/systemtests.git
      #    - cd systemtests
      #    - go test -v ./... -aws_region=us-east-2

#US-WEST-2
deploy-us-west-2:
  stage: deploy-us-west-2
  environment: production-us-west-2
  image: python:latest
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH && $CI_PIPELINE_SOURCE != "merge_request_event"
  before_script:
    - pip3 install awscli --upgrade
    - pip3 install aws-sam-cli --upgrade
    - wget https://golang.org/dl/go1.16.6.linux-amd64.tar.gz
    - rm -rf /usr/local/go && tar -C /usr/local -xzf go1.16.6.linux-amd64.tar.gz
    - export PATH=$PATH:/usr/local/go/bin
    - go version
  script:
    - export AWS_ACCESS_KEY_ID=$AWS_ACCESS_KEY_ID
    - export AWS_SECRET_ACCESS_KEY=$AWS_SECRET_ACCESS_KEY
    - sam build
    - sam package --output-template-file submit-image-packaged.yaml --s3-bucket open-devops-code-us-west-2-$AWS_ACCOUNT_ID --region us-west-2
    - sam deploy --template-file submit-image-packaged.yaml --stack-name OpenDevOpsSubmitImage  --s3-bucket open-devops-code-us-west-2-$AWS_ACCOUNT_ID --capabilities CAPABILITY_IAM --region us-west-2 --no-fail-on-empty-changeset

      #test-us-west-2:
      #  stage: test-us-west-2
      #  environment: production-us-west-2
      #  image: golang:buster
      #  rules:
      #    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH && $CI_PIPELINE_SOURCE != "merge_request_event"
      #  script:
      #    - export AWS_ACCESS_KEY_ID=$AWS_ACCESS_KEY_ID
      #    - export AWS_SECRET_ACCESS_KEY=$AWS_SECRET_ACCESS_KEY
      #    - git clone https://${gitlab_deploy_token}:${gitlab_deploy_password}@gitlab.com/pmmquickstartguides/systemtests.git
      #    - cd systemtests
      #    - go test -v ./... -aws_region=us-west-2

#US-EAST-1
deploy-us-east-1:
  stage: deploy-us-east-1
  environment: production-us-east-1
  image: python:latest
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH && $CI_PIPELINE_SOURCE != "merge_request_event"
  before_script:
    - pip3 install awscli --upgrade
    - pip3 install aws-sam-cli --upgrade
    - wget https://golang.org/dl/go1.16.6.linux-amd64.tar.gz
    - rm -rf /usr/local/go && tar -C /usr/local -xzf go1.16.6.linux-amd64.tar.gz
    - export PATH=$PATH:/usr/local/go/bin
    - go version
  script:
    - export AWS_ACCESS_KEY_ID=$AWS_ACCESS_KEY_ID
    - export AWS_SECRET_ACCESS_KEY=$AWS_SECRET_ACCESS_KEY
    - sam build
    - sam package --output-template-file submit-image-packaged.yaml --s3-bucket open-devops-code-us-east-1-$AWS_ACCOUNT_ID --region us-east-1
    - sam deploy --template-file submit-image-packaged.yaml --stack-name OpenDevOpsSubmitImage  --s3-bucket open-devops-code-us-east-1-$AWS_ACCOUNT_ID --capabilities CAPABILITY_IAM --region us-east-1 --no-fail-on-empty-changeset

      #test-us-east-1:
      #  stage: test-us-east-1
      #  environment: production-us-east-1
      #  image: golang:buster
      #  rules:
      #    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH && $CI_PIPELINE_SOURCE != "merge_request_event"
      #  script:
      #    - export AWS_ACCESS_KEY_ID=$AWS_ACCESS_KEY_ID
      #    - export AWS_SECRET_ACCESS_KEY=$AWS_SECRET_ACCESS_KEY
      #    - git clone https://${gitlab_deploy_token}:${gitlab_deploy_password}@gitlab.com/pmmquickstartguides/systemtests.git
      #    - cd systemtests
      #    - go test -v ./... -aws_region=us-east-1

#CA-CENTRAL-1
deploy-central-1:
  stage: deploy-ca-central-1
  environment: production-ca-central-1
  image: python:latest
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH && $CI_PIPELINE_SOURCE != "merge_request_event"
  before_script:
    - pip3 install awscli --upgrade
    - pip3 install aws-sam-cli --upgrade
    - wget https://golang.org/dl/go1.16.6.linux-amd64.tar.gz
    - rm -rf /usr/local/go && tar -C /usr/local -xzf go1.16.6.linux-amd64.tar.gz
    - export PATH=$PATH:/usr/local/go/bin
    - go version
  script:
    - export AWS_ACCESS_KEY_ID=$AWS_ACCESS_KEY_ID
    - export AWS_SECRET_ACCESS_KEY=$AWS_SECRET_ACCESS_KEY
    - sam build
    - sam package --output-template-file submit-image-packaged.yaml --s3-bucket open-devops-code-ca-central-1-$AWS_ACCOUNT_ID --region ca-central-1
    - sam deploy --template-file submit-image-packaged.yaml --stack-name OpenDevOpsSubmitImage  --s3-bucket open-devops-code-ca-central-1-$AWS_ACCOUNT_ID --capabilities CAPABILITY_IAM --region ca-central-1 --no-fail-on-empty-changeset

      #test-central-1:
      #  stage: test-ca-central-1
      #  environment: production-ca-central-1
      #  image: golang:buster
      #  rules:
      #    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH && $CI_PIPELINE_SOURCE != "merge_request_event"
      #  script:
      #    - export AWS_ACCESS_KEY_ID=$AWS_ACCESS_KEY_ID
      #    - export AWS_SECRET_ACCESS_KEY=$AWS_SECRET_ACCESS_KEY
      #    - git clone https://${gitlab_deploy_token}:${gitlab_deploy_password}@gitlab.com/pmmquickstartguides/systemtests.git
      #    - cd systemtests
      #    - go test -v ./... -aws_region=ca-central-1

통합 테스트 실행은 지금 주석 처리되어 있습니다. 시스템 테스트는 전체 애플리케이션이 배포된 후에만 통과합니다. 리포지토리 통합 테스트 단계의 주석 처리를 제거하고 ImageLabeller의 모든 컴포넌트가 배포된 후에 배포 파이프라인을 실행하려면 다시 한번 푸시하세요. SystemTests가 SystemTests 리포지토리가 되려면 git clone 라인을 업데이트해야 합니다.

.gitlab-ci.yml 파일 이해하기

이 단계는 SubmitImage 리포지토리의 일부인 단위 테스트를 실행합니다.

unit-test-us-west-1:
  stage: unit-test-us-west-1
  environment: test-us-west-1
  image: golang:buster
  rules:
    - if: $CI_COMMIT_BRANCH != $CI_DEFAULT_BRANCH && $CI_PIPELINE_SOURCE != "merge_request_event"
  script:
    - cd submitImage
    - go test ./opendevopslambda/...

이 단계는 AWS SAM을 사용하여 SubmitImage AWS Lambda를 배포합니다. before_script 섹션에 주목하세요. 이 단계는 스크립트 섹션 전에 실행되며 종속성을 설치하고 다양한 도구를 설정하는 데 사용할 수 있습니다.

deploy-us-west-1:
  stage: deploy-us-west-1
  environment: test-us-west-1
  image: python:latest
  rules:
    - if: $CI_COMMIT_BRANCH != $CI_DEFAULT_BRANCH && $CI_PIPELINE_SOURCE != "merge_request_event"
  before_script:
    - pip3 install awscli --upgrade
    - pip3 install aws-sam-cli --upgrade
    - wget https://golang.org/dl/go1.16.6.linux-amd64.tar.gz
    - rm -rf /usr/local/go && tar -C /usr/local -xzf go1.16.6.linux-amd64.tar.gz
    - export PATH=$PATH:/usr/local/go/bin
    - go version
  script:
    - export AWS_ACCESS_KEY_ID=$AWS_ACCESS_KEY_ID
    - export AWS_SECRET_ACCESS_KEY=$AWS_SECRET_ACCESS_KEY
    - sam build
    - sam package --output-template-file submit-image-packaged.yaml --s3-bucket open-devops-code-us-west-1-$AWS_ACCOUNT_ID --region us-west-1
    - sam deploy --template-file submit-image-packaged.yaml --stack-name OpenDevOpsSubmitImage  --s3-bucket open-devops-code-us-west-1-$AWS_ACCOUNT_ID --capabilities CAPABILITY_IAM --region us-west-1 --no-fail-on-empty-changeset

이 단계는 SystemTests 리포지토리에서 통합 테스트를 다운로드하고 실행합니다. SystemTests가 SystemTests 리포지토리가 되려면 git clone 라인을 업데이트해야 합니다.

test-us-west-1:
  stage: test-us-west-1
  environment: test-us-west-1
  image: golang:buster
  rules:
    - if: $CI_COMMIT_BRANCH != $CI_DEFAULT_BRANCH && $CI_PIPELINE_SOURCE != "merge_request_event"
  script:
    - export AWS_ACCESS_KEY_ID=$AWS_ACCESS_KEY_ID
    - export AWS_SECRET_ACCESS_KEY=$AWS_SECRET_ACCESS_KEY
    - git clone https://${gitlab_deploy_token}:${gitlab_deploy_password}@gitlab.com/pmmquickstartguides/systemtests.git
    - cd systemtests
    - go test -v ./... -aws_region=us-west-1

앞서 만든 배포 토큰은 git clone 라인에서 참조됩니다.

- git clone https://${gitlab_deploy_token}:${gitlab_deploy_password}@gitlab.com/pmmquickstartguides/systemtests.git

기능 브랜치로 푸시

명령줄에서 다음을 실행하여 SubmitImage 리포지토리의 IM-8 브랜치로 변경 사항을 푸시합니다. 커밋 메시지에 Jira 이슈 ID 및 브랜치 이름을 포함하면 Jira GitLab 통합이 프로젝트 진행 상황을 추적하도록 할 수 있습니다.

git add --all
git commit -m "IM-8 add .gitlab-ci.yml to SubmitImage"
git push -u origin IM-8

CI/CD를 클릭한 다음 파이프라인을 클릭하여 파이프라인이 실행되는 것을 확인합니다.

GitLab의 파이프라인 실행 스크린샷

병합 요청 만들기

GitLab이 테스트 환경에 배포한 후에 프로덕션 환경에 배포할 병합 요청을 만듭니다. IM-8 브랜치를 선택합니다.

GitLab의 병합 요청 스크린샷

CI/CD를 클릭한 다음 파이프라인을 클릭하여 병합 요청 파이프라인이 실행되는 것을 확인합니다.

GitLab에서 병합 요청을 실행하는 스크린샷

병합 요청 파이프라인이 완료된 후에 변경 사항을 메인 라인에 병합합니다. CI/CD를 클릭한 다음 파이프라인을 클릭하여 프로덕션 파이프라인이 실행되는 것을 확인합니다.

GitLab에서 실행 중인 프로덕션 파이프라인의 스크린샷

InvokeLabeller AWS Lambda용 리포지토리 만들기

Jira로 이동하여 GitLab에 InvokeLabeller AWS Lambda 리포지토리를 추가하기 위한 새 이슈를 만듭니다. 이슈 ID를 기록해 두세요. 이 예에서는 IM-10입니다.

GitLab의 Jira 이슈 리포지토리 만들기 "invokelabeller"의 스크린샷

GitLab으로 이동하여 새 프로젝트를 클릭한 다음 빈 프로젝트 만들기를 클릭합니다. 프로젝트 이름을 추가하고 프로젝트 URL에서 적절한 그룹을 선택합니다. 프로젝트 만들기를 클릭하여 진행합니다.

GitLab에서 새 프로젝트 만들기 "invokelabeller"의 스크린샷

터미널에서 InvokeLabeller 리포지토리로 이동하고 다음을 실행하여 코드를 GitLab으로 푸시합니다.

git add --all
git commit -m "IM-10 add InvokeLabeller to gitlab"
git remote add origin git@gitlab.com:pmmquickstartguides/invokelabeller.git
git branch -m mainline
git push -u origin mainline

AWS 액세스 키를 추가하고 보호되는 브랜치를 구성하고 배포 환경을 설정해야 합니다.

그런 다음 SystemTests 리포지토리에서 배포 키를 추가하여 InvokeLabeller GitLab 파이프라인이 SystemTests를 다운로드하고 실행할 수 있도록 합니다.

마지막으로 AWS 계정 ID를 CI/CD 변수로 추가합니다.

GitLab의 변수 페이지 스크린샷

AWS에 배포하기 위한 .gitlab-ci.yml

터미널에 있는 InvokeLabeller 리포지토리로 이동하여 Jira 이슈 ID의 이름을 딴 브랜치를 만듭니다.

git checkout -b IM-10

다음 yaml로 .gitlab-ci.yml 파일을 만듭니다. 이것은 테스트, 스테이징, 프로덕션 환경을 위한 배포 워크플로를 정의합니다. SystemTests가 SystemTests 리포지토리가 되려면 git clone 라인을 업데이트해야 합니다.

stages:
  - merge-request
  - run-unit-tests
#US-WEST-1
  - deploy-us-west-1
  - test-us-west-1
#US-EAST-2
  - deploy-us-east-2
  - test-us-east-2
#US-WEST-2
  - deploy-us-west-2
  - test-us-west-2
#US-EAST-1
  - deploy-us-east-1
  - test-us-east-1
#CA-CENTRAL-1
  - deploy-ca-central-1
  - test-ca-central-1

merge-request-pipeline-job:
  stage: merge-request
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
  script:
    - echo "This pipeline always succeeds and enables merge"
    - echo true

run-unit-tests:
  stage: run-unit-tests
  image: python:3.8-buster
  rules:
    - if: $CI_COMMIT_BRANCH != $CI_DEFAULT_BRANCH && $CI_PIPELINE_SOURCE != "merge_request_event"
  before_script:
    - pip3 install pytest
    - pip3 install moto
    - pip3 install -r tst/requirements.txt --user
  script:
    - python3 -m pytest -v tst/unit --junitxml=test-reports/report.xml

#US-WEST-1
deploy-us-west-1:
  stage: deploy-us-west-1
  environment: test-us-west-1
  image: python:3.8-buster
  rules:
    - if: $CI_COMMIT_BRANCH != $CI_DEFAULT_BRANCH && $CI_PIPELINE_SOURCE != "merge_request_event"
  before_script:
    - pip3 install awscli --upgrade
    - pip3 install aws-sam-cli --upgrade
  script:
    - export AWS_ACCESS_KEY_ID=$AWS_ACCESS_KEY_ID
    - export AWS_SECRET_ACCESS_KEY=$AWS_SECRET_ACCESS_KEY
    - sam build
    - sam package --output-template-file invoke-labeller-packaged.yaml --s3-bucket open-devops-code-us-west-1-$AWS_ACCOUNT_ID --region us-west-1
    - sam deploy --template-file invoke-labeller-packaged.yaml --stack-name OpenDevOpsInvokeLabeller  --s3-bucket open-devops-code-us-west-1-$AWS_ACCOUNT_ID --capabilities CAPABILITY_IAM --region us-west-1 --no-fail-on-empty-changeset

      #test-us-west-1:
      #  stage: test-us-west-1
      #  environment: test-us-west-1
      #  image: golang:buster
      #  rules:
      #    - if: $CI_COMMIT_BRANCH != $CI_DEFAULT_BRANCH && $CI_PIPELINE_SOURCE != "merge_request_event"
      #  script:
      #    - export AWS_ACCESS_KEY_ID=$AWS_ACCESS_KEY_ID
      #    - export AWS_SECRET_ACCESS_KEY=$AWS_SECRET_ACCESS_KEY
      #    - git clone https://${gitlab_deploy_token}:${gitlab_deploy_password}@gitlab.com/pmmquickstartguides/systemtests.git
      #    - cd systemtests
      #    - go test -v ./... -aws_region=us-west-1

#US-EAST-2
deploy-us-east-2:
  stage: deploy-us-east-2
  environment: test-us-east-2
  image: python:3.8-buster
  rules:
    - if: $CI_COMMIT_BRANCH != $CI_DEFAULT_BRANCH && $CI_PIPELINE_SOURCE != "merge_request_event"
  before_script:
    - pip3 install awscli --upgrade
    - pip3 install aws-sam-cli --upgrade
  script:
    - export AWS_ACCESS_KEY_ID=$AWS_ACCESS_KEY_ID
    - export AWS_SECRET_ACCESS_KEY=$AWS_SECRET_ACCESS_KEY
    - sam build
    - sam package --output-template-file invoke-labeller-packaged.yaml --s3-bucket open-devops-code-us-east-2-$AWS_ACCOUNT_ID --region us-east-2
    - sam deploy --template-file invoke-labeller-packaged.yaml --stack-name OpenDevOpsInvokeLabeller  --s3-bucket open-devops-code-us-east-2-$AWS_ACCOUNT_ID --capabilities CAPABILITY_IAM --region us-east-2 --no-fail-on-empty-changeset

      #test-us-east-2:
      #  stage: test-us-east-2
      #  environment: test-us-east-2
      #  image: golang:buster
      #  rules:
      #    - if: $CI_COMMIT_BRANCH != $CI_DEFAULT_BRANCH && $CI_PIPELINE_SOURCE != "merge_request_event"
      #  script:
      #    - export AWS_ACCESS_KEY_ID=$AWS_ACCESS_KEY_ID
      #    - export AWS_SECRET_ACCESS_KEY=$AWS_SECRET_ACCESS_KEY
      #    - git clone https://${gitlab_deploy_token}:${gitlab_deploy_password}@gitlab.com/pmmquickstartguides/systemtests.git
      #    - cd systemtests
      #    - go test -v ./... -aws_region=us-east-2

#US-WEST-2
deploy-us-west-2:
  stage: deploy-us-west-2
  environment: production-us-west-2
  image: python:3.8-buster
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH && $CI_PIPELINE_SOURCE != "merge_request_event"
  before_script:
    - pip3 install awscli --upgrade
    - pip3 install aws-sam-cli --upgrade
  script:
    - export AWS_ACCESS_KEY_ID=$AWS_ACCESS_KEY_ID
    - export AWS_SECRET_ACCESS_KEY=$AWS_SECRET_ACCESS_KEY
    - sam build
    - sam package --output-template-file invoke-labeller-packaged.yaml --s3-bucket open-devops-code-us-west-2-$AWS_ACCOUNT_ID --region us-west-2
    - sam deploy --template-file invoke-labeller-packaged.yaml --stack-name OpenDevOpsInvokeLabeller  --s3-bucket open-devops-code-us-west-2-$AWS_ACCOUNT_ID --capabilities CAPABILITY_IAM --region us-west-2 --no-fail-on-empty-changeset

      #test-us-west-2:
      #  stage: test-us-west-2
      #  environment: production-us-west-2
      #  image: golang:buster
      #  rules:
      #    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH && $CI_PIPELINE_SOURCE != "merge_request_event"
      #  script:
      #    - export AWS_ACCESS_KEY_ID=$AWS_ACCESS_KEY_ID
      #    - export AWS_SECRET_ACCESS_KEY=$AWS_SECRET_ACCESS_KEY
      #    - git clone https://${gitlab_deploy_token}:${gitlab_deploy_password}@gitlab.com/pmmquickstartguides/systemtests.git
      #    - cd systemtests
      #    - go test -v ./... -aws_region=us-west-2

#US-EAST-1
deploy-us-east-1:
  stage: deploy-us-east-1
  environment: production-us-east-1
  image: python:3.8-buster
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH && $CI_PIPELINE_SOURCE != "merge_request_event"
  before_script:
    - pip3 install awscli --upgrade
    - pip3 install aws-sam-cli --upgrade
  script:
    - export AWS_ACCESS_KEY_ID=$AWS_ACCESS_KEY_ID
    - export AWS_SECRET_ACCESS_KEY=$AWS_SECRET_ACCESS_KEY
    - sam build
    - sam package --output-template-file invoke-labeller-packaged.yaml --s3-bucket open-devops-code-us-east-1-$AWS_ACCOUNT_ID --region us-east-1
    - sam deploy --template-file invoke-labeller-packaged.yaml --stack-name OpenDevOpsInvokeLabeller  --s3-bucket open-devops-code-us-east-1-$AWS_ACCOUNT_ID --capabilities CAPABILITY_IAM --region us-east-1 --no-fail-on-empty-changeset

      #test-us-east-1:
      #  stage: test-us-east-1
      #  environment: production-us-east-1
      #  image: golang:buster
      #  rules:
      #    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH && $CI_PIPELINE_SOURCE != "merge_request_event"
      #  script:
      #    - export AWS_ACCESS_KEY_ID=$AWS_ACCESS_KEY_ID
      #    - export AWS_SECRET_ACCESS_KEY=$AWS_SECRET_ACCESS_KEY
      #    - git clone https://${gitlab_deploy_token}:${gitlab_deploy_password}@gitlab.com/pmmquickstartguides/systemtests.git
      #    - cd systemtests
      #    - go test -v ./... -aws_region=us-east-1

#CA-CENTRAL-1
deploy-central-1:
  stage: deploy-ca-central-1
  environment: production-ca-central-1
  image: python:3.8-buster
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH && $CI_PIPELINE_SOURCE != "merge_request_event"
  before_script:
    - pip3 install awscli --upgrade
    - pip3 install aws-sam-cli --upgrade
  script:
    - export AWS_ACCESS_KEY_ID=$AWS_ACCESS_KEY_ID
    - export AWS_SECRET_ACCESS_KEY=$AWS_SECRET_ACCESS_KEY
    - sam build
    - sam package --output-template-file invoke-labeller-packaged.yaml --s3-bucket open-devops-code-ca-central-1-$AWS_ACCOUNT_ID --region ca-central-1
    - sam deploy --template-file invoke-labeller-packaged.yaml --stack-name OpenDevOpsInvokeLabeller  --s3-bucket open-devops-code-ca-central-1-$AWS_ACCOUNT_ID --capabilities CAPABILITY_IAM --region ca-central-1 --no-fail-on-empty-changeset

      #test-central-1:
      #  stage: test-ca-central-1
      #  environment: production-ca-central-1
      #  image: golang:buster
      #  rules:
      #    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH && $CI_PIPELINE_SOURCE != "merge_request_event"
      #  script:
      #    - export AWS_ACCESS_KEY_ID=$AWS_ACCESS_KEY_ID
      #    - export AWS_SECRET_ACCESS_KEY=$AWS_SECRET_ACCESS_KEY
      #    - git clone https://${gitlab_deploy_token}:${gitlab_deploy_password}@gitlab.com/pmmquickstartguides/systemtests.git
      #    - cd systemtests
      #    - go test -v ./... -aws_region=ca-central-1

통합 테스트 실행은 지금 주석 처리되어 있습니다. 시스템 테스트는 전체 애플리케이션이 배포된 후에만 통과합니다. 리포지토리 통합 테스트 단계의 주석 처리를 제거하고 ImageLabeller의 모든 컴포넌트가 배포된 후에 배포 파이프라인을 실행하려면 다시 한번 푸시하세요. SystemTests가 SystemTests 리포지토리가 되려면 git clone 라인을 업데이트해야 합니다.

AWS SageMaker 엔드포인트로 src/app.py 업데이트

InvokeLabeller의 src/app.py 파일을 열고 query_endpoint를 찾습니다. endpoint_name 및 클라이언트 region_name을 AWS SageMaker 노트북과 일치하도록 변경합니다.

def query_endpoint(img):
  endpoint_name = 'jumpstart-dft-image-labeller-endpoint'
  client = boto3.client(service_name='runtime.sagemaker', region_name='us-west-1')
  response = client.invoke_endpoint(EndpointName=endpoint_name, ContentType='application/x-image', Body=img)
  model_predictions = json.loads(response['Body'].read())['predictions'][0]
  return model_predictions

기능 브랜치로 푸시

명령줄에서 다음을 실행하여 InvokeLabeller 리포지토리의 IM-10 브랜치로 변경 사항을 푸시합니다. 커밋 메시지에 Jira 이슈 ID 및 브랜치 이름을 포함하면 Jira GitLab 통합이 프로젝트 진행 상황을 추적하도록 할 수 있습니다.

git add --all
git commit -m "IM-10 add .gitlab-ci.yml to InvokeLabeller"
git push -u origin IM-10

CI/CD를 클릭한 다음 파이프라인을 클릭하여 파이프라인이 실행되는 것을 확인합니다.

GitLab의 파이프라인 실행 스크린샷

병합 요청 만들기

GitLab이 테스트 환경에 배포한 후에 프로덕션 환경에 배포할 병합 요청을 만듭니다. IM-10 브랜치를 선택합니다.

GitLab에서 병합 요청을 만드는 스크린샷

병합 요청 파이프라인이 완료된 후에 변경 사항을 메인 라인에 병합합니다. CI/CD를 클릭한 다음 파이프라인을 클릭하여 프로덕션 파이프라인이 실행되는 것을 확인합니다.

GitLab에서 실행 중인 프로덕션 파이프라인의 스크린샷

여기까지 완료하셨나요? 축하합니다! 방금 ImageLabeller를 배포했습니다. 다음 단계는 Opsgenie로 ImageLabeller 모니터링을 설정하는 것입니다.

Warren Marusiak
Warren Marusiak

Warren is a Canadian developer from Vancouver, BC with over 10 years of experience. He came to Atlassian from AWS in January of 2021.


이 문서 공유

여러분께 도움을 드릴 자료를 추천합니다.

이러한 리소스에 책갈피를 지정하여 DevOps 팀의 유형에 대해 알아보거나 Atlassian에서 DevOps에 대한 지속적인 업데이트를 확인하세요.

DevOps 일러스트레이션

DevOps 커뮤니티

DevOps 일러스트레이션

DevOps 학습 경로

맵 일러스트레이션

무료로 사용해보기

DevOps 뉴스레터 신청

Thank you for signing up