Tag Archives: Continuous delivery

Martin Fowler at Singapore, June 2012

เมื่อวันพฤหัสฯ ที่ผ่านมา ThoughtWorks ได้ทำการประกาศตัวว่าเปิดสาขาที่ Singapore แล้ว ด้วยการนำ Martin Fowler Chieft Architecture Scientist ผู้ที่มีชื่อเสียงมากที่สุดคนหนึี่งในด้าน Agile มาพูดให้ฟัง งานแบบนี้ส่วนตัวก็ไม่พลาดไปติดตามแน่นอน และยังได้พบพี่ๆจากไทย ทั้งพี่แป๋ม พี่จั๊วและพี่เก๋ ที่สองคนหลังเค้าบินมาเพื่องานนี้โดยเฉพาะ!!

การพูดของเค้าครั้งนี้ แบ่งออกเป็น 3 เรื่อง ซึ่งล้วนแล้วแต่เป็นเรื่องที่เค้าได้เขียนลง blog ของเค้าแล้วทั้งนั้น ใครติดตาม blog เค้าอยู่เป็นประจำคงเคยได้อ่านผ่านตามาบ้าง แต่กับการที่เค้ามาอธิบายให้ฟังก็ทำให้เข้าใจและจับประเด็นสำคัญได้ดีมากขึ้นอยู่เหมือนกัน

เริ่มด้วยเรื่อง NoSQL DATA MODELS

เค้ากำลังเขียนหนังสือที่มีชื่อว่า NoSQL Distilled อยู่ เลยได้ดึงเนื้อหาบางส่วนออกมาพูดให้ฟัง

  • เค้าเรียกการรวมกันของ NoSQL ประเภท Key-Value และ Document Store ว่า Aggregate-Oriented Database ประเด็นของมันคือการเก็บกลุ่มของข้อมูลที่ได้ทำการ denormalize แล้วนั่นเอง ทำให้ถ้าเราเข้าถึงกลุ่มของข้อมูลนั้นผ่าน key ปกติจะทำได้เร็วและถูกกว่า relational database แต่เมื่อไหร่ที่เราต้องการเข้าถึงข้อมูลใน pattern อื่นก็จะทำได้แย่กว่า relational database
  • (จากรูป) งานที่เหมาะมากๆ กับ NoSQL คือ custom fields และ non-uniform data แต่เรื่อง migration ที่หลายคนพูดว่าเป็นข้อดีหนึ่งของ NoSQL นั้น เค้าไม่เห็นด้วย เค้ามองว่าในการเก็บข้อมูลเราก็จะมีการคิดถึงรูปแบบในการจัดข้อมูลซึ่งหมายถึงมี implicit schema อยู่ดี

เรื่องต่อมาคือเรื่อง 2 Kinds of software projects

  • เค้าจัดกลุ่มการพัฒนาซอฟแวร์บนโลกนี้ออกเป็น 2 กลุ่ม คือ strategic software และ utility software
  • Strategic software (S) คือ software ที่สร้างข้อได้เปรียบในเชิงการแข่งขันทางธุรกิจ
  • Utility software (U) คือ software ที่นำมาใช้ช่วยการดำเนินธุรกิจ
  • เป้าหมายของ S คือ innovation และ speed, เป้าหมายของ U คือ ถูก
  • S ควรทำเอง, U ควรซื้อสำเร็จ
  • ความเสี่ยงของ U คือการทำพลาด, ความเสี่ยงของ S คือการไม่ทำ

เรื่องสุดท้ายคือ Continuous Integration และ Continuous Delivery

  • Source code version control ในปัจจุบันยังทำได้แค่การ merge text แต่ยังมีการ merge sematic ที่ทำไม่ได้ หากนึกตัวอย่างไม่ออกลองนึกถึงสถานการณ์ ที่เพื่อนร่วมทีมของเราเปลี่ยนการทำงานของ method ที่เราเรียกใช้อยู่ซึ่งทำให้ผลลัพธ์ของ method นั้นเปลี่ยนไปจากตอนที่เราเขียนโปรแกรมเรียกใช้มัน
  • สิ่งที่พอจะทำให้เราตรวจสอบ sematic merge ได้มีแค่ test เท่านั้น
  • พอการ merge มันสร้างความลำบากทำให้เราไม่อยาก merge กันเท่าไหร่ เลยหนีไปทำ feature branch กัน
  • แต่ feature branch ก็ยังไม่ช่วยให้การ merge มันง่ายขึ้น การแก้ปัญหานี้ที่ถูกต้อง คือควรจะ merge กันบ่อยๆ จากรูปจะเห็นว่าเค้าจำลองเหตุการณ์ของการแก้ไขที่ไม่ตรงกันของ 2 developer ด้วยลูกศร และจุดที่เราพบว่าการแก้ไขของคนสองคนขัดกันด้วยจุดแดง จะเห็นว่าถ้ารวม code กันบ่อยๆ ก็จะเจอจุดบกพร่องเร็วกว่าการแตก branch มาก
  • การรวม code กันบ่อยๆ นั่นคือแนวคิดที่เป็นหัวใจของ Continuous Integration นั่นเอง
  • ส่วน Continuous delivery คือ กระบวนการการนำซอฟแวร์จากจุดที่ dev commit ไปอยู่ในจุดที่พร้อมจะ release แบบอัตโนมัติ เหลือไว้เพียงแค่การกดปุ่ม release จากการเห็นชอบของฝ่าย business เท่านั้น
  • วิธีที่ใช้ในการทำให้เกิด Continuous delivery คือ deployment pipeline คือสร้างลำดับการรัน test หลายๆ ขั้นขึ้นมา เนื่องจาก test แต่ละระดับมีความเร็วช้าและความครอบคลุมต่างกัน จึงวางกลุ่ม test ที่รันได้เร็ว (จากการที่ตัด dependency ออก) ไว้ก่อน เพื่อให้สร้าง feedback ได้เร็วที่สุด หากผ่านชั้นที่เร็วไปได้ ก็ไปสู่ในชั้นที่ test ระหว่างส่วนมากขึ้น แต่รันได้ช้าลงต่อไป
  • ไม่ควร compile code ใหม่ระหว่างขั้น เพื่อลดความผิดพลาดในการ test จากความแตกต่างของสภาพแวดล้อมที่ใช้ในการ test
  • พี่จั๊วถามคำถามด้วยว่า ถ้าไปเจอปัญหาใน test ขั้นหลังๆ ควรทำอย่างไร เค้าก็ตอบว่าให้ไปเพิ่ม unit test ที่ครอบคลุมมากขึ้น
Advertisements