풀 요청 번호를 서버리스 배포 단계로 사용

서버리스 프레임워크를 사용하면 하나의 서비스를 여러 단계(예: dev, qual 및 prod)에 배포할 수 있습니다. 스테이지는 provider 속성에서 설정할 수 있습니다.

# serverless.yml
service: myservice

provider:
  name: aws
  stage: dev
  region: us-east-1

단계는 CloudFormation 스택 이름에 추가되고 서비스의 모든 Lambda 함수 및 대부분의 다른 리소스에 추가됩니다. 배포 중에 명령줄 플래그--stage 또는 -s를 사용하여 재정의할 수도 있습니다.

serverless deploy --stage prod --region eu-central-1

> Deploying myservice to stage prod (eu-central-1)

> ✔ Service deployed to stack myservice-prod (130s)

> functions:
>  hello: myservice-prod-hello (14 kB)

이제 커밋 또는 끌어오기 요청을 기반으로 변경 사항을 지속적으로 배포하는 GitHub 워크플로와 같은 CI/CD 환경이 있을 수 있습니다. 이러한 변경 사항은 개발 또는 프로덕션 상태와 별도로 테스트해야 합니다. 한 가지 방법은 별도의 단계(예: qual 또는 분기/커밋/풀 요청의 이름)에 배포한 다음 테스트 스크립트를 실행하는 것입니다.

각 배포 스크립트에 추가--stage하는 대신 환경 변수를 사용하여 단계를 동적으로 설정하는 것을 좋아합니다. GitHub 워크플로를 시작할 때 워크플로 실행을 트리거한 풀 요청을 기반으로 환경 변수를 설정했습니다.

# .github/workflows/ci.yml
name: GitHub CI/Testing

on:
  pull_request

env:
  PR_NUMBER: ${{ github.event.number }} # e.g. 65
  BRANCH: ${{ github.head_ref }}        # e.g bugfix/issue-42
  STAGE: pr${{ github.event.number }}   # => pr65

...

서버리스 프레임워크가 환경에서 올바른 단계를 가져오려면 가변 해상도로 단계를 덮어써야 합니다.

# serverless.yml

provider:
  stage: ${opt:stage, env:STAGE, "dev"} 

이 변수는 배포 중에 단계가 해결되는 순서를 정의합니다. 먼저 --stage 플래그를 확인합니다. 사용할 수 없는 경우 환경 변수STAGE를 확인합니다. 사용할 수 없는 경우 기본값dev이 사용됩니다.

이 예에서 서버리스 프레임워크는 서비스를 myservice-pr65로, Lambda 함수를 myservice-pr65-hello로 제공합니다. 예를 들어 다른 리소스 및 내보내기의 이름을 지정하기 위해 serverless.yml 파일 내의 단계에 액세스해야 하는 경우 위에서 ${sls:stage} 변수에 대해 해결되는 내장 변수provider.stage를 사용할 수 있습니다.

연결

Serverless Variables

GitHub Actions Environment Variables

GitHub Actions Context