คู่มือ ZDT Deployment for PHP สำหรับ PHP

ผู้ใช้บริการเว็บสมัยใหม่ส่วนใหญ่ควรสามารถเข้าถึงได้ตลอดเวลาปัญหาที่พบบ่อยแต่มักถูกมองข้ามที่นี่คือกระบวนการ Deploy โปรเจ็กต์ใหม่ (เช่นการอัปเดต) ส่งผลให้ Application ของคุณล่มหรือส่งคืนข้อผิดพลาดจนกว่าการดำเนินการจะเสร็จสิ้นซึ่งสามารถแก้ไขได้ด้วยเครื่องมือที่หลากหลายเช่น Capistrano, Fabric และอื่นๆอย่างไรก็ตามส่วนเสริมเหล่านี้มักต้องใช้เวลาค่าใช้จ่ายและความรู้เฉพาะทางเพิ่มเติมเพื่อให้สามารถบูรณาการและกำหนดค่าได้อย่างถูกต้อง (เช่นอาจดำเนินการผ่านการตั้งค่า Server หลายเครื่องโดยมี Load Balancer อยู่ข้างหน้าในขณะที่การ Deploy งานกำลังทำงานบน Server เดียว - จะถูกแยกออกจากรายการเส้นทางหลังจากนั้น Server อื่นๆก็สามารถอัปเดตได้) แน่นอนว่าการดำเนินการดังกล่าวค่อนข้างซับซ้อนและต้องใช้ Resource เพิ่มเติมจำนวนมากดังนั้นจึงจำเป็นต้องมีวิธีการที่ดีกว่า

เช่นกโซลูชั่นใหม่ได้รับการเสนอสำหรับ Application PHP ซึ่งทำงานบน Apache โดยผู้ก่อตั้งภาษาการเขียนโปรแกรมนี้และที่ปรึกษาด้านเทคนิคของเรา Rasmus Lerdorf ในเวลาเดียวกันเนื่องจากมีการใช้อย่างแข็งขันที่ Etsy และดังนั้นจึงเป็นแนวทางที่ได้รับการทดสอบแล้วจึงถูกนำมาใช้เป็นพื้นฐานสำหรับฟีเจอร์ Zero Downtime & Atomic Deployment ใน Platform แนวคิดหลักของวิธีนี้ขึ้นอยู่กับสองประเด็นต่อไปนี้:

• แต่ละครั้งที่มีการดำเนินการกระบวนการ Deploy ใหม่ไฟล์ของแอปที่เกี่ยวข้องจะถูกทำซ้ำโดยจัดเก็บไว้ใน Directory Server แยกต่างหาก (ซึ่งตั้งชื่อโดยอัตโนมัติตามวันที่/เวลาที่สร้างเพื่อให้ระบุได้ง่าย)
• ตัวเปลี่ยนเส้นทางคำขอพิเศษที่เรียกว่าซิมลิงค์(เช่นลิงก์สัญลักษณ์) สลับระหว่างแอปเวอร์ชันต่างๆหลังจากอัปเดตแต่ละครั้งโดยชี้ไปที่เวอร์ชันที่ควรใช้ในปัจจุบัน

ด้วยวิธีนี้ไฟล์โปรเจ็กต์ที่อัปเดตจึงสามารถ Deploy ได้อย่างราบรื่นในขณะที่เวอร์ชัน Code เริ่มต้นยังคงทำงานและจัดการ Session ของผู้ใช้ต่อไปและเมื่อการ Deploy เสร็จสมบูรณ์ Symlink จะสลับไปยังเวอร์ชันล่าสุดของแอปที่ Deploy สำเร็จทันทีโดยเริ่มเปลี่ยนเส้นทางคำขอที่เข้ามาทั้งหมดไปยังแอปนั้นทั้งหมดนี้ทำให้กระบวนการ Deploy สำหรับลูกค้าของคุณเป็นแบบอะตอมมิกและโดยปริยายอย่างสมบูรณ์ขณะเดียวกันก็ช่วยให้คุณไม่ต้องดำเนินการด้วยตนเองมากมายตามที่จินตนาการไว้

บันทึก:ความพร้อมใช้งานของฟังก์ชันนี้ขึ้นอยู่กับการตั้งค่าของผู้ให้บริการ Host ของคุณ

ด้านล่างนี้เราจะสำรวจกลไกนี้โดยละเอียดยิ่งขึ้นโดยอธิบายว่า:

• Workflow การ Deploy ZDT
• วิธีรับประกันการทำงานของ ZDT ที่ Platform
• การเปรียบเทียบโหมดการใช้งานแบบอะตอมมิกและแบบคลาสสิก

เอาล่ะไปกันต่อ!

Workflow การ Deploy ZDT

ก่อนอื่นเราจะพิจารณาให้เจาะจงมากขึ้นว่ากลไกการ Deploy PHP แบบ Zero-Downtime ที่อธิบายไว้ข้างต้นทำงานอย่างไรบน Platform จริงๆอย่างไรเรามาตรวจสอบกระบวนการทั้งหมดเหล่านี้ทีละขั้นตอนด้วยตัวอย่างจริงกัน

1. ในการเริ่มต้นคุณจะต้องมี Environment PHP (เช่น aใหม่หรืออันที่มีอยู่แล้ว) - เราจะใช้ Apache เป็นตัวอย่างนี้:

2. ต่อไปให้ดำเนินการต่อไปที่การใช้งานของ Application ที่ต้องการในระหว่างขั้นตอนนี้คุณต้องทำเครื่องหมายในช่องที่เกี่ยวข้องในกรอบการยืนยันที่เหมาะสม (ขึ้นอยู่กับประเภทแหล่งที่มาของโครงการที่ใช้) เพื่อเปิดใช้งานตัวเลือกการ Deploy ZDT:

• สำหรับการ Deploy ผ่านไฟล์ในเครื่องหรือ URL โดยตรง

บันทึก:ขณะดำเนินการนี้เป็นครั้งแรกสำหรับ Application ที่มีอยู่แล้ว Deploy กับรากตามบริบทโดยปกติแล้วข้อมูลก่อนหน้านี้ทั้งหมดจะถูกลบและเขียนทับด้วยการติดตั้งแอป "เปล่า" (สำหรับการ Deploy ผ่านไฟล์เก็บถาวร/URL เท่านั้น)

• สำหรับการ Deploy ผ่าน VCS (เช่นจาก GIT/SVN หรือ Bitbucket repo):

บันทึก:

• เปิดใช้งานการ Deploy แบบไม่ต้องหยุดทำงานแฟล็กจะใช้งานได้เฉพาะเมื่อมีการ Deploy กับรากบริบทของ Application Server PHP ของคุณมิฉะนั้นจะใช้วิธีการแบบคลาสสิก
• ในขณะที่ทำงานกับ VCS repos โหมดการ Deploy ที่เลือกจะถูกจดจำและใช้สำหรับทั้งหมดเพิ่มเติมอัปเดตอัตโนมัติของ Application นี้จนกว่าคุณจะเปลี่ยนด้วยตนเอง
• โดยทั่วไปเราขอแนะนำไม่ให้ใช้เส้นทางสัมบูรณ์แบบ "ฮาร์ด Code" ใน Code และการกำหนดค่าของแอปของคุณในขณะที่ใช้คุณลักษณะการ Deploy แบบอะตอมมิกเพื่อให้แน่ใจว่าจะยังคงทำงานได้โดยไม่คำนึงถึงชื่อ Directory ของโครงการ

3. ในระหว่างการใช้งานครั้งแรก, กROOT_ประทับเวลา(เช่น.,ROOT_year.mm.dd-hh.mm.ss) โฟลเดอร์และรายการพิเศษรากไฟล์เป็น symlink ไปยังโฟลเดอร์นี้ถูกสร้างขึ้นภายในเว็บรูทDirectory ของ Application Server ของคุณ

ตามปกติ Application พร้อมที่จะจัดการคำขอหลังจากกระบวนการ Deploy เสร็จสิ้น

ถ้าจะนำทางภายใน.รากDirectory ที่วงกลมไว้ด้านบนเนื้อหาของเวอร์ชัน Application ที่ใช้อยู่ในปัจจุบันจะถูกดูกล่าวคือมีการเปลี่ยนแปลงทุกครั้งที่เปลี่ยน Symlink

สิ่งนี้สามารถเห็นได้ชัดเจนหากเข้าสู่ Container ของ Application Server ของคุณผ่านทาง SSHและดำเนินการคำสั่งรายการไฟล์รูปแบบยาวสำหรับคุณเว็บรูทโฟลเดอร์เช่น:

ทุบตี

ls -l /var/www/webroot

ด้วยวิธีนี้คุณสามารถค้นหา symlink ได้อย่างง่ายดายเนื่องจากมีการทำเครื่องหมายด้วยสีไว้ในรายการและเพื่อดูเส้นทางการเปลี่ยนเส้นทางจริง

4. ในระหว่างการ Deploy ครั้งที่สอง(เช่นเมื่อ Deploy การอัปเดต) ใหม่ROOT_ประทับเวลาโฟลเดอร์ถูกสร้างขึ้น - ด้วยวิธีนี้เวอร์ชัน Application จริงและลูกค้าที่กำลังใช้งานอยู่จะไม่ได้รับผลกระทบ

หลังจากที่ไฟล์ใหม่ถูกคลายแพ็ก symlink จะสลับไปที่โฟลเดอร์ใหม่นี้โดยเปลี่ยนเส้นทางคำขอที่เพิ่งได้รับทั้งหมดไปยังโฟลเดอร์นั้นในที่นี้โฟลเดอร์แรกจะถูกเก็บไว้เพื่อประมวลผล Session ของผู้ใช้ “เก่า” (เช่นที่ที่การจัดการเริ่มต้นก่อนที่จะสลับ symlink)

บันทึก:ขณะอัปเดตเวอร์ชันแอปโดยใช้ไฟล์เก็บถาวร/URL เนื้อหาที่ผู้ใช้สร้างขึ้นทั้งหมด (ถ้ามี) ควรย้ายด้วยตนเองไปยัง Directory แอปที่สร้างขึ้นใหม่จากเวอร์ชันเก่าที่เก็บไว้ข้างๆ (ด้วยเหตุนี้การดำเนินการดังกล่าวก่อนหน้านี้จึงแสดงถึงการแทนที่ข้อมูลบริบททั้งหมดโดยสมบูรณ์) หากใช้ VCS เนื้อหา Directory ของแอปจะถูกคัดลอกทั้งหมด (ทั้งไฟล์ที่ติดตามและไม่ได้ติดตาม) ดังนั้นจึงไม่จำเป็นต้องดำเนินการด้วยตนเองอย่างไรก็ตามเราแนะนำให้นำแนวปฏิบัติของ.gitignoreแสดงรายการการใช้งานสำหรับไฟล์ที่ไม่จำเป็นของโปรเจ็กต์ของคุณเนื่องจากจะช่วยประหยัด Resource และเวลาบางส่วนในระหว่างการ Deploy ซ้ำซ้ำๆ

5. การ Deploy อะตอมมิกต่อไปนี้ทั้งหมดจะดำเนินการในลักษณะเดียวกันในระหว่างแต่ละโฟลเดอร์โฟลเดอร์โปรเจ็กต์ที่เก่าที่สุดจะถูกลบออกในขณะที่โฟลเดอร์ใหม่ROOT_ประทับเวลามีการเพิ่ม Directory สำหรับเวอร์ชันโปรเจ็กต์ล่าสุด

ด้วยวิธีนี้ Application ที่ Deploy เพียง 2 เวอร์ชัน (เวอร์ชันล่าสุดและเวอร์ชันก่อนหน้า) จะถูกจัดเก็บไว้ใน Server แอปพร้อมกัน (อย่างไรก็ตามเวอร์ชันเก่าสามารถลบออกด้วยตนเองได้อย่างง่ายดายเมื่อไม่ต้องการอีกต่อไป) ซึ่งจะทำให้ไม่มีการใช้เนื้อที่ดิสก์เพิ่มเติม

บันทึก:หากคุณต้องการหลีกเลี่ยงการลบเวอร์ชันโปรเจ็กต์บางเวอร์ชันโดยอัตโนมัติเพียงเปลี่ยนชื่อโฟลเดอร์ที่เกี่ยวข้องก่อนที่จะเรียกใช้การ Deploy ใหม่

การดำเนินการทั้งหมดเป็นแบบอัตโนมัติโดยสมบูรณ์ดังนั้นจึงไม่จำเป็นต้องมีส่วนร่วมของนักพัฒนาเพิ่มเติมในขณะที่การ Deploy นั้นดำเนินการในโหมด "ซอฟต์" กล่าวคือแม้ว่าจะไม่จำเป็นต้อง RestartServer แอปก็ตามและส่งผลให้ไม่มีการหยุดทำงานของ Application ใดๆอีกด้วย

การใช้งาน ZDT ที่ Server PHP

เมื่อเจาะลึกรายละเอียดของการใช้งานทางเทคนิคการสนับสนุนตัวเลือกการ Deploy แบบอะตอมมิกที่ Platform ได้รับการรับรองโดยการปรับเปลี่ยนต่อไปนี้ซึ่งนำไปใช้กับ Instance PHP ที่เกี่ยวข้อง:

• Apache PHP

ฟังก์ชันการทำงานที่เหมาะสมได้รับการจัดการด้วยความช่วยเหลือของmod_realdocโมดูลซึ่งควบคุมการสลับ symlink ดังกล่าวข้างต้นสามารถกำหนดค่าเพิ่มเติมได้ (หากจำเป็น) ผ่านทาง DashboardPlatform ภายในยืนยัน >mod_realdoc.confไฟล์.

เคล็ดลับ:นี่.Realpath ทุกParameter กำหนดระยะเวลาที่เก็บเส้นทางลิงก์สัญลักษณ์และความถี่ของการ Refresh เป็นค่าเริ่มต้น (0ตามที่ระบุไว้ในความคิดเห็นของ Code) ถูกเปลี่ยนเป็น2เพื่อให้มั่นใจว่าการดำเนินการที่จำเป็นทั้งหมด (เช่นการใช้งานและการสลับ) จะต้องเสร็จสิ้นก่อนที่จะเปลี่ยนเส้นทางคำขอไปยังเวอร์ชันโปรเจ็กต์ใหม่และด้วยเหตุนี้จึงป้องกันการชะลอตัวของ I/O

ค่านี้สามารถเปลี่ยนเป็นค่าที่คุณกำหนดเองได้อย่างง่ายดายหากจำเป็น (อย่าลืม Restart Node Server แอปสำหรับอุปกรณ์ของมัน) อย่างไรก็ตามหากใช้คุณสมบัติการ Deploy ZDT เราไม่แนะนำตั้งค่าไว้สูงเกินไปเนื่องจากจะทำให้เกิดความล่าช้าในการสลับซิมลิงก์

สำหรับข้อมูลเพิ่มเติมเกี่ยวกับข้อมูลเฉพาะของโมดูลนี้โปรดไปที่แหล่งที่มาหน้าหนังสือ.

• NGINX-PHP

ที่นี่รับประกันการ Deploy อะตอมมิกด้วยฟังก์ชันการทำงานในตัวโดยไม่มีการรวมโมดูลเพิ่มเติม - การตั้งค่าที่เกี่ยวข้องสามารถพบได้ที่ส่วนท้ายสุดของคอนเฟิร์ม >nginx.confไฟล์:

ในตอนนี้เมื่อคุณทราบแล้วว่าทั้งหมดนี้ทำงานอย่างไรเราสามารถเปรียบเทียบวิธีการ Deploy ทั้งแบบคลาสสิกและแบบอะตอมมิกได้.

การเปรียบเทียบและสรุป

เพื่อพิสูจน์ประโยชน์ของแนวทางการอัปเดต ZDT จึงมีการทดสอบโหลดอย่างง่ายโดยมี Parameter ต่อไปนี้เป็นพื้นฐาน:

• Application- มีการ Deploy WordPress CMS เวอร์ชันพื้นฐาน (เช่นการเผยแพร่เริ่มต้นโดยไม่มีเนื้อหาหนัก)
• เครื่องมือสร้างโหลด-Apache JMeterซึ่งได้รับการกำหนดค่าให้ส่งคำขอพร้อมกันตามจำนวนที่ต้องการไปยัง Application ของเราอย่างต่อเนื่องในระหว่างกระบวนการ Deploy ใหม่
• กรอบเวลา- การทดสอบเริ่มต้นในช่วงเวลาสั้นๆก่อนที่กระบวนการ Deploy ซ้ำจะดำเนินการและเสร็จสิ้นไม่กี่วินาทีหลังจากเสร็จสิ้น

ดังนั้นมาประเมินผลลัพธ์ของวิธีการ Deploy ทั้งสองวิธีด้วยสถิติง่ายๆที่เราได้รับกัน

การ Deploy เอกสารถาวร

เริ่มจากรูปแบบการใช้งานโครงการที่ใช้บ่อยที่สุดได้แก่ -คลาสสิคกล่าวคือการติดตั้งจาก Package ที่เก็บถาวรเดี่ยวโดยไม่มีตัวเลือกพิเศษเช่นเปิดใช้งาน ZDT:

อย่างที่คุณเห็นจริงๆแล้วเราได้รับผลลัพธ์ที่ค่อนข้างดี:

• รวดเร็วและมั่นคงเวลาตอบสนอง(กราฟสีน้ำเงิน) เท่านั้น1.2วินาทีโดยเฉลี่ย
• การฟื้นฟูอย่างรวดเร็วสู่การทำงานปกติ (เช่นเมื่อคำขอที่เข้ามาทั้งหมดเป็นประมวลผลสำเร็จแล้ว(สายสีเขียว) ไม่มีข้อผิดพลาด(กราฟสีแดง) เกิดขึ้น) หลังจากการ Deploy Package ใหม่
• ไม่ปรากฏเป็นเวลาสองวินาทีเท่านั้น - ดูเส้นสีแดงที่ขัดขวาง (อย่างไรก็ตามการ Deploy โปรเจ็กต์ที่หนักกว่าและเต็มไปด้วยเนื้อหาจะเพิ่มช่วงเวลานี้อย่างแน่นอน)

ตอนนี้เรามาทำการทดสอบเดียวกันกับผู้เข้าแข่งขันคนที่สองกัน -ซีดีที. เพื่อการรับรู้การเปรียบเทียบที่ดีขึ้นเราจะคงคำอธิบายสีไว้เหมือนเดิม:

เวลาตอบสนองยังคงมีเสถียรภาพและแทบไม่เปลี่ยนแปลงแต่คุณสามารถสังเกตเห็นการขยายตัวเล็กน้อยในระหว่างขั้นตอนการอัปเดตซึ่งเกิดจากกระบวนการ Deploy เพิ่มเติมที่ทำงานควบคู่ไปกับการให้บริการคำขอบัดนี้ไม่มีแม้แต่สักองค์เดียวข้อผิดพลาดในระหว่างการทดสอบทั้งหมด

ดังนั้นด้วยวิธีนี้เราสามารถสรุปได้ว่าการ Deploy การหยุดทำงานเป็นศูนย์จะเอาชนะปัญหาคำขอที่ล้มเหลวในระหว่างการ Deploy Application ใหม่โดยรักษาเวลาตอบสนองโดยเฉลี่ยให้อยู่ในระดับเดียวกันไปพร้อมๆกันนอกจากนี้ตัวเลือกอะตอมมิกยังช่วยให้คุณสามารถบันทึกเนื้อหาที่ผู้ใช้สร้างขึ้นทั้งหมดซึ่งอยู่ภายใน Directory Application และย้ายไปยังเวอร์ชันของแอปใหม่ได้อย่างง่ายดายหากจำเป็น (ในขณะที่วิธีการแบบคลาสสิกโดยปกติจะหมายถึงการ Deploy เวอร์ชันแอปใหม่ทั้งหมดเท่านั้น)

คุณอาจสังเกตเห็นด้วยว่าเวลาในการดำเนินการของคำขอขั้นต่ำสำหรับวิธีแบบคลาสสิกนั้นต่ำกว่าแบบอะตอมมิกอย่างมากและดูเหมือนว่าจะให้ประสิทธิภาพที่ดีขึ้นแต่อย่าเข้าใจผิดเนื่องจากเป็นเพียงผลข้างเคียงของการมีอยู่ของคำขอที่ล้มเหลว (โดยจะนับเวลาให้บริการด้วยแม้ว่าจะไม่ได้ประมวลผลก็ตาม) ในขณะที่เวลาตอบสนองโดยเฉลี่ยเกือบจะเท่ากันสำหรับทั้งสองวิธี

การ Deploy VCS

ต่อไปเราจะทำการทดสอบซ้ำสำหรับประเภทการ Deploy Platform ที่สอง (เช่นหากใช้ repos Git/SVN) เพื่อดูว่า ZDT ยังคงความได้เปรียบไว้ในกรณีนี้หรือไม่และอีกครั้งเราจะเริ่มต้นด้วยคลาสสิควิธี:

เนื่องจากแหล่งที่มาของการนำไปใช้งานถูกวางไว้ที่ Resource ระยะไกลจึงต้องใช้เวลาเพิ่มขึ้นเล็กน้อยเมื่อเทียบกับการติดตั้งจากไฟล์เก็บถาวรที่อัปโหลดแล้วซึ่งจริงๆแล้วช่วยให้เราเห็นความแตกต่างได้อย่างชัดเจนที่เวลาตอบสนองตอนนี้มีรายการแบบเลื่อนลงที่ค่อนข้างยาว (เกือบ4วินาทีในกรณีของเรา) เกิดจากการไม่พร้อมใช้งานของ Application (คุณจะเห็นได้ว่าคำขอที่เข้ามาเริ่มล้มเหลวในเวลาเดียวกัน - ซึ่งจะแสดงพร้อมกับขัดขวางที่ข้อผิดพลาดกราฟ). อย่างอื่นยังคงคล้ายกับประเภทการใช้งานก่อนหน้า

บันทึก:ต่างจากการ Deploy ไฟล์เก็บถาวร (โดยที่โปรเจ็กต์เก่าถูกลบออกทั้งหมดก่อนที่จะ Deploy ใหม่ซึ่งจะทำให้เกิดการหยุดทำงานเสมอ) ในขั้นตอนนี้ขั้นตอนการอัพเดตจะถือว่าการเปลี่ยนแปลงไฟล์ที่แตกต่างกันเท่านั้นดังนั้นคุณอาจไม่ประสบปัญหาการหยุดชะงักใดๆในการทำงานบริการหากไฟล์ที่จำเป็นต้องเปลี่ยนแปลงนั้นไม่ได้ใช้งานอยู่ในขณะนี้

ในที่สุดการทดสอบครั้งสุดท้ายสำหรับซีดีทีวิธีการ Deploy ผ่าน VCS ยังสอดคล้องกับความคาดหวังของเราโดยนำมาซึ่งความมั่นคงเวลาตอบสนองโดยจะเพิ่มขึ้นเล็กน้อยในระหว่างการรันการดำเนินการพร้อมกันเช่นการจัดการ Session ของผู้ใช้และการคัดลอก/อัปเดตโปรเจ็กต์

ในขณะเดียวกันก็เห็นว่าไม่ข้อผิดพลาดปรากฏขึ้นและคำขอที่เข้ามาทั้งหมดคือประมวลผลสำเร็จแล้ว.

บทสรุป

ตอนนี้เมื่อคุณมีข้อมูลทั้งหมด (ทั้งข้อมูลทางเทคนิคดิบและกราฟที่ใช้งานได้จริง) เกี่ยวกับการสืบสวนและได้เห็นว่าการใช้ตัวเลือก ZDT ภายใน Platform นั้นง่ายเพียงใดก็ถึงเวลาสรุปและสรุปเกี่ยวกับประโยชน์หลักๆที่ได้รับจากการ Host แอป PHP ของคุณ:

• ZDT ไม่ต้องการ Resource เพิ่มเติมใดๆเช่น Instance/เครื่องมือแยกต่างหากในการใช้งานสิ่งที่คุณต้องมีคือพื้นที่ดิสก์เพียงพอสำหรับจัดเก็บสองเวอร์ชันโปรเจ็กต์ (เวอร์ชันปัจจุบันและเวอร์ชันก่อนหน้า) ถือได้ว่าเป็นโซลูชันที่เกือบจะไม่มีค่าใช้จ่ายโดยเฉพาะอย่างยิ่งเมื่อเปรียบเทียบกับตัวเลือกอื่นๆที่เป็นไปได้ส่วนใหญ่ซึ่งอาจต้องใช้ Server แอปตัวปรับสมดุลบริการภายนอกฯลฯเพิ่มเติม
• การ Deploy ยังคงง่ายเหมือนเมื่อก่อน - ไม่ต้องมีการกำหนดค่าเพิ่มเติมหรือการแทรกแซงของมนุษย์
• เวลาที่จำเป็นสำหรับการ Deploy อะตอมมิกนั้นเหมือนกับวิธีแบบคลาสสิกทุกประการดังนั้นจึงไม่คาดว่าจะเกิดความล่าช้า
• ในที่สุดการใช้งานแบบ Zero-Downtime ก็ย่อมาจากชื่อของมันโดยรับประกันว่าสิ่งนี้จะเกี่ยวข้องกับลูกค้าของคุณด้วยขั้นตอนการอัปเดตที่ไม่มีข้อผิดพลาด (ตรงกันข้ามกับเวอร์ชันคลาสสิกซึ่งหากไม่ได้รับการปรับปรุงเพิ่มเติมจะทำให้เกิดข้อผิดพลาดจำนวนมากแม้ในกรณีของการ Deploy Application ขนาดเล็กอีกครั้ง)

ด้วยวิธีนี้การใช้งานการ Deploy ZDT ทำให้การอัปเดตโปรเจ็กต์ของคุณไม่ยุ่งยากโดยสิ้นเชิงและลูกค้ามองไม่เห็นช่วยให้คุณได้รับประโยชน์สูงสุดจาก Application ของคุณ!