Grails 8 ออกแล้ว ระบบเก่าต้องเตรียม Java ก่อนย้าย

Apache Grails รุ่นพร้อมใช้ทั่วไปกำหนด Java ขั้นต่ำเป็น 21 แปลว่าเครื่องที่ใช้ Java ต่ำกว่านี้ต้องเปลี่ยนก่อนสร้างและเปิดแอป ตามคู่มือทางการครับ รุ่นที่ออกคือ Apache Grails 8.0.0 บน GitHub วันที่ 4 ต.ค. แปลว่าเป็นรุ่นใหม่ที่ทีมดูแลระบบเดิมต้องเริ่มตรวจความเข้ากันได้

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

สรุป 30 วินาที: เกิดอะไรขึ้น

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

Grails เป็น framework หรือชุดเครื่องมือสำเร็จรูปสำหรับสร้างเว็บแอป ใช้ภาษา Groovy บน JVM ซึ่งเป็นระบบที่ใช้เปิดโปรแกรมกลุ่ม Java และมี Spring Boot เป็นฐาน ตามคำอธิบายของเว็บไซต์ Grails คุณไม่จำเป็นต้องเขียนโปรแกรมเป็นเพื่อเข้าใจข่าวนี้ แค่รู้ว่ามันเป็นส่วนเบื้องหลังของเว็บที่องค์กรอาจเลือกใช้

ขั้นต่ำของ Gradle ซึ่งเป็นเครื่องมือประกอบแอปจากไฟล์โปรแกรม เปลี่ยนเป็น 9.7 แปลว่าต้องตรวจเครื่องมือสร้างแอปควบคู่กับ Java ตามInfoQและคู่มือ Grails ส่วนการรับคำขอจากเว็บและการทำงานเบื้องหลังก็มีการเปลี่ยนวิธีจัดการตามรายงานเดียวกัน

ทำไมเรื่องนี้เกี่ยวกับคุณ

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

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

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

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

ทำงานยังไง

คำตอบอยู่ที่ Grails ใช้ส่วนประกอบหลายตัวร่วมกันครับ คู่มือระบุการย้ายฐานไป Spring Boot 4.1.x แปลว่าเครื่องมือที่ช่วยเตรียมและเปิดแอปเปลี่ยนรุ่นใหญ่ด้วย ตัวเลขสายรุ่นนี้ยืนยันจากคู่มือแหล่งเดียว ไม่ควรนำไปตีความว่าแค่เปลี่ยน Grails แล้วส่วนประกอบอื่นจะเข้ากันโดยอัตโนมัติ

คู่มือระบุว่า Grails รุ่นก่อนหน้ากำหนด Java ขั้นต่ำเป็น 17 แปลว่าฐานที่เคยเพียงพอสำหรับรุ่นก่อน ยังไม่ถึงข้อกำหนดใหม่ ข้อมูลเปรียบเทียบนี้มาจากคู่มือ Grails ทีมจึงต้องตรวจทั้งเครื่องนักพัฒนา เครื่องสร้างแอปอัตโนมัติ และเครื่องที่เปิดบริการจริง ตามที่เอกสารแนะนำ

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

ส่วนที่ทีม IT ต้องตรวจเพิ่ม

InfoQ ระบุว่า controller ทั้งหมดเปลี่ยนเป็น REST resources หรือส่วนรับคำขอที่จัดการข้อมูลผ่านเว็บ โดยเลือก controller จาก request หรือคำขอที่เข้ามา แทน mapping หรือตารางจับคู่เส้นทางเดิม รายละเอียดนี้ในชุดแหล่งข้อมูลมีคำอธิบายจาก InfoQ เท่านั้น จึงยังสรุปไม่ได้ว่าเส้นทางของแอปใดต้องแก้บ้าง

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

InfoQ ยังรายงานว่า Grails Promises ทำงานบน Spring Boot Task Executor โดย Promises คือวิธีจัดการงานที่รอผลภายหลัง ส่วน Task Executor คือส่วนจัดการให้โปรแกรมทำงานเหล่านั้น แหล่งนี้ไม่ได้ให้ตัวเลขว่าทำงานเร็วขึ้นเท่าไร จึงควรตรวจงานเบื้องหลังที่แอปใช้จริง แทนการคาดว่าจะเร็วขึ้นทุกกรณี

จุดหักมุม: พร้อมใช้ทั่วไป แต่แอปคุณอาจยังไม่พร้อมย้าย

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

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

เรื่องเงิน / ผลกระทบ

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

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

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

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

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

ข้อมูลที่ยังไม่ชัด และจุดที่แหล่งข่าวพูดไม่ตรงกัน

วันที่มีหลายความหมาย: ข้อมูลหน้า GitHub release ระบุ 4 ต.ค. ขณะที่รายการบล็อก Grails แสดงประกาศวันที่ 8 ต.ค. ส่วนข่าว InfoQ ลงวันที่ 12 ต.ค. แม้ชื่อชุดข่าวกล่าวถึงสัปดาห์วันที่ 5 ต.ค. จึงควรแยกวันออกบน GitHub วันประกาศในรายการบล็อก และวันสื่อรายงาน ไม่เลือกวันใดวันหนึ่งแทนทุกเหตุการณ์

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

ฝั่งสนับสนุนและฝั่งเตือน: InfoQ เน้นการออก GA และการปรับส่วนประกอบ ส่วนคู่มือ Apache Grails เตือนเรื่องเครื่องมือสร้างแอปและค่าตั้งที่เข้ากันไม่ได้ นี่เป็นมุมประโยชน์เทียบกับข้อจำกัดในการย้าย ไม่ใช่หลักฐานว่าองค์กรหนึ่งคัดค้านการออก Grails ไม่มีคำให้สัมภาษณ์ฝ่ายต่อต้านในแหล่งที่ได้รับ จึงไม่ควรแต่งเสียงค้านขึ้นมา

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

เส้นทางจากระบบเก่า: คู่มือที่ได้รับอธิบายการย้ายจาก Grails 7.x แปลว่าขั้นตอนส่วนนี้ตั้งต้นจากสายรุ่นก่อนหน้า แต่ไม่ได้สั่งชัดว่าทุกรุ่นเก่าต้องผ่านสายนี้เสมอ สำหรับแอปที่ใช้ Java ต่ำกว่าขั้นต่ำใหม่ อย่าสรุปว่าปรับเลข Grails แล้วจบ ต้องหาแผนที่ตรงกับต้นทางของแอปก่อน

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

แล้วเราควรทำอะไร

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

คนใช้งานและเจ้าของกิจการ

1. ขอชื่อผู้รับผิดชอบระบบและรุ่นที่ใช้อยู่จากทีม IT หรือผู้รับจ้าง อย่าเริ่มด้วยการสั่งอัปเกรดทั้งหมด ให้ทีมยืนยันก่อนว่าเว็บของคุณใช้ Grails จริงหรือไม่
2. ทำรายการงานที่หยุดไม่ได้ เช่น ส่งคำขอ บันทึกรายการ และแนบเอกสาร นำไฟล์ตัวอย่างที่ไม่มีข้อมูลอ่อนไหวไปให้ทีมทดสอบ พร้อมจดว่าผลลัพธ์เดิมควรเป็นอย่างไร
3. ขอแผนวันทดสอบ วันเปลี่ยนระบบ และวิธีกลับไปใช้รุ่นเดิม หากผลไม่ผ่าน กำหนดคนตัดสินใจชัดเจน เพื่อไม่ให้ผู้ใช้งานต้องเป็นคนพบปัญหาเป็นกลุ่มแรก

ทีม IT และผู้ดูแลเครื่อง

1. สำรวจ Java ที่ใช้จริงทุกจุด ตั้งแต่เครื่องพัฒนาไปถึงเครื่องบริการ ตรวจแยกจากรุ่นที่เขียนไว้ในเอกสาร เพราะข้อกำหนด Grails ครอบคลุมทั้งการสร้างและการเปิดแอป
2. ตรวจ Gradle wrapper และเครื่องสร้างแอปอัตโนมัติ หรือ CI ซึ่งเป็นระบบที่สั่งประกอบและตรวจโปรแกรมแทนคน อย่าตรวจเฉพาะเครื่องของนักพัฒนา ตามคำเตือนเรื่อง wrapper ในคู่มือ
3. เตรียม staging หรือระบบทดสอบที่แยกจากบริการจริง พร้อมสำรองข้อมูลและบันทึกค่าตั้ง ให้เจ้าของงานลองขั้นตอนประจำวันก่อนเลือกช่วงเปลี่ยนระบบ
4. แยกติดตามการเปิดแอป การรับไฟล์ และงานเบื้องหลัง ตรวจพื้นที่เก็บไฟล์ชั่วคราวด้วย เพราะคู่มือระบุว่าค่าเริ่มต้นตำแหน่งอัปโหลดเปลี่ยนไปใช้พื้นที่ของตัวเปิดเว็บ

นักพัฒนาและผู้รับจ้างดูแลแอป

1. ทำรายการรุ่น Grails ปัจจุบันและปลั๊กอินทุกตัว พร้อมหลักฐานว่ารองรับฐานใหม่ หากโครงการเก่ากว่าสายที่คู่มืออธิบาย ให้ตรวจขั้นตอนของรุ่นต้นทางก่อน ไม่ประกาศว่าข้ามได้หรือข้ามไม่ได้โดยไม่มีเอกสาร
2. ใช้ Spring Boot properties migrator ซึ่งเป็นเครื่องมือหาค่าตั้งที่เลิกใช้หรือย้ายชื่อ ระหว่างย้ายตามคำแนะนำ Grails เปิดแอปเพื่อตรวจคำเตือน แล้วนำเครื่องมือนี้ออกเมื่อจัดค่าตั้งเสร็จ
3. ทดสอบเส้นทางรับคำขอและงาน Promises ที่โครงการใช้จริง โดยอิงการเปลี่ยนแปลงที่InfoQ รายงาน บันทึกผลสำเร็จและผลเมื่อเกิดข้อผิดพลาด แทนการดูแค่หน้าแรก
4. ตรวจช่องข้อมูลที่แบบฟอร์มอนุญาตให้บันทึก ถ้าจะใช้โหมดปฏิเสธช่องที่ไม่ได้อนุญาต ต้องกำหนดช่องให้ชัด ตามคู่มือการผูกข้อมูล พร้อมทดสอบว่าแบบฟอร์มที่ถูกต้องยังใช้งานได้
5. ตรวจการอัปโหลด เอกสาร XML และการเชื่อมฐานข้อมูลตามที่แอปใช้อยู่ แยกปัญหาที่เกิดจากส่วนเสริมออกจากข้อกำหนดหลัก แล้วรายงานผลให้เจ้าของงานอ่านเข้าใจได้

ผมมองว่า…

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

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

ปิดท้าย: สิ่งที่ต้องจับตา

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

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

Recap

• เกิดอะไรขึ้น: GitHub ออก Apache Grails รุ่นใหม่ และ InfoQ รายงานว่าเป็น GA หรือพร้อมใช้ทั่วไป
• ตัวเลขที่จำ: Java ขั้นต่ำ 21 แปลว่าต้องตรวจฐานของเครื่องก่อนย้าย ตามคู่มือ
• เครื่องมือสร้างแอป: Gradle ขั้นต่ำ 9.7 แปลว่า wrapper เดิมต้องได้รับการตรวจด้วย ตามInfoQ
• จุดต่างของแหล่งข่าว: วันออกบน GitHub ต่างจากวันประกาศในรายการบล็อก ส่วน InfoQ เน้นข่าวรุ่นใหม่ คู่มือเน้นข้อควรระวัง ไม่พบเสียงคัดค้านที่ยืนยันได้
• ยังไม่รู้: วันสิ้นสุดการสนับสนุนสายเก่า รุ่น Groovy ที่แน่ชัด และผลกับปลั๊กอินเฉพาะขององค์กร
• ผลต่อคุณ: ให้เจ้าของงานตรวจการแนบไฟล์และบันทึกข้อมูลในระบบทดสอบ ก่อนอนุมัติวันย้ายจริง
• จับตา: หลักฐานปลั๊กอินรองรับและข้อมูลการสนับสนุนเพิ่มเติม อย่าใช้สถานะ GA เป็นกำหนดอัปเกรดเพียงอย่างเดียว
• แหล่งอ่าน: 1 — GitHub release, 2 — InfoQ, 3 — บล็อก Grails, 4 — คู่มืออัปเกรด