เรื่องที่ 32 ที่นักพัฒนาควรรู้ และ เข้าใจก็คือ One Binary
ในการพัฒนา software นั้นมักพบว่า
ในการ build หรือ package software นั้น มักจะต้องทำการแก้ไขอะไรบางอย่าง
ให้ตรงตามแต่ละ environment ที่จะทำการติดตั้ง เช่น
- Local machine
- Development server
- Test server
- Staging server
- Production server
ซึ่งที่ทำกันนั้นมันบ่งบอกให้เห็นว่า
เรากำลังสร้างระบบที่มีความซับซ้อน หรือมีขั้นตอนที่ซับซ้อนเกินไป
ผลก็คือ เสี่ยงต่อความผิดพลาดอย่างมาก
แต่เราก็ยังคงทำเช่นนั้นอยู่ แปลกดีนะ !!
คำถาม
เคยไหมที่เราทำการ configuration หรือ setting ผิดพลาด ?
เคยไหมที่ลืมแก้ไขอะไรบางอย่าง ?
เคยไหมที่ต้องทำการ build หรือ package software ใหม่ทุกๆ ครั้งที่จะติดตั้ง ?
เคยไหมที่ต้องทำการ build หรือ package software ใหม่ในแต่ละ environment ?
เคยไหมที่ต้อง copy package software จาก environment หนึ่งไปอีก environment หนึ่ง ?
เคยไหมที่มักจะผิดพลาด ?
เคยไหมที่จะเปลี่ยน ?
เคยไหมที่จะปรับปรุง ? เคยสิ … แต่ว่า …
หนึ่งในวิธีการแก้ไขปัญหานี้ คือ One Binary ไงล่ะ
มาลองดูกันว่ามันเป็นอย่างไร
โดยปกติในการพัฒนา software นั้น
เมื่อ developer ทำการแก้ไข code และ checkin/commit code ไปยัง Version Control แล้ว
จะมีระบบการ build software เต็มขั้นคือ
- การ compile
- ทำการทดสอบด้วย unit test, integration
- การตรวจสอบ source code เช่น Static Analysis Tool
- ทำการ package software
- ทำการติดตั้งใน environment ต่างๆ
- ทำการทดสอบแบบ อัตโนมัติ
- ทำการทดสอบแบบ manual
- และอื่นๆ อีกมากมาย
สิ่งที่มักพบก็คือ
เมื่อจะทำการ deploy software บน Staging หรือ Production server
เรามักจะทำการ build อีกรอบ ด้วย script หรือขั้นตอนเดิมที่เคยทำไว้
ปัญหาคืออะไรล่ะ ?
คุณจะมั่นใจได้อย่างไร ว่าสิ่งที่คุณ build ขึ้นมาใหม่
มันคือ version เดียวกับสิ่งที่ผ่านการทดสอบมาแล้ว ??
ผลมันคืออะไร … ความผิดพลาดไงล่ะ และงานก็มักจะเข้านะสิ !!
ดังนั้น มีกฎง่ายๆ มาช่วยแก้ไขคือ
Build a single binary that you can identify and promote
through all the stages in the release pipeline
แปลง่ายๆ ว่า
มี software package เพียงตัวเดียวในแต่ละ version
ซึ่งสามารถทำการ deploy ได้ในทุกๆ environment นั่นเอง
โดยจะไม่ทำการแก้ไขอะไรเลย
หรือ One Binary นั่นเอง
ส่วนเรื่อง configuration อื่นๆ ให้ไปทำในแต่ละ environment เองนะ
อย่ามาแก้ไข หรือ เปลี่ยนแปลงในสิ่งที่จะทำการ deploy
ไม่ใช่นนั้นก็จะเกิดความผิดพลาดเช่นเดิม
ตัวอย่างที่มักเกิดข้อผิดพลาด
พวกไฟล์ configuration ที่มักกำหนด path
- Local machine กำหนดว่า c:\myconfig
- Development server กำหนดว่า /home/projectx/myconfig
- Production server กำหนดว่า /var/local/projectx/myconfig
คำถามคือ คุณจะแก้ไขปัญหานี้อย่างไรล่ะ ?
ทำการ build ตามแต่ละ environment เลยไหม ?
เข้าไปแก้ไขไฟล์ config เลยสิ ?
มีหลากหลายแนวทางนะ แต่ทางไหนที่มันลดความเสี่ยงล่ะ ?
ลองคิดดูเอากันเองนะครับ
บางคนบอกว่า เราทำแบบนี้ไม่ได้หรอก
เพราะว่า ติดปัญหา เงื่อนไขต่างๆ เยอะมาก
แต่เชื่อเถอะว่ามันทำได้
ถ้าคุณเพียงเริ่มทำ
ถ้าคุณเพียงแก้ไขปัญหาไปทีละปัญหา
แต่ถ้าคุณปล่อยไปเรื่อยๆ ระบบเหล่านั้นมันจะกลับมาเล่นงานคุณอย่างหนัก
และหนักหน่วงขึ้นไปเรื่อยๆ
และมักจะบ่นว่าเราทำงานกับ Legacy code นะ
และก็มักจะเพียงแค่บ่น แล้ว ก้มหน้าก้มตาทำมันไปให้เสร็จ !!!
ยังไม่พอนะ พวก configuration ของ environment
ก็ควรจัดทำ version ไว้ด้วยเช่นกัน
เพราะว่า บ่อยครั้งมักพบว่าปัญหาเกิดจากการ configuration ที่ผิดพลาด
ซึ่งควรแยกการจัดการ version ออกจาก code นะครับ
เนื่องจากอัตราและเหตุผลในการเปลี่ยนแปลงมันแตกต่างกัน
ในปัจจุบันเรื่อง configuration ของ environment ต่างๆ มันง่ายขึ้นมาก
ส่วนเครื่องมือที่ผมมักใช้งานในการจัดเก็บ software package เช่น
ทำในแต่สิ่งที่จำเป็นนะครับ อะไรที่ไม่จำเป็นก็ ลด ล่ะ เลิก ลงไปก็ได้บ้างนะ
ไม่ต้องขยันขนาดนั้น !!
