Google Chat 앱의 배포를 만들고 관리합니다.
컬렉션을 사용해 정리하기
내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요.
이 페이지에서는 Google Chat 앱의 배포를 만들고 관리하는 방법을 설명합니다. 다양한 배포를 유지하면 Chat 앱의 수명 주기의 각 단계를 더 효과적으로 관리하고 변경사항을 프로덕션에 안전하게 출시할 수 있습니다.
앱 수명 주기의 각 단계에 배포 만들기
수명 주기 전반에 걸쳐 채팅 앱을 관리하려면 다음 각 환경에 대해 채팅 앱을 만들고 배포하는 것이 좋습니다.
- 개발: 변경사항을 작업하는 데 사용하는 환경입니다. 필요한 경우 헤드 배포를 사용하거나 이 환경을 로컬로 실행할 수 있습니다.
- 스테이징: 엔드투엔드 테스트를 위해 신뢰할 수 있는 테스터에게 배포하는 환경입니다. 이 환경은 프로덕션 환경과 최대한 유사해야 합니다.
- 프로덕션: Google Workspace Marketplace에 Chat 앱을 게시하여 최종 사용자에게 배포하는 환경입니다.
배포하는 각 Chat 앱에 대해 Google Cloud 프로젝트를 만들어야 합니다. 각 Cloud 프로젝트에서 Chat API를 구성할 때 Google Chat에서 Chat 앱을 더 잘 구분할 수 있도록 고유한 앱 이름, 아바타 URL, 설명을 사용하는 것이 좋습니다.
다음 예에서 Task app
라는 Chat 앱은 HTTP를 기반으로 하며 개발, 스테이징, 프로덕션에 배포하기 위해 서로 다른 엔드포인트를 사용합니다.
환경 |
Cloud 프로젝트 이름 |
앱 이름 |
HTTP 엔드포인트 URL |
개발 |
task-chat-app-dev |
개발자 작업 앱 |
http://example.com/api/myapp/head |
스테이징 |
task-chat-app-staging |
스테이징 작업 앱 |
http://example.com/api/myapp/staging |
프로덕션 |
task-chat-app |
작업 앱 |
http://example.com/api/myapp/ |
채팅 앱 아키텍처에 따라 배포 관리
다음 표에는 특정 Chat 앱 아키텍처의 배포를 관리할 때 추가로 고려해야 할 사항이 포함되어 있습니다.
아키텍처 |
배포 형식 |
고려사항 |
HTTP |
HTTP 엔드포인트 URL |
- Chat 앱 수명 주기의 각 엔드포인트에 변경사항을 점진적으로 배포합니다. 예를 들어 스테이징 엔드포인트
http://example.com/api/myapp/staging 에 배포된 새 기능을 테스트한 후 프로덕션 엔드포인트(예: http://example.com/api/myapp )에 배포하여 프로덕션에 기능을 출시합니다.
- 배포하기 전에 코드를 디버그하려면 엔드포인트를 로컬 환경으로 설정하면 됩니다. 변경사항을 로컬로 테스트하는 방법을 알아보려면 Google Chat 앱 디버그를 참고하세요.
|
Google Apps Script |
배포 ID |
- Apps Script 프로젝트에는 하나의 브랜치만 있을 수 있으며 하나의 Cloud 프로젝트와 연결될 수 있습니다. 변경사항을 테스트하고 여러 환경을 유지하려면 환경마다 다른 Apps Script 프로젝트를 만들어야 합니다.
- 개발 환경에는 Apps Script 프로젝트의 헤드 배포만 사용해야 합니다. 스테이징 및 프로덕션 환경의 경우 버전이 지정된 배포를 사용하세요. 자세한 내용은 Apps Script 문서의 배포 만들기 및 관리를 참고하세요.
|
Pub/Sub |
Pub/Sub 주제 |
배포마다 다른 Pub/Sub 주제를 사용해야 합니다. |
달리 명시되지 않는 한 이 페이지의 콘텐츠에는 Creative Commons Attribution 4.0 라이선스에 따라 라이선스가 부여되며, 코드 샘플에는 Apache 2.0 라이선스에 따라 라이선스가 부여됩니다. 자세한 내용은 Google Developers 사이트 정책을 참조하세요. 자바는 Oracle 및/또는 Oracle 계열사의 등록 상표입니다.
최종 업데이트: 2025-08-29(UTC)
[null,null,["최종 업데이트: 2025-08-29(UTC)"],[[["\u003cp\u003eManage your Google Chat app's lifecycle by creating separate deployments for development, staging, and production environments.\u003c/p\u003e\n"],["\u003cp\u003eCreate a distinct Google Cloud project for each deployment, using unique app names, avatar URLs, and descriptions for clarity.\u003c/p\u003e\n"],["\u003cp\u003eDeploy changes progressively through each environment, starting with development and moving to staging before releasing to production.\u003c/p\u003e\n"],["\u003cp\u003eFor Apps Script projects, maintain separate projects for each environment due to their single-branch limitation.\u003c/p\u003e\n"],["\u003cp\u003eUtilize different Pub/Sub topics for individual deployments to ensure environment isolation.\u003c/p\u003e\n"]]],["The document outlines creating and managing deployments for Google Chat apps across development, staging, and production environments. Each environment requires a separate Google Cloud project with a distinct app name and details. Deployment methods vary: HTTP uses endpoint URLs, Apps Script utilizes deployment IDs and separate projects, and Pub/Sub employs unique topics. Changes should be progressively deployed, starting from development, then staging, and finally production. Different app architectures require different consideration.\n"],null,["# Create and manage deployments for your Google Chat app\n\nThis page explains how to create and management deployments for your\nGoogle Chat app. By maintaining different deployments, you can\nbetter manage each phase of your Chat app's lifecycle\nand safely release changes to production.\n\nCreate deployments for each phase of the app lifecycle\n------------------------------------------------------\n\nTo manage your Chat app throughout its lifecycle, we\nrecommend that you create and deploy a Chat app for\neach of the following environments:\n\n- **Development:** The environment that you use to work on changes. If needed, you can use the head deployment or run this environment locally.\n- **Staging:** The environment that you deploy to trusted testers for end-to-end testing. This environment should be as close to production as possible.\n- **Production:** The environment that you deploy to end users by [publishing\n your Chat app to the\n Google Workspace Marketplace](/workspace/marketplace/how-to-publish).\n\nFor each Chat app that you deploy, you must create a\nGoogle Cloud project. When you configure the Chat API in each\nCloud project, consider using a distinct app name, avatar URL, and\ndescription so that you can better distinguish between the\nChat apps in Google Chat.\n\nIn the following example, the Chat app\ncalled `Task app` is built on HTTP and uses different endpoints to deploy to\ndevelopment, staging, and production:\n\n| Environment | Cloud project name | App name | HTTP endpoint URL |\n|-------------|-------------------------|------------------|----------------------------------------|\n| Development | `task-chat-app-dev` | Dev Task app | `http://example.com/api/myapp/head` |\n| Staging | `task-chat-app-staging` | Staging Task app | `http://example.com/api/myapp/staging` |\n| Production | `task-chat-app` | Task app | `http://example.com/api/myapp/` |\n\n### Manage deployments based on your Chat app architecture\n\nThe following table includes additional considerations when managing deployments\nfor specific [Chat app\narchitectures](/workspace/chat/structure):\n\n| Architecture | Deployment format | Considerations |\n|--------------------|-------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|\n| HTTP | HTTP endpoint URL | - Deploy changes progressively to each endpoint in your Chat app's lifecycle. For example, after you've tested a new feature deployed in your staging endpoint `http://example.com/api/myapp/staging`, release the feature to production by deploying it to your production endpoint, such as `http://example.com/api/myapp`. - To debug code before deploying, you can set an endpoint to your local environment. To learn how to test changes locally, see [Debug Google Chat apps](/chat/troubleshoot/debug). |\n| Google Apps Script | Deployment ID | - Apps Script projects can only have a single branch and be associated with one Cloud project. To test changes and maintain multiple environments, you must create different Apps Script projects for each environment. - You should only use the Apps Script project's head deployment for the development environment. For staging and production environments, use versioned deployments. For details, see [Create and manage deployments](/apps-script/concepts/deployments) in the Apps Script documentation. |\n| Pub/Sub | Pub/Sub topic | You should use a different Pub/Sub topic for each deployment. |\n\nRelated topics\n--------------\n\n- [Test interactive features for Google Chat apps](/workspace/chat/test-interactive-features)\n- [Create and manage Apps Script deployments](/apps-script/concepts/deployments)\n- [Choose a Chat app architecture](/workspace/chat/structure)"]]