백엔드 API 및 프런트엔드 배포를 위한 스테이징 및 프로덕션과 같은 여러 환경을 갖춘 프로젝트에서 작업할 때 저장소의 각 브랜치에 대해 올바른 구성과 명령이 있는지 확인하고 싶을 것입니다.
여러 개발자가 코드베이스에서 적극적으로 작업하거나, 다른 브랜치를 변경하거나, 여러 브랜치별 구성을 관리하는 상황에서는 이는 어려울 수 있습니다.
모든 끌어오기 요청이나 브랜치에 푸시된 변경 사항과 마찬가지로, 병합할지 여부를 결정하기 전에 변경, 추가 또는 제거된 모든 코드 줄을 검토해야 합니다. 코드베이스의 구성 파일은 이로부터 면제되지 않으며 간단한 변경만으로도 전체 지속적 통합 설정에 영향을 미칠 수 있으므로 오류가 발생하기 쉽습니다.
스테이징 또는 프로덕션 브랜치가 변경되고 빌드가 트리거되면 브랜치에 연결된 올바른 리소스가 유지되는지 확인해야 합니다. 경우에 따라 각 클라이언트에 대해 서로 다른 리디렉션 규칙, 사용자 정의 빌드 명령 또는 각 분기에 대한 기타 설정을 정의해야 할 수도 있습니다.
이 기사에서는 간단한 bash 스크립트를 사용하여 여러 브랜치에 대한 자동 리디렉션을 포함하여 브랜치별 구성을 관리하는 방법을 살펴보겠습니다. 또한 Netlify에서 스테이징 및 프로덕션 브랜치에 대한 상황별 규칙을 안전하게 병합하는 방법도 보여드리겠습니다.
우리가 다룰 내용:
-
프로젝트 구조 및 시나리오
-
리디렉션/다시 쓰기란 무엇입니까?
-
Netlify가 리디렉션하는 방법
-
_redirects 파일 구문 사용
-
netlify.toml 구성 파일 구문 사용
-
-
문제:서로 다른 지점에 대해 여러 netlify.toml 파일 관리
-
구성 파일을 자동으로 생성하는 스크립트를 작성하는 방법
-
샘플 Netlify.toml 파일
-
1단계:스크립트 폴더 생성 및 스크립트 파일 추가
-
2단계:스크립트 명령을 포함하도록 package.json 수정
-
-
Netlify에 클라이언트를 배포하는 방법
-
Netlify에 프로젝트를 처음 배포
-
후속 배포/지점 배포 설정 방법
-
1단계:각 브랜치 컨텍스트(프로덕션, 스테이징 등)에 대해 Netlify에서 환경 변수 설정
-
2단계:새로운 배포 실행
-
-
-
배치 검사
-
결론
프로젝트 구조 및 시나리오
프로젝트에 두 개의 별도 서버가 배포된 상황을 생각해 보세요. 하나는 스테이징 환경(렌더링에 배포)에 요청을 처리하고 다른 하나는 프로덕션 환경(Google Cloud Run에 배포)에 제공합니다.
또한 Netlify에는 두 개의 개별 클라이언트 배포가 있으며 각각에는 아래 그림과 같이 해당 서버에서 제공되는 해당 API_BASE_URL이 있습니다.
아래 이미지는 sample-project입니다. 저장소( api 포함) 그리고 client 그 안에 있는 폴더/디렉토리. 이는 위에서 설명한 각 분기의 구조에 대한 개요입니다. 각 디렉토리에는 고유한 package.json이 포함되어 있습니다. 파일은 독립적인 구성 요소로 취급되며 두 개의 별도 서비스에 배포될 수 있습니다.
각 클라이언트에 대한 프런트엔드 배포에서 /api/v1/으로 시작하는 엔드포인트에 대한 모든 요청 서버로 라우팅됩니다. 다른 경로는 클라이언트 내의 페이지로 안내하기 위해 프런트엔드 내에 남아 있습니다. 따라서 클라이언트에게 이러한 요청을 처리하는 방법을 안내하는 올바른 규칙을 작성해야 합니다. 이를 리디렉션 규칙 또는 다시 쓰기라고 합니다.
리디렉션/다시 쓰기란 무엇인가요?
리디렉션 또는 다시 쓰기는 특정 URL이 자동으로 인터넷상의 새 위치로 이동하도록 만들 수 있는 규칙입니다(출처:WPengine). 이는 일반적으로 URL 전달이라고도 알려져 있습니다. 전체 웹사이트, 웹사이트의 섹션, 전체 웹 애플리케이션 등 어디에서나 사용할 수 있습니다.
웹 애플리케이션에서는 요청 처리 방법을 결정하기 위해 리디렉션이 자주 활용됩니다. Netlify 및 Vercel과 같은 웹 호스팅 플랫폼도 이를 사용하여 개발자에게 웹 애플리케이션이 요청을 처리하는 방법을 결정할 수 있는 옵션을 제공합니다.
Netlify가 리디렉션을 처리하는 방법
Netlify에는 리디렉션 규칙을 지정하는 두 가지 방법이 있습니다. _redirects를 사용하여 이를 수행할 수 있습니다. 파일 구문 또는 netlify.toml 사용 구성 파일 구문. 동일한 목표를 달성하지만 netlify.toml 구문은 더 많은 옵션과 기능을 제공합니다.
_redirects 사용 파일 구문
리디렉션 구문을 사용하려는 경우 _redirects를 생성하면 됩니다. 클라이언트 앱의 공용 폴더에 파일을 넣고 그 안에 리디렉션 규칙을 지정하세요. 그것은 가능한 한 쉽습니다. 다음은 파일 내 리디렉션 규칙의 예입니다.

위의 규칙은 다음과 같이 해석될 수 있습니다:
-
/api/v1와 일치하는 모든 요청을 보냅니다. 지정된 API URL로 이동하고 200 성공 상태 코드를 반환합니다./api/v1/뒤의 별표(*)/api/v1/*에서 볼 수 있듯이 원래 URL의 다른 확장자를 명시된 API URL에 추가하도록 지시합니다. 예를 들어/api/v1/users가 있는 경우 프런트엔드에서 경로를 지정하면 해당 요청이https://your-api-base-url.com/api/v1/users로 리디렉션됩니다. .:splatAPI URL에 표시되는 것은 단순히 자리 표시자입니다. -
index.html 폴더를 통해 다른 모든 기본 경로를 제공합니다. 이는 다른 페이지로 이동하고 '뒤로' 버튼을 사용하여 이전 페이지를 방문하려고 할 때 깨진 페이지가 발생하지 않도록 하기 위해 필요합니다.
netlify.toml 사용 구성 파일 구문
netlify.toml 구성 파일을 사용하면 원래 요청 경로 일치, 필요한 대상, 선호하는 상태 코드 응답, 헤더 규칙, 서명, 국가 제한, 역할 등을 포함하되 이에 국한되지 않는 리디렉션 규칙을 지정할 때 훨씬 더 많은 유연성을 얻을 수 있습니다.
샘플 netlify.toml입니다 Netlify 문서에서 가져온 파일:

빠른 참고사항: 특정 요청을 API로 리디렉션하기 위해 리디렉션 파일을 사용하는 것은 완벽합니다. 그러나 리디렉션에 일반 텍스트로 API URL을 추가하는 것은 보안 위험으로 간주될 수 있습니다. API_BASE_URL이 비공개로 간주되는 경우 파일입니다. 이는 공개 폴더에 있는 모든 파일이 말 그대로 공개이며 누구나 액세스할 수 있기 때문입니다.
앱에 포함하고 싶은 직접 위치가 공개 URL인 경우 _redirects를 자유롭게 활용하세요. 파일 구문. 하지만 비공개 URL을 갖고 싶다면 netlify.toml를 활용하세요. 일반적으로 환경 변수와 함께 구성 파일을 사용하는 것이 더 좋습니다.
문제:여러 netlify.toml 관리 다른 지점을 위한 파일
netlify.toml을 사용하는 경우 파일을 사용하여 빌드 명령 및 환경별 설정을 정의하고 저장소에 푸시된 변경 사항을 적용하고 끌어오기 요청을 열려면 각 netlify.toml을 수동으로 무시하거나 편집해야 합니다. 각 지점에서. 이는 결국 매우 스트레스를 주고 오류가 발생하기 쉽습니다.
이 외에도 우리는 API URL이 _redirects에 하드코딩되는 것을 피하고 싶습니다. 또는 netlify.toml 보안상의 이유로 프로젝트 코드베이스 내에 파일을 저장하세요. 프로덕션 및 스테이징 컨텍스트를 위해 Netlify UI 내에 제공된 환경 변수를 사용합니다.
위의 문제를 방지하기 위해 코드베이스의 작은 스크립트를 사용하여 올바른 netlify.toml를 동적으로 생성합니다. 각 지점에 대한 파일입니다. 이 접근 방식은 충돌을 없애고 분기 간 전환이나 끌어오기 요청 처리 시 수동 개입의 필요성을 제거합니다.
구성 파일을 자동으로 생성하는 스크립트를 작성하는 방법
샘플 Netlify.toml 파일
다음은 netlify.toml 샘플의 스크린샷입니다. 우리가 각 빌드에 대해 달성하려고 하는 파일입니다. api/v1/과 일치하는 모든 요청을 볼 수 있습니다. 코드베이스의 내용은 API로 라우팅됩니다.
API 엔드포인트 요청을 다르게 구성할 수 있습니다(예:/api/your-endpoint). – 그에 따라 스크립트를 조정하십시오. 이 샘플 프로젝트에서는 api/v1/your-endpoint을 사용합니다. 우리의 구조입니다.
1단계:스크립트 폴더 생성 및 스크립트 파일 추가
client에서 디렉토리, scripts/ 생성 디렉토리 및 configure-netlify.sh 스크립트 파일. 저장소의 각 분기에 대해 이 작업을 수행해야 합니다. 내용은 동일합니다.
configure-netlify.sh 열기 스크립트 파일에 다음 내용을 붙여넣으세요.
#!/bin/bash
# Ensure API_BASE_URL is set
if [ -z "$API_BASE_URL" ]; then
echo "Error: API_BASE_URL environment variable is not set."
exit 1 # Exit the script to stop the deployment
fi
echo "Using API endpoint: $API_BASE_URL"
# Define the desired Netlify configuration
NETLIFY_CONFIG="
[build]
command = \"npm install && npm run build\"
base = \"client\"
publish = \"dist\"
[[redirects]]
from = \"/api/v1/*\"
to = \"$API_BASE_URL/:splat\"
status = 200
force = true
[[redirects]]
from = \"/*\"
to = \"/index.html\"
status = 200
"
# Create or update the netlify.toml file
if [ ! -f "netlify.toml" ]; then
echo "Creating netlify.toml file..."
else
echo "Updating existing netlify.toml file..."
fi
echo "$NETLIFY_CONFIG" > netlify.toml
# Confirm successful configuration
echo "netlify.toml file has been configured successfully!"
스크립트는 다음을 수행합니다:
-
API_BASE_URL이 있는지 확인하기 위해 환경 변수를 확인합니다. 설정됩니다. 이것이 설정되지 않으면 빌드가 종료되고 실패하게 됩니다. 이는 실수로 성공적인 배포를 생성하지 않지만 프로덕션에서 잘못된 URL을 사용하는 것을 방지하기 위한 것입니다. -
그런 다음
netlify.toml의 콘텐츠를 생성합니다. 위의 샘플에 표시된 대로 파일을 다운로드하세요. API 엔드포인트가api/v1/your-endpoint과 다른 구조를 사용하는 경우 , 원하는 구조에 맞게 스크립트를 조정할 수 있습니다. -
netlify.toml가 이미 존재하는지 확인합니다. 파일. 존재하지 않는 경우 하나를 만들고 내용을 씁니다. 존재하는 경우API_BASE_URL를 사용하여 빌드 중에 올바른 콘텐츠로 업데이트합니다. 환경변수에 설정하세요.
2단계:package.json 수정 스크립트 명령을 포함하려면
이 스크립트를 빌드 프로세스와 통합하기 위해 package.json에 스크립트 명령을 추가합니다. 실제 빌드를 실행하기 전에 이 스크립트를 호출하기 위한 파일입니다.
configure-netlify 추가 명령은 다음과 같습니다:"configure-netlify": "bash scripts/ configure-netlify.sh" package.json의 스크립트 내에서 파일입니다.
실제 빌드를 실행하기 전에 스크립트를 실행하도록 빌드 명령을 업데이트하세요. "build": "npm run configure-netlify && vite build" .
이러한 변경 사항을 저장하고 원격 저장소에 푸시하는 것을 잊지 마세요.
Netlify에 클라이언트를 배포하는 방법
클라이언트를 Netlify에 배포할 때 세 가지 옵션이 제공됩니다:
-
기존 프로젝트(즉, GitHub 및 GitLab과 같은 Git 저장소 서비스에 존재하는 프로젝트) 가져오기,
-
템플릿에서 가져오기 또는
-
Netlify 드롭(드래그 앤 드롭) 인터페이스를 사용하여 정적 사이트를 수동으로 배포합니다.
빌드 프로세스 중에 저장소의 구성이 예상대로 작동하려면 GitHub와 같은 기존 프로젝트에서 가져와야 하는 옵션을 사용해야 합니다. 드래그 앤 드롭 인터페이스를 사용하면 작동하지 않습니다. 꼭 사용해야 한다면 _redirects를 선택하세요. 리디렉션을 정의하는 파일 구문 옵션입니다.
Netlify에 프로젝트를 처음 배포
프로젝트를 처음 배포할 때 처음에는 하나의 브랜치만 배포하는 옵션이 제공됩니다. 후속 배포에서는 다른 브랜치 등 다른 옵션만 추가하고 지정할 수 있습니다.
프로젝트를 배포하려면 다음 단계를 따르세요:
-
Netlify> netlify.com
에 로그인하세요. -
"새 사이트 추가"> "기존 프로젝트 가져오기"> "GitHub으로 배포"를 클릭하세요.
-
"GitHub에서 Netlify 구성"을 클릭하고> 저장소 검색> 선택
을 클릭하세요. -
프로젝트의 고유한 사이트 이름을 입력하세요
-
배포 설정을 구성합니다. 여기에서는 배포할 기본 분기를 선택해야 합니다. 초기 배포를 위해
main를 배포합니다. 우리가 프로덕션 브랜치로 사용하는 브랜치입니다.-
분기:메인/마스터
-
빌드 명령:
npm run build -
게시 디렉터리:
dist(정적 파일이 있는 디렉터리를 선택하세요. 이 샘플 프로젝트에서는dist로 내보내집니다. 디렉토리. 일부 도구는build로 내보냅니다. )
-
-
프로젝트의 환경 변수를 입력합니다.
API_BASE_URL을 입력하는 것을 잊지 마세요. 귀하의 서버에서. 이는 bash 스크립트에 따른 필수 요구 사항입니다. -
"사이트 배포"를 클릭하세요

프로젝트가 올바르게 배포되어야 하며 netlify.toml을 볼 수 있습니다. 성공적인 배포 페이지 하단에 있는 배포 세부 정보를 검사하여 스크립트에 의해 생성된 구성입니다.
이 파일을 로컬 컴퓨터에 다운로드하여 생성된 구성을 확인할 수 있습니다. 샘플 netlify.toml와 일치해야 합니다. 위의 파일. 생성된 사이트 링크를 사용하여 작동하는지 테스트할 수도 있습니다.

후속 배포/지점 배포 설정 방법
1단계:Netlify에서 각 분기 컨텍스트 — 프로덕션, 스테이징 등에 대한 환경 변수 설정
프로젝트가 성공적으로 배포되면 스테이징 분기에 대한 배포를 설정할 수 있습니다. 구성을 편집하려면 다음을 수행해야 합니다.
-
사이트 목록으로 이동
-
성공적으로 배포된 사이트를 선택하세요
-
왼쪽 메뉴에서 "사이트 구성"을 클릭하세요
-
'환경 변수'를 선택하고> '변수 추가' 버튼을 클릭하세요.

변수를 개별적으로 추가하거나 전체 .env를 가져올 수 있는 옵션이 제공됩니다. 파일. 두 옵션 중 하나를 선택할 수 있습니다. 아래 이미지에서는 '.env에서 가져오기'를 선택했습니다. 파일”.

우리 프로덕션 사이트가 main에서 배포된 것을 확인했습니다. 브랜치(프로덕션 환경 변수 포함)가 이미 배포되었으므로 다음을 수행해야 합니다.
-
프로덕션 브랜치를 선택 취소합니다(처음에 배포된 기본 브랜치를 교체하지 않으려면. 다른 브랜치에 대한 환경 변수를 혼동하지 않도록 주의하세요)
-
"브랜치 배포"를 선택하세요
-
입력 섹션에 .env 파일의 내용을 복사하여 붙여넣으세요.
-
API_BASE_URL을 추가하는 것을 잊지 마세요. 스테이징 환경을 위한 환경 변수
브랜치 배포를 선택할 때 여기에서 가져온 환경 변수는 프로덕션 브랜치를 제외한 모든 브랜치 배포에 영향을 미칩니다. 사용자 정의 분기를 선택하여 컨텍스트를 추가로 사용자 정의할 수 있지만 이는 netlify.toml를 추가로 사용자 정의해야 할 수 있는 완전히 다른 접근 방식입니다. 구성 파일 또는 bash 스크립트.

각 환경 변수를 개별적으로 가져오기로 결정한 경우 아래와 유사한 옵션이 제공됩니다. 각 분기에 대해 올바른 컨텍스트를 선택했는지 확인하세요.
모든 컨텍스트에 동일한 값을 사용하지 마십시오. 아래 이미지에서 볼 수 있듯이 "배포 컨텍스트마다 다른 값을 선택합니다. ”를 사용하면 각 항목에 대한 값을 정의할 수 있습니다. 이 경우 분기 배포에 대한 값을 정의합니다. 처음에 사용된 생산 변수는 이미 존재해야 합니다.
모든 변수를 가져온 후에는 각 변수 옆의 오른쪽에 있는 드롭다운을 선택하고 해당 값을 검사하여 올바르게 가져왔는지 확인할 수 있습니다.

2단계:새 배포 트리거
다양한 컨텍스트(이 경우 프로덕션 및 스테이징)에 대해 모든 환경 변수를 가져왔으면 화면 왼쪽 패널의 "배포"로 이동합니다. 그런 다음 '배포 트리거' 버튼을 누르고 캐시를 지우고 새 배포를 시작하세요.

배포 검사
배포 중 하나를 선택하고 "배포 로그"에서 건물 드롭다운을 선택하여 스크립트가 예상대로 작동하는지 확인할 수 있습니다. 컨텍스트에 정의된 대로 명령 실행과 해당 배포에 대한 출력 및 API URL이 표시됩니다.

결론
이 가이드의 단계를 따르고 리포지토리의 각 분기에서 스크립트와 업데이트된 명령을 사용하여 변경 사항을 푸시하면 Netlify가 자동으로 netlify.toml를 생성하거나 업데이트합니다. 각 지점에 파일을 보관하세요. 이렇게 하면 빌드 시 각 환경에 대한 올바른 구성과 환경 변수가 사용됩니다.
스크립트는 모든 지점에서 동일하게 유지됩니다. 이를 통해 스크립트가 안전하고 쉽게 올바른 구성을 처리하는 동안 다른 코드 변경에 집중할 수 있습니다.
변경 사항을 모든 브랜치에 푸시하여 실제로 작동하는 모습을 확인하세요.
Twitter(@francisihej) 또는 LinkedIn을 통해 언제든지 저에게 연락해주세요!
무료로 코딩을 배우세요. freeCodeCamp의 오픈 소스 커리큘럼은 40,000명 이상의 사람들이 개발자로 취업하는 데 도움을 주었습니다. 시작하세요