ทีม infra ทีม dev ทีม qa มาทำงานด้วยกัน มั้งครับ เดา

Operation ทั้งหลายที่ช่วยให้ workflow การพัฒนาซอฟท์แวร์มีประสิทธิภาพสูงที่สุดครับ ไม่เกี่ยวกับการเทสหรือทดสอบในตำแหน่ง QA
ส่วนใหญ่ยุ่งเกี่ยวกับการสร้าง Environment สำหรับการพัฒนาร่วมกัน ให้เหมาะแก่การทดสอบ ป้องกันการผิดพลาดในขั้นตอนการติดตั้ง
การจัดการที่เกี่ยวข้องกับการจัดเก็บโค้ด การทดสอบโค้ดอัตโนมัติ หลังจากคอมมิตโค้ดไปแล้ว การติดตั้งระบบอัตโนมัติ เป็นต้น
ความรู้ที่ต้องมี
Linux, Cloud server
Git Server
Docker, Docku, Capistrano, Jenkin
อะไรอีกหลากหลาย ใครสามารถทำงานด้านนี้ได้บริษัทผมรับสมัครนะครับ

https://www.blognone.com/node/69722

มาเสริมจากข้างบน หลักสำคัญของ DevOps คือ CI/CDhttp://vaidamit.blogspot.com/2014/02/devops-keyprinciples-cicd.html

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

แต่แน่นอนว่าถ้าเราแค่มารัน TDD หรือ BDD บนเครื่องเราก็ไม่มีประโยชน์ มันต้องไปรันบนเครื่องเทส (staging) ซึ่งแน่นอนว่า dev จะไปรันเองได้ไง มันก้าวก่ายงาน infra กลับกัน infra ก็มีงานของเขา ทางออกเลยเป็นการสร้าง CI พูดง่ายๆ คือทุกครั้งที่ deploy ขึ้น staging โค้ดขึ้นไป ให้ทำการรัน testcase เองทั้งหมด ถ้ารันไม่ผ่านก็แจ้งบอก แบบนี้ก็จะสบายทั้ง dev และ infra (เป้าหมายของ devops คือไม่ทำให้ dev กับ infra มานั่งทะเลาะกัน #ผิด)

ส่วน CD มันคือการทำให้งานที่เราทำๆ นี้ สามารถส่งถึงลูกค้าได้จริงๆ (ส่วนมากเป็นแนวคิดการสร้าง value ของงาน) คือต่อจาก CI พอเทสเคสเรารันได้หมด ซึ่งอันนี้พูดสั้นๆ เฉพาะจาก a ไป b แต่ถ้าเกิดงานเราแตก feature แน่นอนว่าไม่ใช่ทุกตัวจะมีโอกาสได้เอาขึ้น บางอันทำมาดอง บางอันทำมาขายแต่ดูท่าจะไม่เวิร์ค บางอันเพิ่งมาคิดได้รีนปั่นต้องเอาก่อน พอมันแตกเยอะๆ แถมดันเขียนแยกกัน คนล่ะทีม (chip แล้ว) แนวคิดคือการสร้าง CI เป็นชั้นๆ ในการทำงานและเทสแต่ล่ะชั้น สามารถเลือกเอางาน branch ไหนขึ้นไปก่อน แล้ว เมื่อเอา feature merge deploy ขึ้น staging แล้วมันแป๊ก ต้องมี plan fallback ด้วย คือทั้งหมดนี้ต้องเป็นระบบอัตโนมัติ เป้าหมายคือลดการทำงานซ้ำๆ และทำให้ทุกคนเชื่อได้ว่า process การทำงานของเรามันมี trust ในตัวมันเอง พร้อมจะส่งมอบงานให้ลูกค้าได้ทันทีที่ระบบที่ออกแบบไว้บอกว่า "ผ่าน" (เทสผ่านในแต่ล่ะระดับตั้งแต่ local -> feature -> staging -> production)

อารมณ์ก็น่าจะประมาณนี้ครับ อาจผิดบ้างนะเพราะผมเป็น dev คนหนึ่ง ช่วยเสริมได้นะครับ

#

ทุกวันนี้มีหลายที่พยายามทำ CICD แต่มักไม่เวิร์ค สำคัญสุดคือถ้าไม่มีคนเขียน testing ทั้งสำหรับ TDD และ BDD จะทำไม่ได้เลย ซึ่งมักจะเพราะ timeline มันน้อยซะเหลือเกิน

ทุกวันนี้บางคนหลอกว่าตัวเองทำ kanban แต่จริงๆ อาจเป็น waterfall เวอร์ชั่นหั่นเป็นชิ้น /sob