มีบอร์ดหลายตัวแล้ว จะปล่อย firmware ให้ใครลองก่อน

มีบอร์ดหลายตัวแล้ว จะปล่อย firmware ให้ใครลองก่อน - Image 1
09/11/2025•Admin Team•
ESP32IoTTutorialota

ตอนมีบอร์ดตัวเดียว การบิ้วแล้วอัปโหลดรุ่นใหม่ก็เป็นเรื่องตรงไปตรงมา หากมีอะไรผิด เราเสียบสายแก้ต่อได้ทันที แต่พอมีทั้งบอร์ดบนโต๊ะ เครื่องที่เอาไว้ทดลอง และเครื่องที่คนอื่นกำลังใช้อยู่ คำว่ารุ่นล่าสุดก็เริ่มไม่ควรถูกส่งไปถึงทุกตัวพร้อมกัน

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

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

รู้ว่าไฟล์นี้ถูกสร้างมาให้เครื่องแบบไหน

เลขเวอร์ชันช่วยอ้างอิงแอป แต่ยังควรมีข้อมูลฮาร์ดแวร์ที่รองรับ ชุดบิ้ว และข้อกำหนดการติดตั้งด้วย เพราะ source code รุ่นเดียวกันสามารถบิ้วออกมาได้หลายไฟล์ตาม board, framework และตัวเลือกที่ใช้

จึงควรเก็บ commit กับข้อมูล build ไปพร้อม artifact และมีตัวตรวจความสมบูรณ์ตามระบบที่ใช้ เมื่อเลือกแจกไฟล์ก็ตรวจความเข้ากันได้ก่อน ไม่ใช้ชื่อไฟล์อย่าง latest.bin เป็นหลักฐานเพียงอย่างเดียวว่าตรงกับเครื่องที่กำลังขอ

ตรวจความเข้ากันได้ระหว่างไฟล์เฟิร์มแวร์กับข้อมูลอุปกรณ์และบริการก่อนกำหนดรุ่นเป้าหมาย

รายการอุปกรณ์ก็ควรบอกทั้งรุ่นฮาร์ดแวร์ firmware ที่รายงานล่าสุด และการตั้งค่าที่สำคัญต่อการเลือกไฟล์ หากเครื่องไม่ได้ติดต่อมานาน ข้อมูลนั้นต้องมีเวลาอ้างอิงด้วย ไม่แสดงรุ่นที่ระบบอยากให้ติดตั้งเหมือนเป็นรุ่นที่เครื่องใช้อยู่แล้ว

การมี desired version กับ observed version แยกกันช่วยให้เห็นงานที่ยังไม่จบ เช่น ตั้งให้รับรุ่นใหม่แล้วแต่เครื่องยังไม่ได้ดาวน์โหลด หรือเครื่องทดลองแล้วกลับไปใช้รุ่นก่อน หากใช้ช่องเดียวเก็บทั้งสองความหมาย สถานะบนจอจะดูสำเร็จเร็วกว่าสิ่งที่เกิดจริง

channel เป็นนโยบายรับรุ่น ไม่ใช่รุ่นของตัวมันเอง

ชื่ออย่างทดลอง ทดสอบก่อนใช้งาน หรือใช้งานปกติ ช่วยแบ่งความคาดหวังว่าเครื่องใดควรได้รับรุ่นใด แต่ควรมีรายการอ้างอิงไฟล์ที่แน่นอนอยู่เบื้องหลัง ไม่ให้ channel กลายเป็นชื่อที่วันนี้หมายถึงไฟล์หนึ่งแล้วพรุ่งนี้เปลี่ยนโดยไม่เหลือประวัติ

เมื่อเลื่อนรุ่นผ่านกลุ่ม ควรใช้ artifact ที่ผ่านการตรวจเดิมตามเงื่อนไขที่กำหนด ไม่บิ้วใหม่แบบเปลี่ยน dependency ไปแล้วเรียกว่าไฟล์เดียวกันเพียงเพราะเลขเวอร์ชันเหมือนเดิม หากต้องบิ้วต่างตามฮาร์ดแวร์ ก็ต้องมีหลักฐานของไฟล์แต่ละชุดแยกกัน

เส้นทางปล่อยเฟิร์มแวร์จากเครื่องทดสอบไปกลุ่มตัวแทนก่อนขยาย โดยแยกดาวน์โหลด บูต และยืนยันพร้อมใช้งาน

กลุ่มทดลองควรถูกเลือกจากความสามารถกู้และความหลากหลายที่อยากตรวจ เช่น มีเครื่องที่เข้าถึงง่ายสำหรับแต่ละฮาร์ดแวร์หลัก ไม่เลือกเพียงเครื่องเดียวที่เหมือนสภาพบนโต๊ะทุกอย่างแล้วถือว่าเป็นตัวแทนทุกจุดติดตั้ง

ส่วนคำว่า canary หรือปล่อยบางส่วนไม่ได้ทำให้ปลอดภัยเอง ประโยชน์เกิดจากเรามีเงื่อนไขดูผลและยังหยุดขยายได้ทัน หากปล่อยกลุ่มแรกแล้วส่งทั้งหมดตามเวลาทันทีโดยไม่อ่านข้อมูล ก็ยังไม่ได้ใช้โอกาสเรียนรู้จากกลุ่มแรกเท่าไร

กำหนดว่าผ่านจากหลักฐานอะไร

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

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

ควรมีช่วงสังเกตตามพฤติกรรมที่ต้องการตรวจด้วย ปัญหาที่เกิดหลังหลายรอบอ่านหรือหลัง reconnect อาจไม่ปรากฏทันทีหลังบูต แต่ระยะที่เลือกต้องมีเหตุผลจากงานและหลักฐาน ไม่กำหนดนานเพียงเพื่อให้ดูรอบคอบโดยไม่มีสิ่งที่ต้องสังเกต

ถ้าเจอปัญหา ให้หยุดการกระจายก่อนตามแก้

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

หากมี rollback ก็ยังต้องตรวจข้อมูลที่รุ่นเก่าจะอ่านกลับได้ และไม่ส่งไฟล์เดิมซ้ำไปยังเครื่องที่เพิ่งย้อนกลับทันทีโดยไม่มีเงื่อนไขเปลี่ยน การปล่อยที่ดีควรเห็นว่าเครื่องนั้นเคยปฏิเสธรุ่นใดและเพราะอะไร

ส่วนปัญหาที่เกิดเฉพาะฮาร์ดแวร์บางแบบ อาจต้องหยุดเฉพาะกลุ่มที่เกี่ยวข้อง แต่การตัดสินควรมีข้อมูลรุ่นและการตั้งค่าที่ครบตั้งแต่ต้น หากเราเก็บเพียงจำนวนเครื่องสำเร็จรวม ก็จะตามความสัมพันธ์เหล่านี้ยากในเวลาที่ต้องการคำตอบเร็ว

firmware ต้องใช้ร่วมกับบริการส่วนอื่นได้

เมื่ออุปกรณ์คุยกับ API หรือส่ง payload ให้ Dashboard การปล่อย firmware ก็เกี่ยวกับความเข้ากันได้ของฝั่งรับด้วย ควรจดว่ารูปแบบข้อมูลรุ่นใดได้รับการรองรับและมีช่วงย้ายอย่างไร ไม่อัปเดตทุกฝ่ายโดยสมมติว่าจะเกิดพร้อมกันเสมอ

เครื่องที่ offline อาจกลับมาพร้อม firmware เก่าหลัง backend เปลี่ยนไปแล้ว ระบบจึงควรมีวิธีรับมือเวอร์ชันเก่าตามนโยบายที่กำหนด ไม่ให้เครื่องที่ยังทำงานได้ถูกมองว่าเสียเพียงเพราะกลับมาไม่ทันรอบปล่อยล่าสุด

รายการทดสอบควรรวมทั้งการอัปเดตจากรุ่นที่ยังมีเครื่องใช้อยู่และการอ่านข้อมูลจากเครื่องเก่าระหว่างย้ายรุ่น หากเส้นทางรองรับมีหลายช่วง ก็ควรบอกให้ชัดว่าเครื่องใดต้องผ่านรุ่นกลางก่อน ไม่ปล่อยให้บริการเลือกข้ามตามตัวเลขรุ่นอย่างเดียว

ทุกครั้งที่ย้าย channel ควรเก็บว่าใครหรือขั้นตอนใดเปลี่ยน จากไฟล์ใดไปไฟล์ใด และใช้ผลตรวจชุดไหนประกอบ เพื่อให้การย้อนดูเป็นประวัติการตัดสินใจ ไม่ต้องเดาจากสถานะปัจจุบันที่เปลี่ยนไปแล้ว

สรุป

การปล่อย firmware หลายเครื่องควรแยก artifact, channel และสถานะจริงของอุปกรณ์ พร้อมมีเกณฑ์ผ่านกับทางหยุดที่ใช้ได้ เมื่อเก็บความเข้ากันได้ของฮาร์ดแวร์และบริการร่วมไว้ด้วย เราจะค่อยๆ ขยายรุ่นจากกลุ่มที่กู้ได้ง่ายไปสู่กลุ่มใช้งาน โดยรู้ว่ามีหลักฐานอะไรแล้วและยังมีเครื่องใดต้องตามต่อครับ

Command Eng Logo
CMD yourNgineers
เลขประจำตัวผู้เสียภาษี0805564000814
บทความ
ติดต่อบริษัท คอมมานด์ เอ็นจ์ จำกัด
81/36 เพอร์เฟค พาร์คบางนาตำบลบางเสาธง อำเภอบางเสาธงจังหวัดสมุทรปราการ 10570
team@commandeng.in.th+66 89 393 5191
Facebook Page | Command EngLine | Command Eng Official
© Copyright 2022-2026 Command Eng Co., Ltd.v1.0.4 · 0d556ab · 2026-11-03 15:23