นักพัฒนาน่าจะคุ้นเคยกับการจัดการเรื่องของ configuration ค่าต่าง ๆ ในระบบเป็นอย่างดี
ยกตัวอย่างเช่น

  • ข้อมูลสำหรับ database
  • ข้อมูลสำหรับ URL ของ service ต่าง ๆ
  • username และ password

บ่อยครั้งมักจะทำการ hardcode เอาไว้ใน source code !!

ยกตัวอย่างเช่น

database_connect("dev.db.com", "admin", "admin")

สิ่งที่น่ากลัวคือ เรามักเจอว่า
code เหล่านี้มันขึ้นไปยัง environment ต่าง ๆ รวมทั้ง production server 
ด้วยเหตุผลง่าย ๆ สั้น ๆ ว่า ลืม !!

หนักกว่านั้น เมื่อมีการเปลี่ยนแปลงค่าต่าง ๆ
วิธีการที่ชอบทำกันก็คือ search และ replace all !!

จากนั้นเริ่มแก้ไขปัญหาด้วยการแยกออกมาใส่ไฟล์ (Configuration file)

เป็นที่มาของ configuration file นั่นเอง
เรามักจะเจอไฟล์ประเภทนี้ในหลากหลายรูปแบบและลีลา
ทั้งแยกไฟล์ตามแต่ละ environment
ทั้งไฟล์เดียวแต่มีการตรวจสอบค่า profile เช่น dev, test, prod เป็นต้น
ทั้งเป็น application file ของระบบหรือ framework

แต่ปัญหาคำว่า ลืม ก็ยังตามมาหลอกหลอนอยู่ดี
เพราะว่า ไฟล์เหล่านี้ยังอยู่ใน Source Control อยู่ดี
และจัดการด้วยคน !!

ดังนั้นเราจึงแก้ไขปัญหาด้วยการห้าม commit/push/checkin ไฟล์เหล่านี้ขึ้นไป
หรือทำการ ignore นั่นเอง
เพื่อลดข้อผิดพลาดของนักพัฒนา หรือ กันลืม นั่นเอง
แต่ปัญหามันก็ถูกส่งต่อไปให้คนที่ดูแลเรื่องการ deploy และ release อีก !!

จึงมีอีกแนวคิดหนึ่งคือ ก็ใช้ configuration เดียวกันในทุก ๆ environment สิ !!

ลองคิดดูสิว่า ถ้าทุก ๆ ส่วนมีค่าเหมือนกัน
ตั้งแต่ local -> dev -> test -> uat -> staging -> production
เราจะเสียเวลามาดูแลเรื่อง configuration กันไปทำไม
แต่เมื่อพูดและบอกแบบนี้ไป ก็บอกว่า
มันเป็นไปไม่ได้หรอกนะ
เพราะว่า ….
เพราะว่า ….
เพราะว่า ….

แต่ลองเปลี่ยนแนวคิดว่า เราจะทำให้ configuration ในทุก ๆ environment เหมือนกันสิ
วิธีการมันก็เปลี่ยนไปแล้ว ใช่ไหม ?

จะเห็นได้ว่าปัญหามันเกิดจากคน ที่ดันลืม !!

แก้ไขปัญหาที่ต้นเหตุของปัญหากันดีกว่านั่นคือ คน
ดังนั้นจึงมีแนวคิดเรื่องของ automation หรือการทำงานแบบอัตโนมัติ
ทั้งเรื่องของ shell script และ เครื่องมือต่าง ๆ

ยกตัวอย่างเช่น
Dynamic configuration ตามแต่ละ environment
ซึ่งถูกกำหนดไว้ใน environment variable เช่น

$NODE_ENV=production npm run build

ทำให้สิ่งต่าง ๆ เริ่มดีขึ้น

แต่จะเห็นได้ว่า configuration ระหว่าง application กับ infrastructure ยังแยกกัน !!

ซึ่งทำให้เกิดปัญหาตามมาได้
ดังนั้นสิ่งที่ควรทำคือ infrastructure ควรมี configuration ต่าง ๆ ที่ application ต้องการให้ครบ
และ configuration ของทั้งคู่ควรอยู่ใน repository ของ Source control เดียวกัน
แน่นอนว่ามีเครื่องมือมากมายให้ใช้งาน
เช่น Docker, Ansible, Chef, Packer และ Terraform เป็นต้น

ยกตัวอย่างเช่นการใช้งาน Docker
สามารถสร้าง infrastructure ที่เหมือนหรือคล้ายกันให้กับระบบได้เลย

หรือจะให้ดึงข้อมูลจากไฟล์ configuration ที่กำหนดก็ mapping volume ไปก็จบละ

อาจจะมีปัญหาเรื่องของความลับของข้อมูล

เนื่องจากทำการเก็บข้อมูลไว้ใน configuration และ environment variable
แต่ก็ไม่เป็นปัญหาอะไร เพราะว่ามีเครื่องมือให้ใช้เช่น

สุดท้ายแล้ว

การย้าย configuration ไปยัง environment variable
การย้าย configuration ต่าง ๆ ไปรวมไว้ที่เดียวกัน
มันไม่ได้ช่วยลดปัญหาเรื่อง การลืมได้ทั้งหมด
ดังนั้นเรื่องของ configuration นั้นขอให้มีน้อยที่สุด มีเท่าที่จำเป็นเท่านั้น
ดีที่สุดคือ ไม่มีนั่นเอง

ขอให้สนุกกับการ coding ครับ