สร้างและจัดการการทำให้ใช้งานได้สำหรับแอป Google Chat
หน้านี้อธิบายวิธีสร้างและจัดการการติดตั้งใช้งานสําหรับแอป Google Chat การดูแลรักษาการติดตั้งใช้งานที่แตกต่างกันจะช่วยให้คุณจัดการแต่ละระยะของวงจรของแอป Chat ได้ดียิ่งขึ้นและเผยแพร่การเปลี่ยนแปลงไปยังเวอร์ชันที่ใช้งานจริงได้อย่างปลอดภัย
สร้างการติดตั้งใช้งานสำหรับแต่ละระยะของวงจรของแอป
หากต้องการจัดการแอป Chat ตลอดวงจร เราขอแนะนำให้คุณสร้างและทำให้แอป Chat ใช้งานได้ในสภาพแวดล้อมต่อไปนี้
- การพัฒนา: สภาพแวดล้อมที่คุณใช้ทําการเปลี่ยนแปลง คุณสามารถใช้การทำให้ใช้งานได้แบบ Head หรือเรียกใช้สภาพแวดล้อมนี้ในเครื่องได้หากจำเป็น
- การทดสอบ: สภาพแวดล้อมที่คุณทำให้ผู้ทดสอบที่เชื่อถือได้ใช้งานเพื่อทดสอบจากต้นทางถึงปลายทาง สภาพแวดล้อมนี้ควรใกล้เคียงกับเวอร์ชันที่ใช้งานจริงมากที่สุด
- เวอร์ชันที่ใช้งานจริง: สภาพแวดล้อมที่คุณติดตั้งใช้งานให้กับผู้ใช้ปลายทางโดยเผยแพร่แอป Chat ไปยัง Google Workspace Marketplace
คุณต้องสร้างโปรเจ็กต์ Google Cloud สำหรับแอป Chat แต่ละแอปที่ติดตั้งใช้งาน เมื่อคุณกำหนดค่า Chat API ในโปรเจ็กต์แต่ละโปรเจ็กต์ในไดรฟ์ ให้พิจารณาใช้ชื่อแอป, URL รูปโปรไฟล์ และคำอธิบายที่แตกต่างกันเพื่อให้คุณแยกความแตกต่างระหว่างแอป Chat ใน Google Chat ได้ดีขึ้น
ในตัวอย่างต่อไปนี้ แอปแชทชื่อ Task app
สร้างขึ้นบน HTTP และใช้ปลายทางที่แตกต่างกันเพื่อนำไปใช้งานในเวอร์ชันสำหรับนักพัฒนาซอฟต์แวร์ เวอร์ชันสแต็ก และเวอร์ชันที่ใช้งานจริง
สภาพแวดล้อม |
ชื่อโปรเจ็กต์ที่อยู่ในระบบคลาวด์ |
ชื่อแอป |
URL ปลายทาง HTTP |
การพัฒนา |
task-chat-app-dev |
แอปงานสำหรับนักพัฒนาซอฟต์แวร์ |
http://example.com/api/myapp/head |
กำลังจัดการ |
task-chat-app-staging |
แอป Staging Task |
http://example.com/api/myapp/staging |
เวอร์ชันที่ใช้งานจริง |
task-chat-app |
แอปงาน |
http://example.com/api/myapp/ |
จัดการการติดตั้งใช้งานตามสถาปัตยกรรมแอป Chat
ตารางต่อไปนี้แสดงข้อควรพิจารณาเพิ่มเติมเมื่อจัดการการติดตั้งใช้งานสถาปัตยกรรมแอปแชทที่เฉพาะเจาะจง
สถาปัตยกรรม |
รูปแบบการทำให้ใช้งานได้ |
ข้อควรพิจารณา |
HTTP |
URL ปลายทาง HTTP |
- ค่อยๆ ติดตั้งใช้งานการเปลี่ยนแปลงในแต่ละอุปกรณ์ปลายทางในวงจรของแอป Chat ตัวอย่างเช่น หลังจากที่ทดสอบฟีเจอร์ใหม่ที่ติดตั้งใช้งานในปลายทางที่ใช้ทดสอบแล้ว
http://example.com/api/myapp/staging ให้เผยแพร่ฟีเจอร์นั้นในเวอร์ชันที่ใช้งานจริงโดยติดตั้งใช้งานในปลายทางเวอร์ชันที่ใช้งานจริง เช่น
http://example.com/api/myapp
- หากต้องการแก้ไขข้อบกพร่องของโค้ดก่อนทำให้ใช้งานได้ คุณสามารถตั้งค่าปลายทางเป็นสภาพแวดล้อมในเครื่องได้ ดูวิธีทดสอบการเปลี่ยนแปลงในเครื่องได้ที่หัวข้อแก้ไขข้อบกพร่องของแอป Google Chat
|
Google Apps Script |
รหัสการทำให้ใช้งานได้ |
- โปรเจ็กต์ Apps Script ต้องมีสาขาเดียวและเชื่อมโยงกับโปรเจ็กต์ Cloud ได้เพียงโปรเจ็กต์เดียวเท่านั้น หากต้องการทดสอบการเปลี่ยนแปลงและดูแลรักษาสภาพแวดล้อมหลายแห่ง คุณต้องสร้างโปรเจ็กต์ Apps Script แยกกันสำหรับแต่ละสภาพแวดล้อม
- คุณควรใช้การทำให้ใช้งานได้ของเวอร์ชันหลักของโปรเจ็กต์ Apps Script สำหรับสภาพแวดล้อมการพัฒนาเท่านั้น สําหรับสภาพแวดล้อมการทดสอบและที่ใช้งานจริง ให้ใช้การทําให้ใช้งานได้ที่มีเวอร์ชัน โปรดดูรายละเอียดที่หัวข้อสร้างและจัดการการติดตั้งใช้งานในเอกสารประกอบของ Apps Script
|
Pub/Sub |
หัวข้อ Pub/Sub |
คุณควรใช้หัวข้อ Pub/Sub ที่แตกต่างกันสําหรับการติดตั้งใช้งานแต่ละครั้ง |
เนื้อหาของหน้าเว็บนี้ได้รับอนุญาตภายใต้ใบอนุญาตที่ต้องระบุที่มาของครีเอทีฟคอมมอนส์ 4.0 และตัวอย่างโค้ดได้รับอนุญาตภายใต้ใบอนุญาต Apache 2.0 เว้นแต่จะระบุไว้เป็นอย่างอื่น โปรดดูรายละเอียดที่นโยบายเว็บไซต์ Google Developers Java เป็นเครื่องหมายการค้าจดทะเบียนของ Oracle และ/หรือบริษัทในเครือ
อัปเดตล่าสุด 2024-12-21 UTC
[null,null,["อัปเดตล่าสุด 2024-12-21 UTC"],[[["Manage your Google Chat app's lifecycle by creating separate deployments for development, staging, and production environments."],["Create a distinct Google Cloud project for each deployment, using unique app names, avatar URLs, and descriptions for clarity."],["Deploy changes progressively through each environment, starting with development and moving to staging before releasing to production."],["For Apps Script projects, maintain separate projects for each environment due to their single-branch limitation."],["Utilize different Pub/Sub topics for individual deployments to ensure environment isolation."]]],["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"]]