Cloud 프로젝트 계획

이 페이지는 프로덕션 백엔드용 Cloud 프로젝트에 추가로 만들어야 하는 Cloud 프로젝트 이름 지정 규칙에 대한 권장사항을 제공합니다.

환경의 목적 또는 API 수명 주기 단계에 따라 다음과 같이 할 수 있습니다.

  • API 이름 또는 Cloud Endpoints 서비스 이름을 변경합니다. 자세한 내용은 Endpoints 구성을 참조하세요.
  • 다른 프로젝트를 만듭니다.
  • API가 제공되는 경로를 변경합니다.

일반적으로 사용할 수 있는 방식은 다음과 같습니다.

  • API 버전 관리: 향후에 이전 버전과 호환되지 않는 변경을 수행해야 할 것으로 예상되는 경우, 미리 계획하여 API가 제공되는 경로에 버전 번호를 추가합니다. 예:

    • my-api.endpoints.my‐project.cloud.goog/v1/echo

  • 개발/테스트 인스턴스: 각 개발자가 자신의 프로젝트에서 각자의 서비스 버전을 만듭니다. 예를 들어, 댄이라는 개발자는 다음을 사용합니다.

    • my-api.endpoints.dan-dev-project.cloud.goog/v1/echo

  • 스테이징: 프로덕션에 배포하기 전에 API 자체 프로젝트에 있는 스테이징 백엔드에서 API를 테스트합니다. 예:

    • my-api.endpoints.my‐project-staging.cloud.goog/v1/echo

  • 비공개 알파 실행: 서비스의 신규 버전을 모든 고객이 아닌 일부 고객에게 테스트하고 싶은 경우, 가장 쉬운 방법은 프로덕션에서 격리 수준이 가장 높은 자체 프로젝트에 알파 버전을 배치하는 것입니다. 예:

    • my-api.endpoints.my‐project-alpha.cloud.goog/v2alpha/echo

    또는 동일한 프로젝트에 알파 버전을 배치하되 이를 별도의 서비스로 구성할 수 있습니다. 별도의 서비스이므로, 액세스를 알파 고객으로만 제한할 수 있습니다. 예:

    • my-api-alpha.endpoints.my-project.cloud.goog/v2alpha/echo

  • 공개 알파 실행: 모든 고객이 사용할 수 있는 알파 버전을 출시하려는 경우, 기존 버전과 동일한 서비스와 프로젝트에 알파 버전을 배치하고 경로를 변경할 수 있습니다. 예를 들면 다음과 같습니다.

    • my-api.endpoints.my-project.cloud.goog/v2alpha/echo
참조: