Quantcast
Channel: cc :: somkiat
Viewing all articles
Browse latest Browse all 1997

แนวทางในการนำ DevOps มาใช้ปรับปรุงการพัฒนา software

$
0
0

หลาย ๆ ครั้งมีการพูดคุยเรื่องของ DevOps
ว่าองค์กรเราต้อง DevOps นะ
ออกแบบ DevOps process นะ
ใช้ DevOps tool อะไรดี
ใช้ framework อะไรดี

แนะนำให้หยุดก่อน คิดก่อน ...
ประเด็นคือ อะไรละคือ DevOps ?
ทำไมต้องใช้ ?
ปัญหาของเราคืออะไร ?
หรือว่าเห็นคนอื่นทำ แล้วเขาบอกว่าดี ดังนั้นเราก็ต้องทำ ?
มาลองคิดเป็นขั้นตอนกันหน่อย ก่อนจะเริ่มต้น

ขั้นตอนที่ 0 ระบุปัญหาก่อนว่ามีอะไรบ้าง ?

จากนั้นจึงทำการเรียกลำดับตามความสำคัญหรือผลกระทบที่เกิดขึ้น
ว่าจะแก้ไขอะไรก่อนหลัง
แนะนำให้ค่อย ๆ แก้ไขทีละเรื่อง
ถ้ามันสำคัญหมด คงจะมั่วกันน่าดู 
เนื่องจากเราจะไร้ทิศทางมาก ๆ    

ถ้าไม่มีปัญหา จะปรับปรุงไปทำไม จริงไหม ?

ขั้นตอนที่ 1 ลดความหลากหลาย

สิ่งที่พบเจอบ่อยมาก ๆ ในการพัฒนา software คือ
ความหลากหลายของการทำงาน ไม่ว่าจะเป็น

  • ขั้นตอนการทำงาน
  • Environment ต่าง ๆ ที่ใช้งาน
  • เครื่องมือที่หลายหลาย ตามใจใครหลาย ๆ คน
  • การ configuration ที่ไร้ทิศทาง
  • ข้อมูลที่หลายหลายชนิด อยู่หลายที่

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

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

ขั้นตอนที่ 2 ต้องรู้ขั้นตอนการทำงานตั้งแต่ต้นจนจบ

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

ดังนั้นสิ่งที่ควรทำคือ
อะไรที่ไม่รู้ทำให้รู้ (มักจะไม่รู้ว่า ไม่รู้อะไร !!)
จากนั้นทำการสร้างเอกสาร เพื่ออธิบายการทำงานตั้งแต่ต้นจนจบไว้
จากนั้น share ให้ทุกคนที่เกี่ยวข้อง
จะได้ทำความเข้าใจ แก้ไขหรือปรับปรุงกันต่อไป
มันจะทำให้เราเห็นว่า การทำงานปัจจุบันเป็นอย่างไร
ตรงไหนมีปัญหา ตรงไหนที่มันเป็นคอขวด

ให้จำไว้ว่า ถ้าขั้นตอนมันห่วยแล้ว
จะเอาระบบการทำงานแบบอัตโนมัติมาใช้ มันก็ห่วย
ดังนั้นปรับปรุงการทำงานก่อนนะ

มันช่วยทำให้เราพูดคุยกัน ทำงานร่วมกัน
เพื่อเข้าใจซึ่งกันและกัน ได้ช่วยกัน review ขั้นตอนการทำงานอีกด้วย

เมื่อถึงขั้นตอนตรงนี้ จะเห็นว่า

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

ต่อจากนี้ต่อไป เริ่มนำเครื่องมือและเทคโนโลยีมาใช้แล้ว

ขั้นตอนที่ 3 เข้าสู่กระบวนการพัฒนาและส่งมอบ software

การพัฒนาและส่งมอบ software ที่ดีประกอบไปด้วย

  • การจัดการ source code หรือ Source Control Management (SCM)
  • กระบวนการ build ของ software
  • กระบวนการ deploy software
  • การ configuration หรือ provisioning environment ต่าง ๆ สำหรับการ deploy software

ซึ่งเราอาจจะต้องกำหนดการทำงานเหล่านี้ให้ชัดเจน
หรือดีที่สุดคือ ช่วยกันสร้างระบบที่ทำงานแบบอัตโนมัติขึ้นมา
เพื่อลดงานที่ต้องมีคนเข้าไปยุ่งเกี่ยวให้มากที่สุด
เพราะว่า มันคืองานที่ทำซ้ำ ๆ บ่อยมาก
และที่สำคัญคือ เพื่อลดปัญหาที่เกิดจากคนให้มากที่สุด
เรามักจะได้ยินคำว่า work on my machine !!

ขั้นตอนที่ 4 กระบวนการทดสอบแบบอัตโนมัติ

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

ที่สำคัญต้องทำงานได้รวดเร็วด้วย
มิเช่นนั้น ปัญหาต่าง ๆ ก็ยังคงอยู่เสมอ มันน่ากลัวมาก ๆ
ถ้าเราทำการ deploy software บ่อย ๆ แต่ผิดเยอะบ่อย ๆ  !!!
มันไม่น่าจะใช่ผลที่เราต้องการใช่ไหม ?

เมื่อเราทำตามมาจนถึงขั้นตอนนี้แล้ว

เราได้ผ่านความต้องการพื้นฐานตามแนวคิด DevOps มาแล้ว
สามารถแก้ไขปัญหาที่เรากำหนดได้แล้ว
จากนี้ก็เป็นเรื่องที่เราต้องไปต่อแล้ว
ไม่ว่าจะเริ่มสร้างระบบอื่น ๆ ขึ้นมา เพื่อให้ใช้งานง่ายขึ้น
เช่นระบบแบบ self-service ไม่ต้องมาผ่านขั้นตอนที่มากมายหรือช้ากันแล้ว
อยากได้อะไรไปสร้างเองได้เลย
มันก็อยู่ที่ความต้องการขององค์กรต่อไปแล้ว

ขอเน้นว่า เรื่องพื้นฐานสำคัญมาก ๆ


Viewing all articles
Browse latest Browse all 1997

Trending Articles