จากตอนนี้ไปจะพูดถึงรายละเอียดทางเทคนิคมากขึ้น เริ่มด้วยทางแรก “The technical practices of flow” จุดประสงค์ของเรื่องนี้คือ การที่จะมี flow จาก Dev ไป Ops ที่งานได้เร็ว ไม่ก่อให้เกิดปัญหาและไม่ทำให้ระบบสะดุด โดยทำให้เกิดได้ด้วย technical practices ชุดนึงที่เรียกว่า “Continuous delivery” ซึ่งเราจะพูดถึงตามหัวข้อดังนี้
- Creating the foundation of our deployment pipeline
- Enabling fast and reliable automated testing
- Enabling and practicing continuous integration and testing
- Automating, enabling, and architecting for low-risk release
Creating the foundation of our deployment pipeline
เตรียมโครงสร้างพื้นฐานของการ deployment flow ซึ่งตามหลักที่เคยพูดถึงก่อนหน้านี้คือ เราควรมี production-like environment ในทุก stage ซึ่งในข้อนี้จะเน้นว่ามันต้องทำได้โดย “อัตโนมัติ” และ “ในทันที” ที่ต้องการโดยการมี scripts, configuration ซึ่งทำ version control ไว้ดีแล้วและพร้อมที่จะให้บริการแบบ self-service
ปัญหาทั่วไปของการที่ traditional IT มักไม่มี production-like environment นอกจากเรื่องเงินแล้ว คือมันใช้เวลาสร้างนาน และก็ต้องมีซัก config นึงสิน่าที่ Dev กับ Prod มันไม่ตรงกัน ถ้าพูดให้เห็นภาพคือ server บางตัวนี่ก็อยู่มานานกว่าอายุงานเราอีก ผ่านมือคนมาไม่รู้กี่คน config ก็มีได้เป็นร้อยๆจุด เราก็ไม่รู้หรอกว่า config ที่เกี่ยวข้องจริงๆมีอะไรบ้าง จะดูเอกสารก็ไม่แน่ใจว่าคนทำ update กันได้ครบ 100% มั้ย
โค้ด..โค้ด..แล้วก็โค้ด
ในแนวคิดนี้ config ทุกอย่างมันต้องเป็น code แปลว่า แม้แต่ฝั่ง Ops ที่พวกนายแอดมินเคย automate แค่บางส่วน เช่น จะสร้าง vm เราก็มี template แหละแต่มักจะ config ต่อด้วยมือ มันจะต้องเปลี่ยนมาทำเป็น code ทั้งหมด เพื่อให้นายสามารถสร้างเครื่องนี้เหมือนเป๊ะอีกครั้งได้ในพริบตา และ code นี่เองก็จะถูกเก็บไว้ในฐานะ config doc ด้วย (ดีใจอ่ะดิ ไม่ต้องตามแก้เอกสารด้วย)
นอกจากนี้เรายังสามารถสร้าง env ขึ้นมาใหม่ได้อย่างมี consistency และลด error จากการ manual ถ้าสนใจไปหาอ่านต่อเรื่อง Infrastructure as Code (IaC) กันได้นาจา ส่วน tools ที่จะเข้ามามีบทบาทสำคัญเลยก็คือกลุ่ม config mgmt tools เช่น Chef, Ansible, Salt, etc.
Repository และ version control
ก็เป็นอีกสิ่งหนึ่งที่สำคัญและต้องมี คือไม่ใช่มี script อย่างดีแล้วเก็บไว้ที่ตัวเอง และ save ทับกันไปเรื่อยเปื่อย ซึ่งเค้าแนะนำว่า repository นี้ ก็ควรเป็นที่เก็บเดียวกับ code ของ app นั่นแหละ
Immutable Infrastructure
คือแนวคิดว่าเราจะเป็น infra แบบที่จะไม่ให้มีการทำ manual change ค่านู่นนี่ต่างๆใน production เฮ้ย.. แล้วเวลาต้องไปแก้ config จะทำยังไง พวกนายก็ไปแก้ config script แล้วสร้างเครื่องใหม่ไปใช้แทนได้เลยฮะ เครื่องเก่าก็ทิ้งไปอย่าไปแก้มัน ด้วยกระบวนการนี้จะทำให้เรามั่นใจว่าเราสร้าง Env ใหม่ได้เหมือนเดิมเสมอ
Enabling fast and reliable automated testing
ในการทำ DevOps จะให้ความสำคัญกับ “Automated Test” มากๆๆๆๆ เพราะถ้าเรายิ่งแก้ code บ่อย เราก็ต้องยิ่ง test บ่อยไปด้วย ถ้าเราจะ test แบบ manual ให้ครบถ้วน เราจะมีงานมหาศาล
เป้าหมาย คือ เราจะต้องสร้างงานให้มีคุณภาพ ตั้งแต่ต้น เจอปัญหาแล้วตัดไฟแต่ต้นลม ไม่ให้มีปัญหากับคนอื่นๆ หลักคือพวกนี้ต้อง build บ่อย integrate บ่อย test บ่อย มีหลักการนึงเสนอว่าให้ deployment pipeline กำหนดเลยว่าทุกๆ code ที่ checkin เข้าไป จะต้อง automated build และ test ใน production-like env ในการนี้เราก็จะพบ error ในการ build, integrate ได้อย่างรวดเร็ว
ซึ่ง test ก็แบ่งได้หลายประเภท โดยหลักคือเราควรจับปัญหาส่วนมากให้ได้ใน unit test เค้าก็มีหลักเรื่อง test pyramid ตามรูปนี้คือ test ส่วนย่อยให้เยอะ จับให้เจอตั้งแต่ unit test นี่แหละ ส่วนอื่นก็ลดหลั่นไป และ manual test ต้องเหลือน้อยมาก
เรื่องอื่นๆเกี่ยวกับการ test
- ทำ Test ให้เร็วเข้าไว้ ถ้ามันมีเยอะก็ทำ parallel เสียบ้าง อย่าไปทำทีละหนึ่ง
- Test-Driven Development (TDD) อันนี้เป็นแนวคิดแบบ ให้ทำ automated test ให้เสร็จก่อนเลย แล้วค่อย develop code ตาม
- รวม Performance testing และ Non-functional requirement ให้อยู่ใน test suite ด้วย ไม่ว่าจะเป็นการทดสอบ availability, scability, security ที่เราต้องการใน production คือ เขียนเสร็จก็ scan security ทดสอบ performance และทดสอบ cluster ไปด้วยเลย
- ดึง Andon Cord เมื่อ deployment pipeline break คือ เราต้องรักษาให้เรามี code ที่ทุกคนไว้ใจว่ามันทำงานได้อย่างปลอดภัย (green build) ถ้าเกิดมีปัญหาขึ้นมาคือต้องรีบแก้ ถ้าไม่ได้ก็ต้อง rollback กลับมาก่อน แล้วค่อยว่ากัน อย่าให้เลยเถิด
Enabling and practicing continuous integration and testing
คือ ปัญหาของชาว Dev อย่างนึงคือเวลาเขียน code กันหลายคนแล้วต้องมารวมกัน (integrate) นี่ code มันกระทบกันได้ คือ code เรารันได้ แต่ดันพาลทำของเพื่อนพัง ทีนี้ถ้าทิ้งไว้นานๆทีค่อยมารวม เราแก้ไรไปมั่ง เพื่อนแก้ไปไรไปมั่งก็ไม่รู้ละ ต้องมานั่งหาอีก เราเลยต้องรวมบ่อยๆ เค้าก็มี practice ที่เรียกว่า continuous integration ซึ่งจะต้องมี 3 อย่างนี้
- มี Automated test ที่เชื่อถือได้และครอบคลุม
- มีวิถีทำงานที่ต้องหยุดแล้วแก้ ถ้า test fail (คือหลัก Andon cord อ่ะแหละ)
- Developer ทำงานเป็น small batches on trunk ไม่ใช่ long-lived feature branches อันนี้คือ เวลาทำงาน Dev นี่มันจะมี code เริ่มต้น เปรียบเหมือนลำต้นหรือ trunk (หรือเรียกว่า master) แล้วใครจะแก้อะไรก็จะแตกกิ่ง ที่เรียกว่า branch เพื่อคัดลอก code นั้นไปแก้ แล้วค่อยเอากลับมารวม (merge) กลับใน trunk อีกครั้ง เค้าก็แนะนำว่าไม่ใช่แตกกิ่งแล้วก็ไปยาวๆเลยนะจ๊ะ แตกไปแล้วก็หมั่นเอากลับมารวมกับเพื่อนฝูงกลับมาเป็น trunk เสมอๆ
เค้าแนะนำว่าควรทำ “Trunk-based development” ที่มีข้อแนะนำว่าเราควร check in code มาที่ trunk บ่อยๆ(อย่างน้อยวันละครั้ง)และก่อนเข้าก้อควรมี gated commits ที่มีการตรวจสอบว่า code นี้ผ่าน automate test และมีผล pass การที่เรา commit code บ่อยๆก็จะ force ให้เราแบ่งงานเป็นชิ้นเล็กๆและแน่ใจว่าตัว code หลักทำงานได้โดยไม่มีปัญหา
โดยสรุปคือ ทำทุกอย่างให้เป็นโค้ด ให้ทำซ้ำได้บ่อย เขียนโปรแกรมทีละน้อย รวมงานกันถี่ๆ ทดสอบในทุกขั้นตลอดกระบวนการ ถ้าผิดให้หยุดแล้วแก้ทันที ก็เท่านี้แหละฮะ
Note: อันนี้เป็นสรุปจากการอ่านหนังสือ DevOps Handbook อาจมีผิดถูกบ้าง + มีคหสตบ้างเล็กน้อย ถ้าสนใจไปซื้อหาอ่านเล่มจริงกันต่อได้
ติดตามตอนอื่นๆ
