ทำไม CI ถึงพัง? เมื่อฐานข้อมูลไม่รู้จักคำสั่งที่เราใช้
ในการพัฒนาซอฟต์แวร์ CI (Continuous Integration) หรือกระบวนการทดสอบโค้ดอัตโนมัติทุกครั้งที่เราบันทึกงาน ถือเป็นหัวใจสำคัญที่ช่วยให้เรามั่นใจว่าโค้ดใหม่จะไม่ไปทำลายฟีเจอร์เดิมที่มีอยู่ เปรียบเสมือนการมี "ผู้ช่วยตรวจการบ้าน" ที่คอยเช็กว่าโค้ดของเราทำงานได้ถูกต้องตามเงื่อนไขที่วางไว้หรือไม่ก่อนที่จะนำไปใช้งานจริง
ปัญหาที่พบบ่อยสำหรับมือใหม่คือ เมื่อเราต้องการใช้เทคโนโลยีใหม่ๆ เช่น pgvector ซึ่งเป็นเครื่องมือเสริมสำหรับ PostgreSQL ที่ช่วยให้ฐานข้อมูลเก็บข้อมูลแบบเวกเตอร์ (Vector) สำหรับงาน AI ได้ เรามักจะลืมไปว่า "สภาพแวดล้อมการทดสอบ" หรือตัวจำลองฐานข้อมูลใน CI นั้นไม่ได้ถูกติดตั้งเครื่องมือเสริมเหล่านี้มาให้ตั้งแต่ต้นเหมือนกับที่เราทำในเครื่องคอมพิวเตอร์ของเราเอง
เมื่อโปรแกรมของเราพยายามสั่ง CREATE EXTENSION IF NOT EXISTS vector ในขั้นตอนการทดสอบ ระบบ CI จะแจ้งเตือนว่าหาคำสั่งนี้ไม่เจอ เพราะฐานข้อมูลที่มันใช้อยู่เป็นเพียงรุ่นมาตรฐานทั่วไปที่ไม่มีความสามารถในการประมวลผลเวกเตอร์ หากเราไม่แก้ไขจุดนี้ ต่อให้โค้ดจะเขียนมาดีแค่ไหน แต่กระบวนการทดสอบก็จะ ล้มเหลว (Failed) ตั้งแต่เริ่ม เพราะตัวทดสอบไม่เข้าใจว่าเรากำลังคุยเรื่องอะไรนั่นเอง
เข้าใจความสัมพันธ์ระหว่าง Application และ Database Service
เพื่อให้เห็นภาพชัดขึ้น ลองนึกถึงการทำอาหารในครัว Application ของเราคือ "เชฟ" ที่มีสูตรอาหารพิเศษ ส่วน Database Service คือ "อุปกรณ์ในครัว" หากเชฟต้องการทำเมนูที่ต้องใช้ "เตาอบพิซซ่า" แต่ในครัวจำลองที่เราเตรียมไว้ให้ CI มีแค่ "เตาแก๊สธรรมดา" เชฟก็จะทำอาหารเมนูนั้นไม่สำเร็จแน่นอน
ในโปรเจกต์ FastAPI ที่เชื่อมต่อกับฐานข้อมูล PostgreSQL เรามักจะใช้ Docker หรือคอนเทนเนอร์ (Container) ซึ่งเป็นเหมือนกล่องบรรจุซอฟต์แวร์ที่แยกส่วนออกมา เพื่อจำลองฐานข้อมูลขึ้นมาใหม่ทุกครั้งที่ทดสอบ หากเราเลือกใช้ Image (ไฟล์ต้นแบบของคอนเทนเนอร์) ที่เป็น PostgreSQL รุ่นปกติ มันจะไม่มีความสามารถในการจัดการข้อมูล AI หรือ Vector Embedding มาให้
มือใหม่มักพลาดโดยการพยายามติดตั้ง Extension เข้าไปทีละขั้นตอนใน CI ซึ่งนอกจากจะทำให้กระบวนการทดสอบช้าลงแล้ว ยังเพิ่มความเสี่ยงที่การติดตั้งจะผิดพลาดได้ ทางออกที่ดีที่สุดคือการเลือกใช้ Image ของฐานข้อมูลที่ติดตั้งเครื่องมือที่จำเป็นมาให้แล้วตั้งแต่แรก เพื่อให้มั่นใจว่าทั้ง "เชฟ" และ "อุปกรณ์" จะเข้าใจภาษาเดียวกันเสมอ
วิธีแก้ปัญหาด้วยการเปลี่ยน Database Image ให้ตรงจุด
การแก้ไขที่ถูกต้องและยั่งยืนที่สุดคือการเปลี่ยน Service Definition ในไฟล์คอนฟิกูเรชันของ CI ให้เรียกใช้ Image ที่รองรับ pgvector โดยตรง แทนที่จะพยายามแก้ไขทีละบรรทัดในขั้นตอนการทดสอบ วิธีนี้จะช่วยให้ระบบ CI ของเรามีความเสถียรและจำลองสภาพแวดล้อมใกล้เคียงกับตอนที่เราเขียนโค้ดจริงมากที่สุด
ลองเปรียบเทียบระหว่างการใช้ค่าเริ่มต้นกับค่าที่ปรับปรุงแล้ว ดังนี้:
# แบบเดิม: ใช้ PostgreSQL รุ่นปกติ (พังเมื่อใช้ฟีเจอร์ pgvector)
services:
postgres:
image: postgres:17-alpine
# แบบที่ถูกต้อง: ใช้ Image ที่มี pgvector ติดตั้งมาพร้อมใช้งาน
services:
postgres:
image: pgvector/pgvector:0.8.6-pg17
ในตัวอย่างนี้ เราเปลี่ยนจาก postgres:17-alpine มาเป็น pgvector/pgvector:0.8.6-pg17 ซึ่งเป็น Image ที่เตรียมไว้สำหรับงานเวกเตอร์โดยเฉพาะ การเปลี่ยนแปลงเพียงบรรทัดเดียวนี้ส่งผลให้ระบบ CI สามารถรันคำสั่ง CREATE EXTENSION ได้สำเร็จโดยไม่ต้องติดตั้งอะไรเพิ่มเติมในภายหลัง
ผลลัพธ์ที่ได้: เมื่อ CI กลับมาเขียวสดใสอีกครั้ง
หลังจากที่เราเปลี่ยนมาใช้ pgvector Image สิ่งที่เกิดขึ้นคือกระบวนการทดสอบจะผ่านไปได้อย่างราบรื่น ขั้นตอนการเตรียมฐานข้อมูล (Database Initialization) จะทำงานได้ครบถ้วนโดยไม่มีข้อผิดพลาดแจ้งเตือนว่า "ไม่รู้จักคำสั่ง" อีกต่อไป ซึ่งนี่คือสัญญาณที่ดีว่าระบบของเรามีความพร้อมใช้งาน
ตารางเปรียบเทียบก่อนและหลังการแก้ไข:
- ก่อนแก้ไข: CI ล้มเหลวในขั้นตอน Run tests เพราะฐานข้อมูลไม่มี Extension รองรับ
- หลังแก้ไข: CI ผ่านการทดสอบทั้งหมด (Passed) เพราะฐานข้อมูลมีเครื่องมือที่จำเป็นครบถ้วน
การที่ระบบทดสอบผ่านทั้งหมดแสดงว่า Integration Tests ของเรากำลังทำงานอย่างมีความหมาย มันไม่ใช่แค่การรันโค้ดผ่านๆ ไป แต่เป็นการตรวจสอบว่าฟีเจอร์ AI ของเราสามารถบันทึกและดึงข้อมูลเวกเตอร์จากฐานข้อมูลจริงได้ถูกต้องจริงๆ นี่คือหัวใจสำคัญของการเขียนโปรแกรมที่มีคุณภาพ คือการทำให้สภาพแวดล้อมการทดสอบเหมือนจริงที่สุดเท่าที่จะทำได้
บทเรียนสำหรับมือใหม่: อย่ามองข้าม Infrastructure
หลายคนมักโฟกัสแค่การเขียนโค้ดภาษา Python หรือการสร้าง API แต่ลืมไปว่า Infrastructure (โครงสร้างพื้นฐาน) อย่างฐานข้อมูลหรือระบบเครือข่าย ก็เป็นส่วนหนึ่งของโค้ดที่เราต้องรับผิดชอบ หากเราใช้เครื่องมือที่ซับซ้อน เราต้องเตรียมสภาพแวดล้อมที่รองรับเครื่องมือนั้นๆ ให้ครบถ้วน
คำแนะนำสำหรับมือใหม่คือ ให้มองว่า Database Extension เป็นหนึ่งใน Dependencies เหมือนกับไลบรารีใน Python หากแอปพลิเคชันของคุณต้องการ pgvector คุณต้องระบุให้ชัดเจนว่า CI ต้องเตรียมสิ่งนี้มาให้ อย่าปล่อยให้มันเป็นเรื่องของ "โชคช่วย" หรือ "การติดตั้งหน้างาน" เพราะนั่นคือจุดที่ทำให้บั๊กเกิดขึ้นได้บ่อยที่สุด
การฝึกนิสัยเช็ก Service Compatibility หรือความเข้ากันได้ของบริการต่างๆ จะช่วยให้คุณประหยัดเวลาในการแก้ปัญหาไปได้มหาศาล เมื่อคุณก้าวเข้าสู่การทำงานจริงในบริษัท การรู้วิธีจัดการกับ Docker และ CI จะทำให้คุณดูเป็นโปรแกรมเมอร์ที่รอบคอบและแก้ปัญหาได้ตรงจุด ซึ่งเป็นทักษะที่หัวหน้าทีมมองหาเสมอ
สรุป: การนำไปใช้จริงในโปรเจกต์ของคุณ
จากบทเรียนเรื่อง Fixing a pgvector CI mismatch เราได้ข้อสรุปว่า การเลือกเครื่องมือใน CI ให้ตรงกับความต้องการของแอปพลิเคชันนั้นสำคัญพอๆ กับการเขียนโค้ด หากคุณกำลังทำโปรเจกต์ AI ที่ต้องใช้ฐานข้อมูลแบบ Vector ให้ตรวจสอบเสมอว่า Docker Image ที่คุณใช้ใน CI สนับสนุน Extension เหล่านั้นหรือไม่
ตัวอย่างการนำไปใช้จริง: สมมติว่าคุณกำลังพัฒนาโปรเจกต์แชทบอทที่ใช้ Redis ในการเก็บ Cache ในอนาคตคุณไม่ควรใช้ Image redis:latest แบบลอยๆ แต่ควรเจาะจงเวอร์ชันให้ชัดเจน เช่น redis:7.2-alpine และตรวจสอบว่าเวอร์ชันนั้นรองรับฟีเจอร์ที่คุณจะใช้หรือไม่ เพื่อป้องกันปัญหา "ใช้ได้ในเครื่องเรา แต่พังใน CI" ซึ่งเป็นปัญหาคลาสสิกของชาวโปรแกรมเมอร์ทุกคน
จำไว้ว่า ความน่าเชื่อถือของระบบทดสอบคือความมั่นใจของคุณ ยิ่งคุณทำให้ CI ของคุณใกล้เคียงกับ Production (สภาพแวดล้อมจริง) มากเท่าไหร่ คุณก็จะยิ่งนอนหลับสบายมากขึ้นเท่านั้น เพราะมั่นใจว่าโค้ดที่ผ่าน CI ไปได้ จะไม่มีปัญหาฐานข้อมูลพังตามมาภายหลังแน่นอนครับ
ที่มา: Fixing a pgvector CI mismatch in a FastAPI RAG backend — DEV Community
