จากบทความเรื่อง Visualizations of Continuous Delivery
เป็นบทความอธิบายเรื่อง Continuous Delivery ด้วยภาพ
ซึ่งทำให้เข้าใจง่ายขึ้น แต่ถ้าใครไม่เคยศึกษามาอาจจะธาตุไฟเข้าแทรกได้
เนื่องจากไม่รู้จะเริ่มจากตรงไหน
ดังนั้น ผมจึงลองตัดในแต่ละส่วนมาอธิบาย
เพื่อให้ตัวผมเข้าใจมากยิ่งขึ้น

บทความแบ่งออกเป็น 4 ภาพ ประกอบไปด้วย

1. อธิบายเรื่อง Continuous Delivery
2. อธิบายเรื่องการทดสอบ
3. อธิบายเรื่อง Automated Acceptance Test
4. อธิบายเรื่องการจัดการข้อมูล

เริ่มที่เรื่องแรกกันก่อน คือ Continuous Delivery

Screen Shot 2557-06-06 at 11.07.33 PM

ประโยคแรกสำคัญมากๆ มันคือหัวใจของการส่งมอบ software

A Principle of Software Delivery :: Build Quality In

แปลง่ายๆ ก็คือ งานที่ส่งต้องมีคุณภาพสูง
คุณภาพเป็นเรื่องที่ต่อรองไม่ได้เลย

ต่อมาอธิบายความหมายของ Continuous Delivery

Screen Shot 2557-06-06 at 11.08.54 PM

จากภาพจะเน้นให้เห็นว่า Continuous Delivery นั้น
คนที่จะตัดสินใจว่าจะปล่อยของออกไปให้ลูกค้าใช้งานนั้นคือ คนฝั่ง business นะ
จะแตกต่างกับ Continuous Deployment ที่เมื่อทุกอย่างผ่านหมด
หรือการทำงานเสร็จจริงๆ หรือ Done จะปล่อยของไปให้ลูกค้าทันที

แต่สิ่งที่ทั้งสองเหมือนกันคือ ของที่เสร็จ หมายความว่าสามารถปล่อยออกไปให้ลูกค้าใช้งานได้ทันที
ดังนั้นให้เข้าใจตรงกันว่า เสร็จ คืออะไร …

จากนั้นคือเรื่องของ Deployment pipeline

Screen Shot 2557-06-06 at 11.17.57 PM

เป็นเรื่องสำคัญมากเช่นกัน เนื่องจากก่อนที่จะสร้างระบบ Continuous Delivery ขึ้นมา
ต้องกำหนด deployment pipeline หรือ ขั้นตอนต่างๆ ของการทำงาน
เพื่อทำให้มั่นใจว่าสิ่งที่กำลังสร้างขึ้นมีคุณภาพและตรงตามความต้องการ
จากตัวอย่างนี้ ประกอบไปด้วย  5 ขั้นตอนคือ

  1. Commit stage
  2. Automated Acceptance Testing
  3. Automated Capacity  Testing
  4. Manual Testing
  5. Release

การเรียงลำดับของแต่ละขั้นตอน เป็นไปตามนี้

  • การทำงานจากเร็วไปช้า
  • ต้องแสดงจุดที่หยุดการทำงาน เมื่อเกิดข้อผิดพลาดขึ้น โดยข้อแรกๆ ชัดเจนมาก
  • Environment ที่เหมือนกับ production server ซึ่งจะเริ่มจากน้อยไปมาก

หัวใจของ Deployment pipeline คือ การทำงานที่รวดเร็ว และถูกต้องอยู่เสมอ

มาดูแต่ละขั้นตอนใน Deployment pipeline กัน

1. Commit stage

Screen Shot 2557-06-06 at 11.23.43 PM

ขั้นตอนนี้ เกิดขึ้นเมื่อทีมพัฒนาทำการ commit code
หรือทำการพัฒนา feature บางอย่างเสร็จ ซึ่งคำว่าเสร็จก็คือ

  • ต้องมั่นใจว่า code นั้นทำงานได้  syntax ผ่าน และ compile ผ่านทั้งหมด
  • อย่าลืมว่า unit test ทั้งหมดต้องผ่านด้วยนะ
  • ยังไม่พอต้องมีการตรวจสอบ code โดยใช้พวก metric ต่างๆ ด้วย เช่น code coverage, static code analysis ต่างๆ

ขั้นตอนนี้จะต้องทำงานเร็วมากๆ
เนื่องจากยิ่งทำงานช้าแล้ว feedback ที่ได้จะยิ่งช้ามาก
ส่งผลให้การแก้ไข ช้าตามไปอีก

2. Automated Acceptance Testing

เป้าหมายสำหรับขั้นตอนนี้คือ
เพื่อทำให้เห็นว่า ระบบงานสามารถทำงานได้ตามความต้องการของลูกค้าจริงๆ
ไม่ใช่ทำงานตามสิ่งที่ทีมพัฒนาคิด เช่น unit test หรือพวก metric ต่างๆ

Screen Shot 2557-06-06 at 11.40.00 PM

ในขั้นตอนนี้สิ่งที่ต้องสนใจมากๆ คือเรื่อง performance หรือประสิทธิภาพการทำงาน
ยิ่งรู้ว่ามันผิดพลาดเร็วเท่าไรยิ่งดี
เนื่องจากการทดสอบนี้ จะใช้เวลาทำงานที่นานมาก
แต่มีวิธีแนะนำเพื่อเพิ่มประสิทธิภาพการทำงาน ดังนี้

  • ทำการ refactor test
  • Parallell testing
  • ใช้พวก Cloud และ Grid computing มาช่วยในการทำงาน
  • เครื่องที่ใช้ทดสอบ ควรที่จะสร้างหรือ config ใหม่ขึ้นมาทุกครั้ง และทำลายเมื่อทดสอบเสร็จ

ประเด็นต่อมา คือ ใครละ ที่สร้าง Automated Acceptance Testing ?

Screen Shot 2557-06-06 at 11.56.43 PM

คำตอบคือ ทั้ง Analyst, Developer และ Tester จะต้องทำงานร่วมกัน

  • เพื่อให้เกิด transparency
  • เพื่อให้เกิดข้อสรุปร่วมกัน
  • เพื่อแบ่งปันความรู้ซึ่งกันและกัน

ดังนั้นในแต่ละตำแหน่งสามารถทำงานได้มากกว่า 1 อย่าง
ตัวอย่างการทำงาน เช่น

  • Tester กับ Developer สามารถออกแบบการทดสอบร่วมกัน
  • Analyst สามารถอธิบาย requirement และพวกเงื่อนไขต่างๆ ทางธุรกิจ เพื่อสร้าง criteria ต่างๆ จากมุมมองของ tester และ developer

การสร้าง Acceptance test มีขั้นตอนดังนี้

Screen Shot 2557-06-07 at 12.04.50 AM

  1. สร้าง acceptance criteria มาในรูปแบบที่เราตกลงกัน เช่น BDD style เป็นต้น
  2. ทำการลงมือเขียน code เพื่อสร้าง acceptance test โดยไม่ควรผูกมัดกับ UI ของระบบที่จะทดสอบ
  3. Application Driver Layer คือส่วนจะจะติดต่อสื่อสารกับระบบที่จะทดสอบ

เพื่อทำงานตามที่ได้สร้างไว้ และส่งผลการทำงานกลับมา

ปัญหาใหญ่ ที่มักพบเจอในการทำ Automated Acceptance Testing คือ การทดสอบกับ External system หรือระบบที่อยู่นอกเหนือการควบคุมของเรา

Screen Shot 2557-06-07 at 12.06.21 AM

เพราะว่า เราอาจจะมีจำนวน test case ที่น้อย และไม่ครอบคลุมปัญหาทั้งหมด
แต่เราควรที่จะหาไปเรื่อยๆ ว่ามีกรณีอะไรบ้าง ให้ได้มากที่สุด
แน่นอนว่า ไม่มีวิธีการใดที่จะ perfect ไปหมด หรือครอบคลุมทั้งหมด
เนื่องจากบางกรณีก็ไม่สามารถทำได้จริงๆ
ดังนั้นต้องชั่งน้ำหนักให้ดีว่าระหว่าง ความพยายามสร้างขึ้นมา กับ ประโยชน์ที่ได้รับ
ว่าอะไรที่คุ้มกว่ากัน ถ้าไม่คุ้มก็อย่าทำ แค่นั้นเอง

3. Automated Capacity Testing
ทำการทดสอบเรื่อง performance test ว่าระบบยังสามารถรองรับ
ผู้ใช้งานที่สูงขึ้น จำนวนข้อมูลที่สูงขึ้น
เพื่อทำให้มั่นใจว่าระบบยังสามารถทำงานได้ถูกต้อง
หรือทำให้รู้ว่าระบบจะต้องทำการแก้ไข หรือ ขยาย เมื่อไร

4. Manual Testing
ในขั้นตอนนี้ ก็เข้าสู่กระบวนการทดสอบปกติ เพื่อทำให้มั่นใจว่าระบบทำงานถูกต้อง
โดยการทดสอบจะมีรูปแบบที่แตกต่างออกไป หรือที่เรียกว่า Exploratory Testing

ย้อนกลับมาเรื่องของแนวทางการทดสอบบ้าง

Screen Shot 2557-06-07 at 12.19.31 AM

อย่างแรกที่ต้องทำความเข้าใจตรงกัน ก็คือ testing มันคือ crossfunctional activity
เป็นกิจกรรมที่ไม่ทำเฉพาะ tester ฝ่ายเดียวนะ  ( ไม่ใช่ phase นะ )
แต่ทำกันทั้งทีมพัฒนา ตั้งแต่ business ถึงการติดตั้งระบบงาน และดูแลหลังการติดตั้ง
และทำกันอย่างต่อเนื่องตั้งแต่เริ่มต้น ไม่ใช่มาทำตอนปลายๆ เหมือนปัจจุบันที่ทำกันอยู่ !!

ถ้ายังให้การทดสอบระบบงาน อยู่ท้ายๆ นะ จะเกิดปัญหาดังรูป 
คิดว่าเป็นรูปที่คุ้นเคยกันนะ

Screen Shot 2557-06-07 at 12.24.02 AM

มาดูเรื่องชนิดของการทดสอบบ้าง โดยยึดตาม Agile Testing ดังรูป

Screen Shot 2557-06-07 at 12.25.43 AM

แบ่งออกเป็น 4 ส่วน คือ
1. ต้องทำงานแบบ Automated ทั้งหมด ประกอบไปด้วย

  • Unit test
  • Integration
  • Component
  • System test
  • Deployment test

2. ต้องทำงานแบบ Automated ให้มากที่สุด  ประกอบไปด้วย

  • Functional test
  • Acceptance test

3. ทำงานแบบ Manual ประกอบไปด้วย

  • Usability test
  • Exploratory test

4. ทำงานทั้ง Automated และ Manual ประกอบไปด้วย

  • Non-functional acceptance test
  • Performance test
  • Capacity test
  • Security test

เรื่อง regression test นั้นไม่มี เพราะว่า ไม่สามารถระบุลงไปได้ว่าจะอยู่ส่วนไหนได้
เนื่องจากมันเกี่ยวข้องมากกว่า 1 ส่วนนั่นเอง

มีข้อย้ำเตือนว่า ใน Deployment pipeline จะต้องมีชนิดการทดสอบครบทุกๆส่วนด้วยนะ อย่าลืม

สิ่งที่เกี่ยวข้องกับการทดสอบ คือ การจัดการข้อมูลต่างๆ ในระบบ

Screen Shot 2557-06-07 at 1.05.46 AM

การทำงานแบบ Automated แบบเต็มๆ นั้น
ต้องมีเรื่องของ การสร้าง และ ย้ายข้อมูลในฐานข้อมูล แบบอัตโนมัติด้วย

การจัดการข้อมูล สำหรับการทดสอบ มี 2 เรื่องต้องคำนึงถึง คือ

  1. Performance
  2. Isolation

1. Performance ในการทดสอบ จะต้องทำงานได้รวดเร็ว
ส่วนใหญ่ การทดสอบจะไม่ใช้ข้อมูลฐานข้อมูลจริงๆ
ซึ่งอาจจะใช้ memory database
เพื่อประโยชน์ในการทดสอบที่รวดเร็ว
และสนใจเฉพาะส่วนของ business ของระบบงานนั้นๆ

2.  Isolation คือการจัดการไม่ให้ การทดสอบ และ ข้อมูล ผูกติดกันมากจนเกินไป

แบ่งออกเป็น 3 แบบ ดังรูป

Screen Shot 2557-06-07 at 1.10.03 AM

 

  1. Test isolation แต่ละการทดสอบจะเห้นเฉพาะข้อมูลของตัวเองเท่านั้น
  2. Adaptive test แต่ละการทดสอบถูกออกแบบเพื่อให้ปรับพฤติกรรมเข้ากับ environment อย่างเหมาะสม
  3. Test sequencing แต่ละการทดสอบต้องทำการตามลำดับ ตามลำดับของ input และ output ที่ต้องการ


การจัดการข้อมูลสำหรับการทดสอบ จะทำในทุกขั้นตอนของ Deployment pipeline เนื่องจากมีความต้องการต่างกัน

Screen Shot 2557-06-07 at 1.10.58 AM

อธิบายมากันซะเยอะ แล้วประโยชน์ของ Continuous Delivery  ล่ะมีอะไรบ้าง

Screen Shot 2557-06-07 at 1.13.01 AM

 

  • ทุกๆ คนในทีม สามารถควบคุมการทำงานเองได้ หรือมีอิสระการทำงานมากขึ้น (แต่มีขอบเขตนะ)
  • ลดความเคร่งเครียด เนื่องจาก เราสามารถทำการปล่อยของครั้งละเล็กๆ และบ่อยๆ ( แล้วทาง business ชอบไหมนะ )
  • ลดจำนวนความผิดพลาด เนื่องจากมีส่วนการจัดการ configuration และใช้งาน version control เพื่อจัดการข้อมูลในส่วนต่างๆ
  • การ deploy ระบบงาน ทำได้ง่าย
  • มีการปรับปรุงวิธีการทำงานตลอดเวลา ทำให้ระบบงานของเราเข้าใกล้คำว่า perfect ไปเรื่อยๆ

สุดท้าย คือ ส่วนที่สำคัญมากๆ ของ Continuous Delivery คือ

Screen Shot 2557-06-07 at 1.19.48 AM

หวังว่าน่าจะทำให้ เข้าใจกับคำว่า Continuous Delivery มากยิ่งขึ้นครับ