continuousDelivery_big_None

วันที่ 19-20 กรกฏาคม 2557 นี้ จะมี course เกี่ยวกับ Continuous Integration และ Continuous Delivery
แบบเหมารำวงรอบที่ 2 ที่สำนัก SPRINT3R
ซึ่งผมเคยอธิบายเกี่ยวกับ แนวปฏิบัติ 10 ข้อของ Continuous Integration ไปแล้ว
ดังนั้น ในครั้งนี้ขออธิบายเกี่ยวกับ Continuous Delivery กันบ้าง ว่าเป็นอย่างไร

ข้อมูลต่างๆ นำมาจากหนังสือ Continuous Delivery

แนะนำว่าควรจะต้องอ่านเลย อธิบายว่าด้วยเรื่องความเป็นมาตั้งแต่ Continuous Integration
มายัง Continuous Delivery และ Continuous Deployment ว่ามันประสบความสำเร็จได้อย่างไร
โดยใช้สิ่งที่เรียกว่า Build pipeline
แต่ในปัจจุบันพูดไปถึง deployment pipeline และ delivery pipeline กันอีก

continuous_delivery

แต่พื้นฐานหลักๆ จะต้องเริ่มมาจาก Continuous Integration(CI) เสมอ ซึ่งเป็นหัวใจเลยก็ว่าได้
ส่วน Continuous Delivery (CD) เน้นเรื่องของการส่งมอบ feature มากกว่า CI
และ CD เข้าไปมีเกี่ยวข้องกับคนมากขึ้น ดังนั้นจะสนใจฝั่งลูกค้ามากขึ้น

สิ่งหนึ่งที่หลายๆ คนอาจจะยังไม่รู้คือ คำว่า Continous Delievery มันอยู่ในหลักปฏิบัติข้อที่ 1 ของ Agile เลยนะ
ดังนั้น มันไม่ใช่ของล้อเล่นอย่างแน่นอน

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software

ทำความรู้จักกับ Continous Delivery กันนิดนึง

เป็นแนวคิดอยู่บนพื้นฐานของคำว่า อัตโนมัติ หรือ Automation
เป็นขั้นตอนของการส่งมอบ software
ซึ่งต้องสามารถทำซ้ำได้ และต้องมีความน่าเชื่อถือด้วย

ดังนั้นจะมองว่าขั้นตอนอะไรก็ตามที่เป็นแบบ manual นั่นคือจุดที่เป็นคอขวด
ขั้นตอนจะเริ่มตั้งแต่ requirment จนไปถึงการ deploy software ขึ้น production กันเลยนะ

โดยที่เป้าหมายจริงของ Continuous Delivery คือ Working Software ที่ผู้ใช้สามารถใช้งานได้ทันที
เน้นย้ำว่า ถึง มือ ลูกค้า นะ
ไม่ถึงถึงมือทีม Tester, QA, Operation, Deployment นะ

เนื่องจาก Continuos Delivery นั้นต้องการส่งมอบ software ให้ถึงมือลูกค้าจริงๆ
เพื่อให้ลูกค้าลองใช้งาน และรอรับเสียงตอบรับจากผู้ใช้งานว่าเป็นอย่างไร ( feedback )
เพื่อนำมาแก้ไขและปรับปรุง ดังนั้น ยิ่ง feedback loop ใช้เวลาสั้นเท่าไร จะยิ่งดี

Screen Shot 2557-07-12 at 2.05.16 PM

โดยรวมแล้ว Continuous Delivery มันคือ

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

ดังนั้นจะไม่ได้เน้นเพียงคุณภาพของ code ที่พัฒนา software เท่านั้น
แต่ยังหมายรวมไปถึง คุณภาพของ requirement
และสะท้อนไปถึง คุณภาพของขั้นตอนในการส่งมอบ software อีกด้วย

ต่อจากนั้น เรามาดูเรื่อง Principle ของ Continuos Delivery กันบ้าง

ประกอบไปด้วย principle 8 ข้อ ดังนี้

1. The process for releasing/deploying software MUST be repeatable and reliable

ขั้นตอนในการ deploy และ release software นั้น จะต้องสามารถทำซ้ำได้ และต้องมีความน่าเชื่อถือ

2. Automate everything!

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

พยายามทำให้ขั้นตอนมันทำงานแบบอัตโนมัติได้ให้มากที่สุด
แต่ถ้าอะไรที่ทำไม่ได้จริงๆ ก็ไม่ต้องไปพยายามมากนัก มันเปลือง และอาจจะไร้ค่า

3. If somethings difficult or painful, do it more often

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

ตัวอย่างที่เห็นได้บ่อยๆ ก็คือ การ deploy schema ของ database บน production
แน่นอนว่าไม่อนุญาตให้ทำการ deploy บ่อยๆ หรอกนะ
บางทีอาจจะเป็นเดือนละครั้งก็ได้ ซึ่งอาจจะคิดว่ามันดีแล้วหรอ ?
ลองเข้าไปศึกษา ทำความรู้จักมันว่า ทำไมต้องเดือนละครั้ง มันนานเกินไปไหม
เมื่อเราเข้าใจมันแล้ว ลองทำให้มันบ่อยขึ้น เช่น
สัปดาห์ละครั้ง วันละครั้ง แล้วดูว่าคุณได้อะไรที่ดีกว่าเดิมไหม

4. Keep everything in source control

ผมคิดว่า principle ข้อนี้ อาจจะดูล้าหลังไปแล้วนะ คุณว่าไหม ?

ใครบ้างที่ไม่เก็บสิ่งต่างๆ ในการพัฒนา software ไว้ใน Source control บ้างล่ะ !!
ไม่น่าจะมีแล้วนะเออ…

5. Done means “released”

มันหมายถึงว่า ทีมพัฒนา ต้องมีความเป็นเจ้าของตั้งแต่เริ่มการพัฒนา จน software ไปถึงมือผู้ใช้งาน
ดังนั้น งานจะไม่เสร็จเมื่อคุณทำการ commit code ขึ้น Source control นะ
แต่ต้องดำเนินการทุกๆ อย่างจน software ไปถึงมือลูกค้าจริงๆ

6. Build quality in!

ในการพัฒนา software เรื่องของคุณภาพไม่สามารถต่อรองได้เลย
ดังนั้นในการพัฒนาที่ดี ควรมีการกำหนด metric ของคำว่าคุณภาพขึ้นมา เช่น

  • Test coverage
  • Coding style
  • กฏเรื่องความปลอดภัย
  • การวัดเรื่องความซับซ้อนของระบบ
  • และอื่นๆ อีกมากมาย ทีมลองคุยกันดูนะ

โดยเรื่องต่างๆ เหล่านี้มันจะช่วยทำให้ software ที่สร้างมีคุณภาพ
และการทำงานควรเป็นแบบอัตโนมัติด้วยนะ
ถ้ายังทำแบบ manual คงจะเป็นเส้นทางที่ไม่ถูกต้องเท่าไรนัก

7. Everybody has responsibility for the release process

ถ้าบอกว่า software ที่พัฒนามานั้นมันทำงานบนเครื่องฉันได้
นั้นไม่ได้บอกว่าทีมหรือบริษัทเราจะได้เงินนะ

มันจะต้องมีการกำหนดว่า software ที่พร้อมจะปล่อยหรือ deploy ออกไปนั้นควรอยู่ที่ไหน
เพื่อพร้อมส่งให้ผู้ใช้งาน ซึ่งมันจะทำให้คุณได้เงินมานะ

ดังนั้นทุกๆ คนควรมีส่วนร่วมในการรับผิดชอบในเรื่องการส่งมอบ software ให้ลูกค้า
ไม่ใช่เพียงใครคนใดคนหนึ่ง หรือกลุ่มใดกลุ่มหนึ่ง

เคยไหมที่ต้องอยู่ตั้งแต่เที่ยงคืนจนถึงเช้าเพียงลำพัง …

8. Improve continuously

อย่าหยุดการปรับปรุงตัวเอง ทีม รวมไปถึง software ที่สร้าง
อย่ารอให้ล้าหลัง
พยายามทำให้ software ที่สร้าง หรือ กำลังสร้าง นั้นง่ายต่อการดูแลรักษา
พยายามปรับเปลี่ยนให้มันดีขึ้นเรื่อยๆ อย่าหยุดนิ่ง

อะไรที่มันเจ็บๆ ทำมันบ่อยๆ ครับ

ยังไม่พอนะ จาก Principle 8 ข้อ แล้ว Continuous Delivery ยังมี Practice อีก 4 ข้อ ดังนี้

1. Build binary only once

ในแต่ละเวอร์ชันของ software ควรมี binary ที่ผ่านการ compile และ package แล้วเพียง 1 ตัวเท่านั้น
ไม่เช่นนั้น จะต้องทำการ compile และ package มันทุกๆ environment
ส่งผลให้เกิดความผิดพลาดสูงมาก ( ถ้าภาษาไหนไม่ต้อง compile และ package ก่อนติดตั้งก็ผ่านไปนะ )

สิ่งที่ได้จากการ compile และ package คือ Binary package
ซึ่งต้องสามารถเข้าถึงได้จากกระบวนการ deployment ด้วยเสมอ
และการ deploy ในทุกๆ environment จะใช้ Binary package ตัวเดียวกันเสมอ

2. Use precisely the same mechanism to deploy to every environment

พยายามใช้วิธีการ deploy เดียวกันในทุกๆ environment
ลองคิดดูว่าถ้า Development server, Test server และ Staging server
ทำการ deploy แบบอัตโนมัติ แล้ว production ยังต้องมา deploy แบบ manual
มันดูไม่น่าจะเป็นวิธีการที่ดีนัก เปลี่ยนมาใช้ one click deployment น่าจะดีกว่า

3. Smoke test your deployment

ทำการตรวจสอบผลจากการ deploy ในทุกๆ ขั้นตอนเท่าที่จะเป็นไปได้
เช่น การตรวจสอบขนาดไฟล์ เป็นต้น
เพื่อทำให้รู้ปัญหาการ deploy ได้อย่างรวดเร็ว จะได้หาทางแก้ไขได้รวดเร็วขึ้นด้วย

4. If anything fails, stop the line!

นี่คือ กฎเหล็ก ของ Continuous Delivery เลย
คือ ถ้าเกิดข้อผิดพลาดขึ้นมา ให้หยุดการ deploy ทันที
ไม่มีการ fixed bug ไม่มีการ patch ไม่มีการ hack
หรือทำการแก้ไขหน้างาน ใดๆ ทั้งสิ้น

แต่ให้ทำการแก้ไข source code ใหม่ เพื่อทำให้ทุกอย่างพร้อม
แล้ว commit ขึ้น Source control จึงจะเข้าสู่กระบวนการ deploy ใหม่

ในข้อนี้หลายๆ คนบอกว่า มันเป็นไปไม่ได้หรอกนะ !!
ลองทำดูไหมล่ะ ว่าจริงๆ มันทำได้
คนเรามักใช้เหตุผลทางอารมณ์ มากกว่าเชิงเหตุผลนะ

ลองมองย้อนกลับไปดูว่า ปัจจุบันคุณ deploy งานอยู่กับใคร
กับทุกๆ คนที่เกี่ยวข้องกับการพัฒนา ตั้งแต่ requirement ยันการ deployment ไหม
ที่มากันไม่ครบ เพราะว่า ต้อง deploy กันดึกดื่น เพราะว่า คนใช้งานน้อยสุดๆ
ถ้าไม่ครบลองกลับไปดู prinnciple ข้อ 7 ดูนะ

ทางแก้ไขง่าย ก็ deploy ในช่วงที่ทุกๆ คนว่างพร้อมกันหมดนะ
แล้วคุณจะรู้ว่าการทำงานเป็นทีมเป็นอย่างไร
และ Continuous Delivery จริงๆ เป็นอย่างไร
…. มันคือ สิ่งที่ขัดแย้งกับ common sense อย่างแรงส์นะเออ ….
ดังนั้น ถ้าจะใช้มันแล้ว กรุณาใช้ให้ถูกนะครับ
อย่าเอาเพียงแค่เป็นคำเท่ๆ ไปใช้เท่านั้นนะ

สุดท้าย
อย่าลืมว่า ลูกค้าต้องการ Working Software ไม่ใช่วิธีการขั้นตอนที่เลิศหรูนะ