CI/CD 파이프라인 설정하기

이 페이지의 내용

개요

파이프라인 단계
개발
스테이징
프로덕션
빌드 작업
환경 구성
App Services CLI 설정
앱 만들기
앱 업데이트
앱에 대한 테스트 실행
작업 정리

Atlas Device Sync, Atlas Edge Server, Data API 및 HTTPS endpoints 는 더 이상 사용되지 않습니다. 자세한 내용은 지원 중단 페이지를 참조하세요.

개요

많은 개발자가 지속적 통합, 배포 및 배포서버 파이프라인을 사용합니다. 변경할 때마다 애플리케이션을 자동으로 테스트하고 게시합니다. 이는 git과 같은 공유 버전 관리 시스템을 사용하여 여러 사람이 동시에 코드베이스를 작업하는 대규모 앱에 가장 일반적이며 유용합니다.

이 가이드에서는 대부분의 CI/CD 파이프라인에 공통적으로 적용되는 높은 수준의 단계를 다루며, 각 단계에서 수행할 수 있는 작업에 대해 설명합니다. 또한 Atlas App Services 앱을 구성하고 테스트하기 위해 파이프라인 내에서 수행할 수 있는 일반적인 작업 및 조치 목록이 포함되어 있습니다.

팁

GitHub 작업을 사용한 실제 예시 보기

실제 애플리케이션의 테스트, 배포 및 기타 작업을 관리하는 CI/CD 파이프라인의 예시를 보려면 MongoDB 개발자 허브에서 GitHub 작업을 사용하여 App Services 앱을 위한 CI/CD 파이프라인을 구축하는 방법 문서를 참조하세요.

파이프라인 단계

높은 수준에서 대부분의 파이프라인은 각각 다른 문제를 처리하는 단계를 여러 번 거치는 공통 패턴을 공유합니다.

개발

개발 단계는 앱에서 새로운 기능을 만들고 버그를 수정하기 위한 첫 번째 단계입니다. 개발 단계에서는 애플리케이션의 구성 파일과 소스 코드를 사용하여 원하는 변경 사항을 구현합니다.

기존 앱의 새로운 기능을 개발하려면 다음을 수행합니다:

메인 앱을 분할하고 새 개발 사본을 배포합니다. 이 인스턴스에는 프로덕션 앱과 다른 앱 ID가 부여됩니다. 환경 값 템플릿을 사용하여 프로덕션에 연결되지 않은 개발 데이터 소스 및 기타 서비스를 사용할 수도 있습니다.
애플리케이션을 개발합니다. 여기에는 클라이언트 앱 화면 업데이트 또는 추가, 새 데이터베이스 트리거 추가 또는 기타 애플리케이션 기능 추가가 포함될 수 있습니다. 동기화된 Realm 객체 스키마를 변경해야 하는 경우 개발 모드를 사용할 수 있습니다.

로컬에서 자동화된 테스트를 실행하여 코드가 새로운 오류를 일으키지 않는지 확인합니다. 로컬에서 테스트를 통과했다고 해서 앱에 통합 버그가 없다고 보장할 수는 없지만, 변경 사항에 회귀나 의도하지 않은 동작이 포함되지 않은 것을 확실하게 확인할 수 있습니다.

스테이징

QA(품질 보증), 테스트 또는 사전 프로덕션이라고도 하는 스테이징 단계는 가능한 한 프로덕션과 유사한 환경에서 개발 변경 사항을 시뮬레이션하는 단계입니다. 이를 통해 앱의 사용 가능한 버전을 검토할 수 있으며, 프로덕션 데이터에 영향을 주지 않으면서 라이브 서비스와의 통합 버그를 발견할 수 있습니다.

스테이징 배포의 세부 사항은 애플리케이션의 요구 사항에 따라 달라집니다. 그러나 다음과 같은 높은 수준의 절차를 사용하여 설정할 수 있습니다.

스테이징 환경을 설정합니다. 프로덕션 환경과 최대한 비슷한 구성으로 별도의 비프로덕션 서비스 및 데이터 소스를 사용하세요. 예를 들어, production 클러스터와 동일한 구성을 가진 staging Atlas 클러스터를 사용할 수 있습니다. 사용 사례에 따라 모든 스테이징 빌드에 재사용하는 일관된 앱이 있거나 각 스테이징 빌드에 대해 새 앱을 만들 수 있습니다.
스테이징 빌드를 만들거나 기존 스테이징 빌드를 사용합니다. 새 pull 요청을 생성할 때와 같이 CI/CD 프로세스의 일부로 스테이징 빌드를 자동으로 생성할 수 있습니다. 각 스테이징 빌드에 대해 새 앱을 사용하거나 빌드 간에 공유 하는 사전 빌드된 환경을 재사용할 수 있습니다.
앱이 예상대로 작동하는지 확인합니다. 여기에는 스테이징 환경에 대해 자동화된 테스트 모음을 실행하거나, 동작을 수동으로 확인하거나, 사용자 승인 테스트를 통해 승인을 받는 등이 포함될 수 있습니다.

프로덕션

프로덕션 단계는 수정한 앱을 프로덕션 환경에 배포하는 최종 배포 단계입니다. 프로덕션 단계에서는 로컬 및 스테이징 단계에서 변경 사항을 이미 테스트하여 배포해도 안전한지 확인이 이미 완료된 것이 이상적입니다. 프로덕션 앱을 업데이트하여 수동으로 프로덕션에 배포하거나 CI/CD 워크플로의 일부로 자동으로 배포할 수 있습니다.

빌드 작업

이 섹션에서는 CI/CD 파이프라인에서 수행할 일반적인 작업에 대해 간략하게 설명합니다. 사용 사례와 파이프라인 단계에 따라 이러한 작업을 모두 수행하지 않을 수도 있지만, 일반적으로 대부분의 파이프라인은 이 모든 작업을 적어도 한 번은 수행합니다.

환경 구성

앱의 구성과 코드는 일반적으로 개발 단계 간에 유사해야 합니다. 그러나 환경에 따라 특정 구성 옵션의 값을 변경해야 할 수도 있습니다.

빌드할 단계를 결정하고 적절한 구성 값을 설정합니다. 예를 들어 개발 단계에서 새 앱의 앱 ID로 앱을 구성하거나 프로덕션 단계에서 프로덕션 앱 ID를 사용할 수 있습니다.

# Use the production App ID for the main branch
export REALM_APP_ID="myapp-abcde"
# Use a staging App ID for the QA branch
export REALM_APP_ID="myapp-staging-fghij"
# Use a new App ID for development branches - you'll need to create the app first!
export REALM_APP_ID="myapp-dev-zyxwv"

팁

앱 ID 찾기

앱ID를 항상 하드코딩할 수 있는 것은 아닙니다. App Services CLI로 특정 앱 ID를 조회할 수 있습니다. 예시는 앱 만들기를 참조하세요.

App Services CLI 설정

App Services CLI는 프로그래밍 방식으로 Atlas 앱을 생성, 구성 및 관리하는 가장 쉬운 방법입니다. 배포 스크립트에서 최신 버전을 설치하고 사용해야 합니다.

App Services CLI는 npm 에서 사용할 수 있습니다. 시스템에 를 설치하려면 Node.js 가 설치되어 있어야 합니다. 설치한 다음 CLI 에서 다음 명령을 shell 실행합니다.

npm install -g atlas-app-services-cli

또한 CLI를 인증하고 사용하려면 MongoDB Atlas 공개/비공개 API 키 쌍이 필요합니다. API 키를 얻는 방법에 대한 자세한 내용과 단계별 안내는 프로그래밍 방식 API 키를 참조하세요.

로그인하려면 새로 명명된 프로필 구성에 API 키를 저장한 다음 해당 프로필로 로그인하세요.

~/.config/appservices/<Profile Name>.yaml

<Profile Name>:
  public_api_key: "<MongoDB Atlas Public API Key>"
  private_api_key: "<MongoDB Atlas Private API Key>"
  atlas_base_url: "https://cloud.mongodb.com"
  realm_base_url: "https://services.cloud.mongodb.com"
  telemetry_mode: ""

appservices login --profile="<Profile Name>"

팁

모든 명령에 --profile 플래그를 사용해야 합니다. 그렇지 않으면 App Services CLI가 사용자가 로그인한 것을 인식하지 못합니다.

앱 만들기

App Services CLI를 사용하여 개발 및 테스트에 사용할 새 앱을 만들 수 있습니다. 파이프라인이 개발 또는 스테이징 단계에 있는 경우 라이브 프로덕션 앱이 아닌 앱을 사용하여 변경 사항을 배포하고 테스트해야 합니다.

개발 또는 스테이징 버전에 새 앱을 사용하려면 다음을 따릅니다:

새 앱 만들기
앱 구성 파일의 버전을 기반으로 새 앱을 푸시합니다.
```
cd path/to/realmApp
appservices push -y --project="<MongoDB Atlas Project ID>" # e.g. --project="609ea544934fe445460219a2"
```

앱 ID 저장

새 앱에는 나중에 파이프라인과 클라이언트 앱에서 식별해야 하는 고유한 앱 ID 값이 있습니다. 환경 변수, 파일 또는 기타 위치에 해당 값을 저장해야 합니다.

# Save to an environment variable
output=$(appservices app describe)
app_id=$(echo $output | sed 's/^.*client_app_id": "\([^"]*\).*/\1/')
export REALM_APP_ID=app_id
# Save to a file
echo $REALM_APP_ID > ./clients/ios/realm-app-id.txt

앱 업데이트

App Services CLI를 사용하여 공유 스테이징 앱 또는 프로덕션 배포와 같은 기존 앱을 업데이트할 수 있습니다. 앱이 이미 존재하므로 앱 ID를 조회할 수 있습니다.

기존 앱을 업데이트하려면 --remote 플래그에 앱 ID를 지정합니다.

appservices push --remote=$REALM_APP_ID -y

앱에 대한 테스트 실행

앱에는 모든 것이 제대로 작동하는지 확인하기 위해 실행할 수 있는 자동화된 단위 및 통합 테스트 도구 모음이 포함되어야 합니다. 테스트 설정의 세부 사항은 앱에 따라 다르지만 다양한 시뮬레이터를 사용하여 여러 플랫폼에서 테스트를 실행해야 할 수 있습니다.

통합 테스트가 있는 경우 이전 릴리스를 체크아웃하고 앱의 현재 버전에 대해 통합 테스트를 실행하여 이전 버전과의 호환성을 확인할 수 있습니다.

작업 정리

CI/CD 단계 또는 파이프라인이 완료되면 해당 테스트를 위해 특별히 생성한 리소스를 정리할 수 있습니다. 예를 들어 새 개발 또는 스테이징 앱을 생성하는 경우 변경 사항이 병합된 후 앱 및 이와 연결된 모든 데이터베이스를 삭제할 수 있습니다. 또는 프로덕션 앱이나 영구 스테이징 앱을 사용하는 경우 이를 삭제하지 않는 것이 좋습니다.

삭제하기 전에 나중에 어떤 리소스가 유용할 수 있는지 생각해 봅니다. 예를 들어 테스트가 실패할 경우 앱과 해당 데이터베이스 삭제를 건너뛰도록 선택할 수 있습니다. 이렇게 하면 문제를 수동으로 조사하고 오류를 일으킨 앱 설정이나 데이터를 찾을 수 있습니다.

돌아가기

앱 환경 구성

배포 모델 변경