Cloud Build로 Salesforce용 서버리스 DevOps 파이프라인 빌드

Last reviewed 2021-02-22 UTC

이 튜토리얼에서는 Salesforce Developer Experience(SFDX) 및 Cloud Build를 사용하여 Salesforce용 서버리스 지속적 통합/지속적 배포(CI/CD) 파이프라인을 빌드하는 방법을 보여줍니다. Cloud Build 파이프라인은 컨테이너화를 사용합니다. 파이프라인은 빌드 단계에서 일련의 빌드를 실행합니다. 이때 각 빌드 단계는 Docker 컨테이너에서 실행됩니다. 이 파이프라인은 서버를 사전 프로비저닝할 필요 없이 로드에 따라 수직 확장 및 축소될 수 있으며, 빠르고 일관성 있는 자동화 빌드를 제공합니다.

이 튜토리얼은 조직의 DevOps 워크플로를 설계, 개발, 유지관리할 책임이 있는 모든 사용자를 대상으로 합니다. 이러한 역할에는 설계자, DevOps 팀, 엔지니어가 포함될 수 있습니다. 문서의 여러 섹션에서는 다양한 역할의 파이프라인 부분을 보여줍니다. 예를 들어 한 부분은 관리자 및 DevOps 리드를, 다른 부분은 Salesforce 개발자를 위한 것입니다.

이 문서에서는 사용자가 Salesforce DX, Salesforce CLI, Git, GitHub, Docker, Cloud Build와 같은 Google Cloud 제품, 컨테이너화 개념에 익숙하다고 가정합니다. 또한 GitHub 계정이 있다고 가정합니다.

소프트웨어 개발 수명 주기는 매우 다양할 수 있습니다. 이 튜토리얼에서는 애자일 출시 방법을 사용한다고 가정합니다.

목표

Salesforce 개발자 환경을 설정합니다.
Git 분기 전략을 설정합니다.
Cloud Build를 구성합니다.
Google Cloud 빌드 도구 및 GitHub를 사용하여 Salesforce용 CI/CD 파이프라인을 실행합니다.

비용

이 튜토리얼에서는 비용이 청구될 수 있는 다음과 같은 Google Cloud 구성요소를 사용합니다.

가격 계산기를 사용하면 예상 사용량을 토대로 예상 비용을 산출할 수 있습니다.

Salesforce 비용이 발생할 수도 있습니다. 이 튜토리얼에서는 무료로 사용할 수 있는 Salesforce Developer Edition 조직을 사용합니다. 자세한 내용은 Developer Edition에 대한 Salesforce 페이지를 참조하세요.

시작하기 전에

Google Cloud Console의 프로젝트 선택기 페이지에서 Google Cloud 프로젝트를 선택하거나 만듭니다.

참고: 이 절차에서 생성한 리소스를 유지하지 않으려면 기존 프로젝트를 선택하지 말고 프로젝트를 새로 만드세요. 작업이 끝나면 프로젝트를 삭제하여 프로젝트와 관련된 모든 리소스를 삭제할 수 있습니다.

프로젝트 선택기로 이동
Google Cloud 프로젝트에 결제가 사용 설정되어 있는지 확인합니다.
Cloud Build API 사용 설정
API 사용 설정
Google Cloud 콘솔에서 Cloud Shell을 활성화합니다.

Cloud Shell 활성화
Salesforce 계정이 있어야 Dev Hub 조직의 역할을 맡을 수 있습니다. 조직이 없으면 Salesforce 개발자 사이트에서 Developer Edition 계정을 만들 수 있습니다.

이 튜토리얼을 마치면 만든 리소스를 삭제하여 비용이 계속 청구되지 않도록 할 수 있습니다. 자세한 내용은 삭제를 참조하세요.

아키텍처

다음 다이어그램은 이 튜토리얼에서 만든 CI/CD 워크플로의 아키텍처를 보여줍니다. 이 아키텍처에서는 프로젝트가 출시로 구성됩니다. 기능을 사용하려는 개발자는 출시 분기에서 새로운 기능 분기를 만듭니다.

분기 만들기, pull 요청 만들기, 기본 분기로 변경사항 병합 과정을 보여주는 파이프라인 아키텍처 몇 가지 단계는 Cloud Build 작업을 트리거합니다.

다이어그램은 다음 흐름을 보여줍니다.

개발자가 GitHub에서 개발 중인 기능에 대한 기능 분기를 만듭니다.
개발자가 Salesforce 스크래치 조직에서 개발 작업을 완료하고 단위 테스트를 실행합니다.
개발자가 개발 작업을 커밋하고 소스 코드 저장소에 푸시합니다(이 튜토리얼에서는 GitHub).
개발자가 작업을 출시 분기에 병합하는 pull 요청을 만듭니다.
pull 요청을 만들면 Cloud Build 작업이 자동으로 트리거되어 테스트를 실행합니다.
담당 직원(일반적으로 팀 책임자)이 개발 작업을 출시 분기에 병합하는 pull 요청을 검토하고 승인합니다.
출시 분기에 병합되면 Cloud Build 작업이 자동으로 트리거되어 코드베이스가 품질보증 또는 다른 Salesforce 환경에 배포됩니다.
선택적으로 품질보증 환경에서 수동 테스트 및 검토가 수행됩니다.
담당 직원이 코드를 main 분기로 병합하는 pull 요청을 만듭니다.
main 분기에 대한 pull 요청이 Cloud Build 작업을 트리거하여 프로덕션에 코드가 배포됩니다.

프로젝트를 사용하려는 개발자는 엔터프라이즈 소스 제어 도구(이 튜토리얼의 GitHub)에서 프로젝트 저장소를 클론하는 것으로 시작합니다. 다음 다이어그램은 이 전략을 그래프로 보여줍니다.

전략 한 분기가 여러 기능 분기로 분할된 후 출시 분기로 다시 개별적으로 병합되고 기본 분기로 다시 병합되는 일련의 버전으로 표시된 분기

이 다이어그램에서 볼 수 있듯이, 분기 전략은 다음과 같이 구성됩니다.

기본 분기. 기본 분기의 코드는 프로덕션에서 실행 중인 코드의 현재 버전을 나타냅니다.
출시 분기. 출시 분기는 기능 분기보다 상대적으로 더 오래 지속되는 분기로, 출시 버전과 관련된 모든 변경사항과 코드를 통합합니다. 조직은 새 출시 버전마다 새 출시 분기를 만듭니다.
하나 이상의 기능 분기. 기능 분기를 사용하면 진행 중인 작업을 기본 분기의 최신 코드 버전과 격리할 수 있습니다. 일반적으로 출시 분기는 여러 기능 분기로 구성됩니다. 개발자는 버그 수정을 위한 기능 분기를 만드는 것이 좋습니다.

개발자는 프로젝트 저장소를 클론한 후 로컬 머신 또는 Salesforce 스크래치 조직에서 개발합니다. 개발자는 스크래치 조직을 사용하여 변경사항에 대한 단위 테스트를 실행할 수 있습니다. 단위 테스트가 통과하면 코드를 커밋하고 소스 코드 저장소에 푸시합니다. 그런 다음 코드에 상위 출시 분기로 병합할 pull 요청을 생성합니다.

pull 요청은 다음을 수행하는 Cloud Build 작업을 자동으로 트리거합니다.

단위 테스트를 실행할 새 스크래치 조직을 만듭니다.
테스트 결과로 pull 요청을 업데이트합니다.

이때 팀 리드와 제품 소유자는 pull 요청을 검토할 수 있습니다. 요청이 승인되면 변경사항이 출시 분기에 병합됩니다.

소프트웨어 개발 수명 주기에 따라 출시 분기에 대한 병합에 따라 트리거되는 자동화된 단계가 더 있을 수 있습니다. 자동화된 단계의 예로는 검증된 코드를 품질 보증 또는 시스템 통합 테스트 샌드박스와 같은 상위 샌드박스로 배포하는 작업 등이 있습니다.

Cloud Functions, Cloud Run 또는 기타 Google Cloud 도구를 사용하여 빌드 알림을 보내고 추가 작업을 수행하도록 Cloud Build를 구성할 수도 있습니다. (이러한 추가 작업은 이 튜토리얼에서 다루지 않습니다.) 이 접근방식은 엔터프라이즈 DevOps 프레임워크를 수용하도록 파이프라인을 맞춤설정할 수 있는 유연성을 제공합니다.

이 튜토리얼에서는 편의를 위해 샘플 코드베이스를 단일 Salesforce 조직(Dev Hub)에 배포합니다. 프로덕션용 CI/CD 파이프라인을 빌드할 때는 앞에서 설명한 아키텍처를 사용하고 소프트웨어 개발 수명 주기의 일부인 샌드박스에 대한 배포를 자동화합니다.

일반적으로 소프트웨어 개발에 참여하는 사람

모든 조직은 다르며 각각 고유한 역할과 팀이 있습니다. 다음 표에서는 이 튜토리얼에 설명된 것과 같은 Salesforce DevOps 파이프라인과 일반적으로 상호작용하는 핵심 캐릭터(역할) 목록을 보여줍니다.

서로 다른 역할의 사용자는 Salesforce 파이프라인 설정에 대한 책임이 다릅니다. 따라서 이 튜토리얼에는 두 개의 경로가 있습니다. 한 경로는 관리자 및 DevOps 리드를, 다른 경로는 개발자를 위한 것입니다.

캐릭터	책임
관리자 또는 DevOps 리드	Dev Hub 조직을 설정합니다. 사용자가 Salesforce CLI에서 Dev Hub 조직에 연결하는 데 사용되는 인증서를 생성합니다. DevOps 파이프라인을 사용하여 코드가 배포되는 모든 Salesforce 환경에 연결된 앱을 만듭니다. Dev Hub 조직에서 개발자 계정을 설정합니다. DevOps 파이프라인 및 모든 필수 트리거를 설정합니다. 소스 코드 저장소를 초기화합니다. Cloud Build 트리거를 설정합니다.
Salesforce 개발자	소스 코드 저장소를 클론합니다. 개발용 Salesforce CLI를 설정합니다. 출시의 기능을 개발하고 단위 테스트합니다. 기능이 완성되면 출시 분기에 기능을 병합하기 위한 pull 요청을 생성합니다.
품질보증 책임자	기능에 대한 개발자의 작업을 출시 분기에 병합하기 위한 pull 요청을 검토 및 승인합니다.
출시 책임자	코드를 기본 분기로 병합하여 프로덕션으로 승격하기 위한 pull 요청을 관리 및 승인합니다.

Salesforce 관리자 및 DevOps 리드를 위한 파이프라인 설정

이 섹션에서는 관리자와 DevOps 팀이 CI/CD 워크플로를 설정하기 위해 수행해야 하는 작업을 설명합니다.

Dev Hub 조직 사용 설정

Salesforce 프로덕션 조직에 로그인합니다.
Setup(설정) 탭의 Quick Find(빠른 찾기) 상자에 Dev Hub를 입력하고 Dev Hub를 선택합니다.
Dev Hub를 사용 설정합니다.

이 단계에서는 스크래치 조직을 설정합니다. 스크래치 조직을 사용하여 튜토리얼의 샘플 코드를 Salesforce Developer Edition 조직에 배포합니다.

인증서 및 키 쌍 만들기

Dev Hub 조직을 사용 설정한 후에는 Salesforce Dev Hub 조직에 인증하는 데 사용할 수 있는 인증서와 키 쌍을 생성해야 합니다. 이 인증서와 키 쌍은 이후 단계에서 Cloud Build를 구성할 때 사용합니다.

프로덕션 CI/CD 파이프라인의 경우 Salesforce 샌드박스에 인증하려면 추가 인증서를 생성해야 합니다. (이 튜토리얼의 일부로 이러한 추가 인증서는 만들지 않습니다.) 각 환경의 인증서와 키 쌍을 생성할 때 다음 예시와 같이 식별 가능한 이름을 지정해야 합니다.

프로덕션(Dev Hub 조직): salesforce.key 및 salesforce.crt. 이 이름은 이후 절차에서 사용합니다.
품질보증 샌드박스(QA): salesforce_qa.key 및 salesforce_qa.crt
통합 개발 샌드박스(IDEV): salesforce_dev.key 및 salesforce_dev.crt

인증서 및 키 쌍을 생성하려면 다음 단계를 따르세요.

Cloud Build가 Salesforce CLI에서 Salesforce Dev Hub 조직에 인증할 수 있도록 Cloud Shell에서 인증서와 키 쌍을 생성합니다.
```
openssl req -x509 -sha256 -nodes -days 36500 -newkey \
rsa:2048 -keyout salesforce.key -out \
salesforce.crt
```
인증서를 식별하기 위한 세부정보를 입력하라는 메시지가 표시됩니다. 이 튜토리얼에서는 이러한 값이 중요하지 않으므로 Enter 키를 눌러 기본값을 사용합니다.

Dev Hub 조직의 인증서와 키 쌍을 만드는 것이므로 명령어에 salesforce.key 및 salesforce.crt라는 이름을 사용합니다.
More(더보기)를 클릭하고 Download File(파일 다운로드)를 선택합니다.
정규화된 파일 경로 상자에 다음과 같은 파일 이름을 입력한 다음 다운로드를 클릭합니다.
```
salesforce.crt
```
이렇게 하면 생성된 인증서가 로컬 머신에 다운로드됩니다. 다음 섹션에서 Salesforce 조직에 인증서를 업로드합니다.

Salesforce에서 연결된 앱 만들기

이 섹션에서는 Cloud Build가 Salesforce 코드를 배포하는 데 사용할 수 있는 연결된 애플리케이션을 만듭니다. 이 튜토리얼에서는 Dev Hub 조직에만 코드를 배포합니다. 프로덕션 환경에서는 Cloud Build가 DevOps 파이프라인의 Salesforce 코드를 배포하려는 프로덕션 조직과 샌드박스에 코드를 배포합니다.

이 프로세스의 일부로 이전 섹션에서 생성한 인증서와 키 쌍을 사용합니다. 인증서는 Cloud Shell 세션에서 Salesforce 클라이언트를 Salesforce Dev Hub 조직(Salesforce 샌드박스)에 인증하기 위한 공개 키입니다. 이 인증서는 자동 배포를 위해 Cloud Build를 인증하는 데에도 사용됩니다.

다음 절차의 일부 단계에 대한 세부정보는 사용 중인 Salesforce 버전에 따라 다릅니다. 선택한 환경에 올바른 인증서와 키 쌍을 사용해야 합니다.

Salesforce Lightning Experience를 사용하는 경우 앱 관리자를 사용하여 연결된 앱을 만듭니다. Salesforce 조직의 설정에서 다음을 수행합니다.
1. 빠른 찾기 상자에 App을 입력합니다.
2. 앱 관리자를 선택합니다.
3. 새로 연결된 앱을 클릭합니다.
Salesforce Classic을 사용하는 경우 Salesforce 조직의 설정에서 다음을 수행합니다.
1. 빠른 찾기 상자에 Apps를 입력합니다.
2. Build(빌드) > Create(만들기)에서 Apps(앱)를 선택합니다.
3. Connected Apps(연결된 앱)에서 New(새로 만들기)를 클릭합니다.
애플리케이션 이름으로 Google Cloud DevOps를 입력합니다.

그러면 API 이름 상자에 Google_Cloud_DevOps가 입력됩니다.
연락처 이메일 정보와 애플리케이션에 적합한 기타 정보를 입력합니다.
OAuth 설정 사용을 선택합니다.
콜백 URL 값에 다음 URL을 입력합니다.
```
http://localhost:1717/OauthRedirect
```
디지털 서명 사용 옵션을 사용 설정하려면 파일 선택을 클릭한 다음 이전에 다운로드한 salesforce.crt 파일을 선택합니다.
다음 OAuth 범위를 선택한 OAuth 범위에 추가합니다.
- 데이터 액세스 및 관리(api)
- 사용자를 대신하여 언제든지 요청 수행(refresh_token, offline_access)
- 웹을 통한 데이터 액세스 제공(web)
Save(저장)와 Continue(계속)를 차례로 클릭합니다.
API 섹션에 표시되는 고객 키 값을 기록합니다. 이는 나중에 Cloud Build 매니페스트를 설정할 때 필요합니다.

프로덕션 환경에서 작업하는 경우 각 배포 환경에 대한 키가 있습니다.
Manage(관리)를 클릭한 후 OAuth 정책을 변경하려면 Edit Policies(정책 수정)를 클릭합니다.
Permitted users(허용된 사용자)를 Admin Approved Users are Pre-Authorized(관리자가 승인한 사용자는 사전 승인 처리됨)로 설정하고 선택을 확인합니다.
IP 완화를 IP 제한사항 완화로 설정합니다.
저장을 클릭합니다.
Manage Profiles(프로필 관리)를 클릭하고 System Administrator(시스템 관리자) 옵션을 선택합니다.

이 단계가 끝나면 이 프로필을 사용하는 사용자가 Salesforce CLI에 로그인할 수 있습니다.
저장을 클릭합니다.

Google Cloud 환경 초기화

Cloud Shell에서 기본 프로젝트로 만들거나 선택한 프로젝트를 설정합니다.
```
gcloud config set project PROJECT_ID
```
PROJECT_ID를 Google Cloud 프로젝트의 ID로 바꿉니다.
리전 및 영역의 설정을 할당합니다.
```
gcloud config set compute/region us-central1
gcloud config set compute/zone us-central1-a
```
이 튜토리얼에서는 us-central1을 리전으로, us-central1-a를 영역으로 사용합니다.

현재 Google 프로젝트 ID를 GCP_PROJECT_NUMBER 환경 변수로 내보냅니다.

export GCP_PROJECT_NUMBER=$(gcloud projects describe $DEVSHELL_PROJECT_ID --format='value(projectNumber)')

Cloud Storage에 Salesforce 키 업로드

Cloud Shell에서 빌드 프로젝트에 Cloud Storage 버킷을 만들어 Salesforce 비공개 키 파일을 저장합니다.
```
gsutil mb -p ${DEVSHELL_PROJECT_ID} -l us-central1 \
    gs://salesforce-ref-${DEVSHELL_PROJECT_ID}
```
버킷에 전역적으로 고유한 이름이 있어야 합니다. 이 명령어는 Google Cloud 프로젝트 ID가 포함된 버킷 이름을 만듭니다.
Dev Hub 조직 사용 설정 섹션에서 생성한 Salesforce 비공개 키를 새 Cloud Storage 버킷에 복사합니다.
```
gsutil cp salesforce.key gs://salesforce-ref-${DEVSHELL_PROJECT_ID}
```

GitHub 저장소 만들기

Cloud Shell에서 이 튜토리얼과 연결된 저장소를 클론합니다.

git clone https://github.com/GoogleCloudPlatform/salesforce-serverless-cicd-cloudbuild

DEV_REPO_NAME이라는 새 GitHub 저장소를 만듭니다.

DEV_REPO_NAME을 로컬에서 저장소에 할당할 이름으로 바꿉니다.

개발자가 코드를 가져오거나 푸시하는 저장소입니다. 이 튜토리얼에서는 자체 GitHub 계정에 이 저장소를 만듭니다.

클론된 저장소로 이동합니다.

cd salesforce-serverless-cicd-cloudbuild

개발자 GitHub 저장소를 원격 저장소로 추가합니다.
```
git remote add github DEV_REPO_NAME
```

Cloud Build 구성

이 섹션에서는 개발자가 작업을 출시 분기에 병합하는 pull 요청을 생성할 때 Cloud Build 작업을 트리거하는 데 필요한 설정 단계를 완료합니다.

이 튜토리얼에서 만든 CI/CD 파이프라인을 위해 두 개의 트리거를 설정합니다.

개발자가 출시 분기에 코드를 병합하기 위해 pull 요청을 만들 때 Cloud Build 작업을 실행하는 트리거입니다. 이 트리거의 일반적인 용도는 단위 테스트를 실행하는 것입니다.
pull 요청이 출시 분기에 병합될 때 Cloud Build 작업을 실행하는 트리거. 이 트리거의 일반적인 용도는 대상 샌드박스(이 튜토리얼의 Dev Hub)에 변경사항을 배포하는 것입니다.

Salesforce DX를 포함하는 기본 이미지 빌드

Cloud Build는 빌드를 단계 집합으로 실행하며 각 단계는 Docker 컨테이너에서 실행됩니다. Salesforce CLI가 포함된 기본 Docker 컨테이너 이미지를 빌드하면 Cloud Build가 Salesforce CLI 명령어를 사용하여 작업을 실행합니다.

Cloud Shell에서 빌드해야 하는 이미지의 Dockerfile을 만듭니다.

cat <<EOF > Dockerfile
FROM debian:buster
RUN apt-get update && \
apt-get install -y wget xz-utils
RUN wget https://developer.salesforce.com/media/salesforce-cli/sfdx-linux-amd64.tar.xz && \
mkdir sfdx && \
tar xJf sfdx-linux-amd64.tar.xz -C sfdx --strip-components 1 && \
./sfdx/install
ENTRYPOINT [ "sfdx" ]
EOF

Docker 이미지의 이름을 SFDX_BASE_IMAGE 환경 변수로 내보냅니다.

export SFDX_BASE_IMAGE="gcr.io/${DEVSHELL_PROJECT_ID}/salesforcedx-base-image:1"

Cloud Build로 컨테이너를 빌드하고 해당 이미지를 Container Registry에 게시합니다.
```
gcloud builds submit --tag ${SFDX_BASE_IMAGE}
```

Cloud Build 작업 구성

cloudbuild.yaml 파일을 수정하여 Cloud Build 작업을 정의합니다.

Cloud Shell에서 Cloud Build가 Salesforce Dev Hub 조직에 코드를 배포할 때 cloudbuild.yaml 파일을 만들어서 실행할 작업 단계를 정의합니다.
```
cat <<EOF > cloudbuild.yaml
steps:
- name: gcr.io/cloud-builders/gsutil
  args: ['cp', 'gs://\${_BUCKET_NAME}/salesforce.key', 'salesforce.key']
- name: "${SFDX_BASE_IMAGE}"
  args:
  - force:auth:jwt:grant
  - --setdefaultusername
  - -u
  - \${_SF_USERNAME}
  - -f
  - ./salesforce.key
  - -i
  - \${_CONSUMER_KEY}
- name: "${SFDX_BASE_IMAGE}"
  args: ['force:source:deploy', '-p', './force-app/']
substitutions:
  _BUCKET_NAME: __BUCKET_NAME__
  _SF_USERNAME: __USERNAME__
  _CONSUMER_KEY: __CONSUMER_KEY__
EOF
```
이 파일은 Cloud Build가 다음 작업을 수행하도록 구성합니다.
1. Cloud Build가 Dev Hub 조직에 인증하는 데 사용하는 salesforce.key 파일을 다운로드합니다.
2. Salesforce DX CLI가 설치된 Docker 컨테이너를 시작하고 JWT 권한 부여를 통해 Dev Hub 조직에 연결합니다. Cloud Build는 Cloud Build 트리거 정의에 있는 고객 키 및 Salesforce 사용자 이름과 같은 구성 매개변수를 사용합니다.
3. 개발자가 Dev Hub 조직이나 프로덕션 CI/CD 파이프라인의 다른 대상 샌드박스에 푸시한 코드를 배포합니다.
참고: 이 튜토리얼이 필요 이상으로 길어지지 않도록 이 단계에서는 Dev Hub 조직에 직접 배포하는 방법을 보여줍니다. 프로덕션 CI/CD 파이프라인에서는 일반적으로 품질보증 (QA) 또는 사용자 승인 테스트 (UAT) 샌드박스와 같은 테스트 환경에 배포할 때 트리거를 사용합니다.
Cloud Build가 pull 요청을 통해 임시 Salesforce 스크래치 조직 또는 샌드박스로 코드를 배포할 때 실행할 작업 단계를 정의하려면 cloudbuild_pr.yaml이라는 다른 파일을 만듭니다.
```
cat <<EOF > cloudbuild_pr.yaml
steps:
- name: gcr.io/cloud-builders/gsutil
  args: ['cp', 'gs://\${_BUCKET_NAME}/salesforce.key', 'salesforce.key']
- name: "${SFDX_BASE_IMAGE}"
  args:
  - force:auth:jwt:grant
  - -u
  - \${_SF_USERNAME}
  - -f
  - ./salesforce.key
  - -i
  - \${_CONSUMER_KEY}
- name: "${SFDX_BASE_IMAGE}"
  args:
  - force:org:create
  - --setdefaultusername
  - --definitionfile
  - config/project-scratch-def.json
  - --targetdevhubusername
  - \${_SF_USERNAME}
  - --setalias
  - testing org
- name: "${SFDX_BASE_IMAGE}"
  args: ['force:source:push']
- name: "${SFDX_BASE_IMAGE}"
  args: ['force:apex:test:run', '--resultformat', 'tap', '--codecoverage']
- name: "${SFDX_BASE_IMAGE}"
  args: ['force:org:delete', '--noprompt']
substitutions:
  _BUCKET_NAME: __BUCKET_NAME__
  _SF_USERNAME: __USERNAME__
  _CONSUMER_KEY: __CONSUMER_KEY__
EOF
```
이 파일은 Cloud Build가 다음 작업을 수행하도록 구성합니다.
1. Cloud Build가 Dev Hub 조직에 인증하는 데 사용하는 salesforce.key 파일을 다운로드합니다.
2. Salesforce DX CLI가 설치된 Docker 컨테이너를 시작하고 JWT 권한 부여를 통해 Dev Hub 조직에 연결합니다. Cloud Build는 Cloud Build 트리거 정의에 고객 키와 Salesforce 사용자 이름 같은 구성 매개변수를 사용합니다.
3. 개발자의 자동 테스트용 코드를 배포하기 위해 새로운 스크래치 조직을 만듭니다.
4. 스크래치 조직에서 Apex 텍스트를 실행합니다.
5. GitHub pull 요청 요약에 제공되는 Apex 텍스트 결과를 출력합니다.
6. 임시 스크래치 조직을 삭제합니다.

GitHub로 저장소 푸시

Cloud Shell에서 새 cloudbuild yaml 파일과 Dockerfile을 저장소에 추가하고 이 파일을 DEV_REPO_NAME 저장소의 기본 분기로 푸시합니다. 메시지가 표시되면 GitHub에 로그인합니다.
```
git add .
git commit -m "Added cloud build configuration"
git push github main
```
개발자가 코드를 풀하거나 푸시할 수 있는 출시 분기를 만듭니다. 이 튜토리얼에서는 분기 이름을 release-sample로 지정합니다.
```
git checkout -b release-sample
```
분기를 GitHub로 푸시합니다.
```
git push github release-sample
```

GitHub 저장소를 Cloud Build에 연결

GitHub 마켓플레이스의 Cloud Build 애플리케이션 페이지로 이동합니다.
아래로 스크롤하여 Google Cloud Build로 설정을 클릭합니다. 메시지가 표시되면 GitHub에 로그인합니다.
저장소를 Cloud Build에 연결합니다.
1. 저장소만 선택을 선택합니다.
2. 저장소 선택 목록에서 저장소를 선택합니다.
설치를 클릭합니다.
Google Cloud에 로그인합니다.

승인 페이지가 표시되고 Google Cloud Build 애플리케이션이 Google Cloud에 연결하도록 승인하라는 메시지가 됩니다.
Authorize Google Cloud Build by GoogleCloudBuild(GoogleCloudBuild로 Google Cloud Build 승인)를 클릭합니다.

Google Cloud 콘솔로 리디렉션됩니다.
Google Cloud 프로젝트를 선택합니다.
동의하면 약관을 승인하고 다음을 클릭합니다.
저장소 선택 페이지에서 DEV_REPO_NAME GitHub 저장소를 선택합니다.
저장소 연결을 클릭합니다.
푸시 트리거 만들기를 클릭합니다.

Cloud Build 트리거 정의 업데이트

이전 섹션에서 푸시 트리거 만들기를 클릭할 때 생성된 새 트리거의 세부정보를 정의합니다.

Google Cloud 콘솔에서 Cloud Build 트리거 페이지를 엽니다.

Cloud Build 트리거 페이지로 이동
새 트리거의 메뉴를 클릭한 다음 수정을 클릭합니다.
이름을 pull-request-to-release-branch로 설정합니다.
설명을 Run unit tests when a pull request is created from a feature branch로 변경합니다.
이벤트를 pull 요청(GitHub 앱만 해당)으로 변경합니다.
소스에서 기본 분기 텍스트 상자에 다음 표현식을 입력합니다.
```
^release.*
```
구성에서 Cloud Build 구성 파일(yaml 또는 json)을 선택하고 텍스트 상자에 cloudbuild_pr.yaml을 입력합니다.

대체 변수 아래에서 세 개의 변수를 만듭니다. 각 변수에 대해 다음을 수행합니다.

항목 추가를 클릭합니다.

다음 표에 나열된 대로 변수 및 값 필드를 설정합니다.

변수	값
`_BUCKET_NAME`	Salesforce 키 파일의 Cloud Storage 버킷 이름이며 다음과 같은 형식입니다. `salesforce-ref-PROJECT_ID` `PROJECT_ID`를 Google Cloud 프로젝트 ID로 바꿉니다.
`_CONSUMER_KEY`	Salesforce Dev Hub 조직에서 만든 연결된 애플리케이션의 고객 키
`_SF_USERNAME`	Dev Hub 조직의 Salesforce 사용자 이름

저장을 클릭합니다.

이 페이지를 닫지 마세요. 다음 절차에서는 이 페이지의 추가 작업을 수행합니다.

두 번째 Cloud Build 트리거 만들기

다음 단계는 출시 분기에 커밋할 때 Cloud Build 작업을 시작하는 다른 트리거를 만드는 것입니다. 이 트리거는 Cloud Build 작업을 호출하여 변경사항을 Dev Hub 조직에 푸시합니다. DevOps 파이프라인에서 승인된 직원 및 프로세스만 출시 분기에 변경사항을 커밋할 수 있는지 확인해야 합니다.

Cloud Build 트리거 페이지에서 트리거 만들기를 클릭하여 새 트리거를 만듭니다.
이름을 commits-to-release-branch로 설정합니다.
트리거 유형으로 분기로 푸시를 선택합니다.
저장소 목록에서 GitHub Salesforce 저장소를 선택합니다.
분기(정규식) 텍스트 상자에 다음 표현식을 입력합니다.
```
^release.*
```
빌드 구성에서 Cloud Build 구성 파일을 선택하고 cloudbuild.yaml을 입력합니다.

대체 변수 아래에서 세 개의 변수를 만듭니다. 각 변수에 대해 다음을 수행합니다.

항목 추가를 클릭합니다.

다음 표에 나열된 대로 변수 및 값 필드를 설정합니다.

변수	값
`_BUCKET_NAME`	Salesforce 키 파일의 버킷 이름을 다음 형식으로 입력합니다. `salesforce-ref-PROJECT_ID` `PROJECT_ID`를 Google Cloud 프로젝트의 ID로 바꿉니다.
`_CONSUMER_KEY`	Salesforce Dev Hub 조직에서 만든 연결된 애플리케이션의 고객 키
`_SF_USERNAME`	Dev Hub 조직의 Salesforce 사용자 이름

저장을 클릭합니다.

Cloud Build가 Salesforce 키를 읽을 수 있도록 권한 추가

Cloud Shell에서 Cloud Build 서비스 계정에 권한을 추가하여 해당 계정이 생성된 Cloud Storage 버킷에서 Salesforce 키를 읽을 수 있도록 합니다.
```
gsutil iam ch serviceAccount:$GCP_PROJECT_NUMBER@cloudbuild.gserviceaccount.com:objectViewer \
    gs://salesforce-ref-${DEVSHELL_PROJECT_ID}
```

Salesforce 개발자를 위한 파이프라인 설정

이 섹션에서 설명하는 작업은 Salesforce 개발자용입니다.

이 튜토리얼의 앞부분에서 관리자 및 책임자 섹션에 있는 단계를 수행했다면 다른 사용자 인증 정보 집합을 사용하여 이 섹션의 단계를 실행해야 합니다.

Salesforce DX CLI 설치 단계는 사용하는 OS에 따라 다를 수 있습니다. 이 섹션의 단계에서는 Debian Linux 단계에 대해 설명합니다. macOS 및 Windows용 안내는 Salesforce 문서의 Salesforce CLI 설치를 참조하세요.

Salesforce DX CLI 설정

이 섹션에서는 Salesforce CLI를 설치하고 승인을 설정합니다.

Cloud Shell이 아닌 로컬 머신에서 홈 디렉터리로 이동합니다.
```
cd $HOME
```

xz-utils 및 wget 도구를 설치합니다.

sudo apt-get install --assume-yes xz-utils wget

Salesforce CLI를 설치합니다.

wget https://developer.salesforce.com/media/salesforce-cli/sfdx-linux-amd64.tar.xz

sfdx 디렉터리를 만듭니다.
```
mkdir sfdx
```

다운로드한 tar 파일의 압축을 풉니다.

tar xJf sfdx-linux-amd64.tar.xz -C sfdx --strip-components 1

CLI를 설치합니다.
```
./sfdx/install
```
Salesforce CLI는 /usr/local/bin/sfdx에 설치됩니다.

CLI가 올바르게 설정되었는지 확인합니다.

sfdx

출력은 다음과 비슷합니다.

VERSION
sfdx-cli/7.8.1-8f830784cc linux-x64 node-v10.15.3

USAGE
$ sfdx [COMMAND]

COMMANDS
commands  list all the commands
force     tools for the Salesforce developer
help      display help for sfdx
plugins   add/remove/create CLI plug-ins
update    update the sfdx CLI
which     show which plugin a command is in

TOPICS
Run help for each topic below to view subcommands

commands  list all the commands
force     tools for the Salesforce developer
plugins   add/remove/create CLI plug-ins

로컬 개발 환경을 Salesforce Dev Hub 조직에 연결

로컬 머신에서 개발자 역할의 사용자 인증 정보를 사용하여 Salesforce 조직에 로그인합니다.
```
sfdx force:auth:web:login --setalias YOUR_HUB_ORG
```
YOUR_HUB_ORG를 Dev Hub 조직의 적절한 별칭으로 바꿉니다.

이 명령어는 로컬 머신에서 웹 브라우저를 엽니다. 따라서 연결된 VM에서는 실행할 수 없습니다.

GitHub 저장소 클론

Salesforce 관리자가 만든 GitHub 저장소를 클론합니다.
```
git clone DEV_REPO_NAME -o github
```
클론된 저장소의 디렉터리로 이동합니다.
```
cd DEV_REPO_NAME
```

스크래치 조직에 Salesforce 코드베이스 및 메타데이터 푸시

이 섹션에서는 단위 테스트를 위해 코드베이스와 메타데이터를 스크래치 조직에 푸시합니다.

로컬 머신에서 Dev Hub 사용자 이름을 SALESFORCE_USERNAME이라는 환경 변수로 내보냅니다.
```
export SALESFORCE_USERNAME=YOUR_DEVHUB_USERNAME
```
YOUR_DEVHUB_USERNAME을 이전에 설정한 사용자 이름으로 바꿉니다.

이 튜토리얼을 위해 클론한 저장소를 테스트할 스크래치 조직을 만듭니다.

sfdx force:org:create \
    --setdefaultusername \
    --definitionfile config/project-scratch-def.json \
    --targetdevhubusername ${SALESFORCE_USERNAME} \
    --setalias feature-test-scratch-org

메타데이터와 코드를 스크래치 조직으로 푸시합니다.
```
sfdx force:source:push
```
스크래치 조직의 URL을 생성하고 브라우저 창에서 해당 URL로 이동합니다.
```
sfdx force:org:open
```

일반적으로 프로젝트 수명 주기의 다음 단계는 단위 테스트를 실행하고 개발한 기능을 검증하는 것입니다. 이 튜토리얼에서는 사전 검증된 샘플 코드로 작업하므로 이 단계를 수행하지 않습니다.

소스 코드 저장소에 코드 푸시

로컬 머신에서 이름이 feature-1인 새 분기를 만듭니다.
```
git checkout -b feature-1
```
소스 코드 저장소에 변경사항을 푸시합니다.
```
git add .
git commit -m "Feature 1 changes"
git push github feature-1
```
이 튜토리얼에서는 GitHub를 소스 코드 도구로 사용합니다.

배포 테스트

이 섹션에서는 만든 트리거가 작동하는지 확인하기 위해 실행할 수 있는 테스트에 대해 설명합니다. Salesforce 관리자가 만든 저장소에는 샘플 테스트 클래스가 포함되어 있습니다.

Cloud Shell이 아닌 로컬 머신에서 새 Git 분기를 만듭니다.
```
git checkout -b feature-1
```
텍스트 편집기를 사용하여 다음 파일을 엽니다.
```
./force-app/main/default/classes/SampleTest.cls
```
테스트가 실패하도록 System.assertEquals 문에서 101 값을 102로 변경합니다. 변경 후에는 파일을 저장하고, 이 절차의 뒷부분에서 다시 변경할 것이므로 열린 상태로 둡니다.
```
@isTest
public class SampleTest {
static testmethod void testAddOne() {
    Test.startTest();
    System.assertEquals(Sample.addOne(100), 102); // Change to 102 from 101
    Test.stopTest();
  }
}
```

기능 분기에 변경사항을 추가하고 커밋합니다.

git add .
git commit -m "Changed test case"
git push github feature-1

코드를 출시 샘플 분기에 병합하는 pull 요청을 만듭니다.

새 Cloud Build 작업이 트리거됩니다. 하지만 단위 테스트가 실패하므로 작업이 실패합니다.
빌드 상태를 보려면 Cloud Build 페이지를 엽니다.

Cloud Build 페이지로 이동

Cloud Build 페이지의 기록 섹션으로 이동합니다.

작업에 대한 다음 빌드 로그가 표시되며, 이는 테스트 어설션이 실패했음을 나타냅니다.

Step #4: not ok 1 SampleTest.testAddOne
Step #4: # System.AssertException: Assertion Failed: Expected: 101, Actual: 102
Step #4: # Class.SampleTest.testAddOne: line 24, column 1
Step #4: # Run "sfdx force:apex:test:report -i 7076300001gEzne --resultformat <format>" to retrieve test results in a different format.
[. . .]
Finished Step #4
ERROR
ERROR: build step 4 "gcr.io/serverless-devops-sf/salesforcedx-base-image:1" failed: step exited with non-zero status: 100

테스트에 통과할 수 있도록 ./force-app/main/default/classes/SampleTest.cls 파일에서 102 값을 다시 101로 변경합니다.

@isTest
public class SampleTest {
static testmethod void testAddOne() {
    Test.startTest();
    System.assertEquals(Sample.addOne(100), 101); //Change back to 101 from 102
    Test.stopTest();
  }
}

기능 분기에 변경사항을 추가하고 커밋합니다.
```
git add .
git commit -m "Changed test case to make it pass"
git push github feature-1
```
커밋 작업 후 Cloud Build 작업이 트리거됩니다.
작업이 완료되면 GitHub에서 pull 요청을 검토하고 release-sample 분기로 병합합니다.

프로덕션 워크플로에서 pull 요청을 병합하는 권한은 일반적으로 DevOps 리드 및 관리자로 제한됩니다. 이를 설정하는 방법에 관한 자세한 내용은 GitHub 사이트의 pull 요청 병합 가능성 정의를 참조하세요.
Google Cloud 콘솔에서 pull 요청을 출시 샘플 분기에 병합할 때 자동으로 트리거되는 Cloud Build 작업을 검토합니다.
작업이 완료되면 Dev Hub 조직에 로그인합니다. 개발자 또는 관리자로 로그온할 수 있습니다.

이 Salesforce 조직에서 개발자의 코드를 수정할 수 있습니다. 이를 확인하려면 설정 페이지로 이동하여 커스텀 코드/Apex 클래스를 확인하세요.

삭제

이 튜토리얼에서 사용된 리소스 비용이 Google Cloud 계정에 청구되지 않도록 하려면 리소스가 포함된 프로젝트를 삭제하거나 프로젝트를 유지하고 개별 리소스를 삭제하세요.

프로젝트 삭제

주의: 프로젝트를 삭제하면 다음과 같은 효과가 발생합니다.

프로젝트의 모든 항목이 삭제됩니다. 이 문서의 태스크에 기존 프로젝트를 사용한 경우 프로젝트를 삭제하면 프로젝트에서 수행한 다른 작업도 삭제됩니다.
커스텀 프로젝트 ID가 손실됩니다. 이 프로젝트를 만들 때 앞으로 사용할 커스텀 프로젝트 ID를 만들었을 수 있습니다. appspot.com URL과 같이 프로젝트 ID를 사용하는 URL을 보존하려면 전체 프로젝트를 삭제하는 대신 프로젝트 내에서 선택한 리소스만 삭제합니다.

여러 아키텍처, 튜토리얼, 빠른 시작을 살펴보려는 경우 프로젝트를 재사용하면 프로젝트 할당량 한도 초과를 방지할 수 있습니다.

Google Cloud 콘솔에서 리소스 관리 페이지로 이동합니다.
리소스 관리로 이동
프로젝트 목록에서 삭제할 프로젝트를 선택하고 삭제를 클릭합니다.
대화상자에서 프로젝트 ID를 입력한 후 종료를 클릭하여 프로젝트를 삭제합니다.

Salesforce 리소스 삭제

Salesforce Developer Edition 조직 및 이 튜토리얼에서 만든 관련 스크래치 조직을 삭제할 수도 있습니다.

Developer Edition 조직 비활성화

Salesforce Dev Hub 조직으로 이동합니다.
Setup(설정)의 Quick Find(빠른 찾기) 상자에 Company를 입력한 후 Company Information(회사 정보)을 선택합니다.
회사 정보를 클릭합니다.
조직 비활성화 버튼을 클릭합니다.

스크래치 조직 삭제

Cloud Shell에서 다음 명령어를 실행하여 Salesforce 스크래치 조직을 삭제합니다.
```
sfdx force:org:delete -u feature-test-scratch-org
```

GitHub 저장소 삭제

GitHub로 이동하여 이 튜토리얼에서 개인 계정으로 만든 저장소를 삭제합니다.

다음 단계

그 밖의 참조 아키텍처, 다이어그램, 튜토리얼, 권장사항을 알아보려면 클라우드 아키텍처 센터를 확인하세요.