建立及管理 Google Chat 應用程式部署作業
    
    
      
    
    
      
      透過集合功能整理內容
    
    
      
      你可以依據偏好儲存及分類內容。
    
  
  
      
    
  
  
  
  
  
    
  
  
    
    
    
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
   
本頁說明如何為 Google Chat 應用程式建立及管理部署作業。維護不同的部署作業,有助於您妥善管理 Chat 應用程式生命週期的各個階段,並安全地將變更發布至正式環境。
為應用程式生命週期的每個階段建立部署作業
為在整個生命週期中管理 Chat 應用程式,建議您為下列每個環境建立及部署 Chat 應用程式:
您必須為部署的每個 Chat 應用程式建立 Google Cloud 專案。在每個 Cloud 專案中設定 Chat API 時,建議使用不同的應用程式名稱、虛擬人偶網址和說明,以便在 Google Chat 中區別 Chat 應用程式。
在下列範例中,名為 Task app 的即時通訊應用程式是以 HTTP 建構而成,並使用不同的端點部署至開發、測試和實際工作環境:
| 環境 | Cloud 專案名稱 | 應用程式名稱 | HTTP 端點網址 | 
| 開發 | 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 應用程式架構管理部署作業
下表列出管理特定 Chat 應用程式架構部署作業時,需要額外考量的因素:
| 架構 | 部署格式 | 注意事項 | 
| HTTP | HTTP 端點網址 | 
在 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 主題。 | 
  
  
  
    
  
 
  
    
    
      
       
    
    
  
  
  除非另有註明,否則本頁面中的內容是採用創用 CC 姓名標示 4.0 授權,程式碼範例則為阿帕契 2.0 授權。詳情請參閱《Google Developers 網站政策》。Java 是 Oracle 和/或其關聯企業的註冊商標。
  上次更新時間:2025-10-15 (世界標準時間)。
  
  
  
    
      [null,null,["上次更新時間:2025-10-15 (世界標準時間)。"],[],["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"]]