Vercel에 태깅하여 릴리스

문제는 어디에 있습니까?

프로덕션 릴리스 직전에 프로덕션 구성에 가까운 모든 수락 테스트를 실행하는 스테이징 빌드를 갖도록 프로젝트를 구성하는 것을 좋아합니다.

이를 달성하기 위해 내 스테이징 빌드는 프로젝트HEAD 분기의 현재main를 나타냅니다. 실행 후 승인 테스트 분기에 태그가 지정되고 프로덕션으로 릴리스됩니다.

vercel.com의 프로젝트에 대한 기본 구성은 커밋할 때마다 기본 브랜치를 프로덕션으로 릴리스합니다. staging 분기 및 도메인 구성을 추가하여 스테이징 빌드를 위한 두 번째 분기를 쉽게 구성할 수 있습니다.



이 구성에서 main 분기의 헤드는 https://vercel-release-by-tag.vercel.app/으로 릴리스되고 staging 분기의 변경 사항은 https://staging-vercel-release-by-tag.vercel.app/로 릴리스됩니다.

프로덕션으로 릴리스하려면 staging 분기를 main 에 병합해야 합니다.

이는 허용되는 워크플로우이지만 다른 프로덕션 릴리스 간의 변경 사항을 추적하기 위해 GitHub 릴리스 페이지를 사용하고 있지 않습니다. 또한 개발자는 최적이 아닌 두 개의 분기를 관리해야 합니다.

첫 시도

태그가 있는 릴리스의 문제를 해결하기 위한 첫 번째 접근 방식은 can you deploy based on tags releases on vercel 가이드를 사용하는 것이었습니다. 제안된 솔루션은 사용하지 않는 분기를 생성하고deploy hook 이 태그를 해제하는 것인데, 저에게는 효과가 없었습니다. 배포 후크는 분기에 연결됩니다.



그리고 그 링크 때문에 특정 브랜치에 있는 코드만 릴리스할 수 있습니다. staging 분기를 릴리스하도록 웹후크를 구성하면 해당 분기가 스테이징 환경으로 릴리스되지만 해당 동작을 변경할 방법을 찾지 못했습니다.

두 번째 시도

이를 해결하기 위한 두 번째 시도는 how can I use GitHub Actions with Vercel? 가이드를 사용하여 릴리스를 GitHub 작업으로 이동하는 것이 었습니다.

결과적으로 나는 내용이 있는 파일.github/workflows/deploy-prod.yml을 만들었습니다.

name: Deploy to production
env:
  VERCEL_ORG_ID: ${{ secrets.VERCEL_ORG_ID }}
  VERCEL_PROJECT_ID: ${{ secrets.VERCEL_PROJECT_ID }}
on:
  push:
    tags:
      - 'v*'

jobs:
  Deploy-Production:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v3

      - name: Install Node.js
        uses: actions/setup-node@v3
        with:
          node-version: 16

      - name: install and release
        run: | 
          npm install --global vercel@latest
          vercel pull --yes --environment=production --token=${{ secrets.VERCEL_TOKEN }}
          vercel build --prod --token=${{ secrets.VERCEL_TOKEN }}
          vercel deploy --prebuilt --prod --token=${{ secrets.VERCEL_TOKEN }}

이 접근 방식은 허용되지 않았습니다.

빌드는 GitHub에서 한 번 수행되었습니다. 작업 작업자 및 빌드 아티팩트를 Vercel에 업로드해야 하며 이 프로세스는 그곳에서 직접 빌드하는 것보다 느립니다.

빌드 환경이 런타임과 다르기 때문에 추가 구성 없이 Prisma 클라이언트가 올바르게 생성되지 않았습니다.
이 접근 방식의 장점은 인공 분기를 만들 필요가 없다는 것입니다.

최종 접근

최종 솔루션의 경우 브랜치에서 직접 빌드하도록 Vercel을 구성하기로 결정했지만 태그를 적용한 후 프로덕션 브랜치의 모든 변경 사항이 자동으로 수행되도록 워크플로우를 추가했습니다.

이를 달성하기 위해 git repo에 production 분기를 생성하고 main 및 production 보호 규칙에 대해 생성했습니다.
.
보호 기능은 production 분기를 다른 분기에 병합한 후 실수로 삭제되지 않도록 합니다.

그런 다음 production 분기(설정 -> git)에서 프로덕션 코드를 릴리스하도록 Vercel을 구성했습니다.



그리고 main 분기를 staging 도메인으로 해제하려면(설정->도메인):



그리고 마지막 부분은 태그 생성 시 분기를 업데이트production하는 것입니다. 가장 쉬운 방법은 GitHub Action을 만드는 것입니다.

name: Deploy to production
on:
  push:
    tags:
      - 'v*'

jobs:
  Deploy-Production:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v3

      - name: Release to production
        run: |
          git push origin HEAD:production -f

git push origin HEAD:production -f 명령은 현재 태그가 지정된 커밋이 있는 현재production 분기 업데이트를 강제 실행합니다(작업이 v 로 시작하는 태그에서만 실행되기 때문입니다.

생성된 프로세스:

마무리 생각

이 솔루션은 팀이 main 분기에서 작업하고 production가 태그 지정 후 작업에 의해서만 업데이트될 때 워크플로를 가정합니다. 분기 보호 규칙에 풀 요청 요구 사항을 추가하고 이 분기에 대한 production 권한이 있는 봇 계정을 만들고 GitHub 작업에서 해당 계정의 토큰을 사용하여 실수로 bypass branch protections 분기를 업데이트하는 기능을 잠글 수 있습니다. 자식 액세스 권한을 부여하십시오.

우발적인 프로덕션 릴리스에 대한 두 번째 방어 방법은 ignored build step을 구성하는 것입니다.

다음과 유사한 스크립트:

#!/bin/bash

echo "VERCEL_GIT_COMMIT_REF: $VERCEL_GIT_COMMIT_REF"

if [[ "$VERCEL_GIT_COMMIT_REF" == "main" ]]; then
  echo "✅ - Staging build can proceed"
  exit 1;
elif [[ "$VERCEL_GIT_COMMIT_REF" == "production" && $(git name-rev --name-only --tags HEAD) != "undefined"  ]]; then
  echo "✅ - Production build can proceed"
  exit 1;
else
  # Don't build
  echo "🛑 - Build cancelled"
  exit 0;
fi