GitHub Actions를 사용하여 API 게시
웹앱에 API를 추가했으며, 둘 다 로컬로 실행되고 있습니다. 이제 API 및 앱을 Azure Static Web Apps에 게시하겠습니다.
Azure Static Web Apps 인스턴스를 만들고 main 분기를 감시하도록 요청했을 때 GitHub 작업이 생성되었습니다. GitHub 작업은 리포지토리의 main 분기에 대한 커밋 및 끌어오기 요청을 수신합니다. 그런 다음, GitHub 작업이 해당 변경 내용을 검색하면 앱을 빌드하고 게시합니다.
Azure Static Web Apps 리소스를 만들 때 기본값인 Api를 수락하여 API 프로젝트의 폴더 위치를 제공했습니다. Azure Static Web Apps는 해당 폴더에 Azure Functions 앱을 빌드하고 배포했습니다. 하지만 아직 HTTP GET API가 만들어지지 않았기 때문에 앱이 작동하지 않았습니다.
GitHub 작업 트리거
GitHub 작업이 main 분기의 변경을 검색하면 웹앱 및 API를 빌드하고 게시할 준비가 된 것입니다. 직접 커밋하거나 main 분기에 대한 끌어오기 요청을 만들 수 있습니다. 이 두 가지 변경 내용 모두 GitHub Action을 트리거합니다. 기본 분기에서 변경 내용이 검색되면 GitHub Action이 트리거되어 라이브 웹 사이트와 동일한 URL에 앱을 게시합니다.
미리 보기 URL이 있는 사전 프로덕션 환경
라이브 웹 사이트에 게시하기 전에 스테이징 사이트에서 변경 내용을 확인하려는 경우가 있습니다. Azure Static Web Apps를 사용하면 각 미리 보기 URL을 포함하는 사전 프로덕션 환경을 통해 변경 내용을 볼 수 있습니다. GitHub 작업이 감시하고 있는 분기에 대해 끌어오기 요청을 만들어 사전 프로덕션 환경을 만들 수 있습니다. 라이브 웹 사이트는 영향을 받지 않습니다. 대신 새 버전의 앱이 자체의 사전 프로덕션 환경에서 만들어집니다. 돌아가서 GitHub에서 끌어오기 요청을 확인하면 사전 프로덕션 버전에 대한 링크가 대화 탭에 게시되어 있음을 알 수 있습니다.
다음 표에서는 Azure Static Web Apps가 앱을 다양한 URL에 게시하는 방법을 보여 줍니다. 앱은 한 URL에 게시되지만 동일한 분기에 대한 끌어오기 요청은 다른 URL에 게시됩니다. 이러한 자동 생성된 URL은 프로덕션 앱 및 끌어오기 요청을 위해 Azure Static Web Apps에서 제공됩니다. 필요에 따라 프로덕션 앱에 사용자 지정 도메인을 할당할 수 있습니다.
| 원본 | 설명 | URL |
|---|---|---|
| main 분기 | 실제 웹 사이트 URL의 예 | https://purple-rain-062d03304.azurestaticapps.net/ |
| 끌어오기 요청 #5 | 미리 보기 URL의 예 | https://purple-rain-062d03304-5.<location>.azurestaticapps.net/ |
현재 api 분기에서 작업하고 있습니다. api 분기에서 main 분기로 끌어오기 요청을 만듭니다. main 분기에 대해 끌어오기 요청을 만들면 GitHub 작업은 앱을 사전 프로덕션 환경에 게시합니다.
워크플로가 앱 빌드 및 배포를 완료하면 GitHub 봇이 끌어오기 요청에 설명을 추가합니다. 이 설명에는 사전 프로덕션 환경의 URL에 대한 링크가 포함되어 있습니다. 이 링크를 선택하면 단계적 변경 내용을 볼 수 있습니다.
다음으로, 끌어오기 요청을 만들고 스테이징된 버전의 앱을 방문합니다.