หากบริษัทของคุณเพิ่งแนะนำเครื่องมือ DevOps หรือ CI/CD อาจเป็นประโยชน์สำหรับคุณที่จะทำความคุ้นเคยกับข้อผิดพลาดที่พบบ่อยที่สุด เพื่อไม่ให้เกิดซ้ำและไม่เหยียบย่ำคนอื่น
ทีม แปลบทความ .
การไม่เตรียมพร้อมที่จะเปลี่ยนแปลงวัฒนธรรมและกระบวนการ
หากดูจากแผนภาพวงจร เห็นได้ชัดว่าในการทดสอบการปฏิบัติ DevOps เป็นกิจกรรมต่อเนื่อง ซึ่งเป็นส่วนพื้นฐานของทุกการใช้งาน
แผนภูมิวงจรไม่มีที่สิ้นสุด DevOps
การทดสอบและการประกันคุณภาพระหว่างการพัฒนาและการส่งมอบเป็นส่วนสำคัญของทุกสิ่งที่นักพัฒนาทำ สิ่งนี้จำเป็นต้องเปลี่ยนกรอบความคิดเพื่อรวมการทดสอบเข้ากับทุกงาน
การทดสอบกลายเป็นส่วนหนึ่งของงานประจำวันของสมาชิกในทีมทุกคน การเปลี่ยนไปใช้การทดสอบอย่างต่อเนื่องไม่ใช่เรื่องง่าย คุณต้องเตรียมพร้อม
ขาดความคิดเห็น
ประสิทธิผลของ DevOps ขึ้นอยู่กับผลตอบรับอย่างต่อเนื่อง การปรับปรุงอย่างต่อเนื่องเป็นไปไม่ได้หากไม่มีพื้นที่สำหรับการทำงานร่วมกันและการสื่อสาร
บริษัทที่ไม่จัดการประชุมแบบย้อนหลังพบว่าการนำวัฒนธรรมการตอบรับอย่างต่อเนื่องไปใช้ใน CI/CD เป็นเรื่องยาก การประชุมแบบย้อนหลังจะจัดขึ้นเมื่อสิ้นสุดการวนซ้ำแต่ละครั้ง ในระหว่างนี้สมาชิกในทีมจะหารือกันว่าอะไรไปได้ดีและอะไรไปไม่ดี การประชุมย้อนหลังเป็นรากฐานของ Scrum/Agile แต่ก็จำเป็นสำหรับ DevOps เช่นกัน
เนื่องจากการประชุมย้อนหลังจะปลูกฝังนิสัยในการแลกเปลี่ยนความคิดเห็นและข้อเสนอแนะ จุดที่สำคัญที่สุดประการหนึ่งในช่วงเริ่มต้นคือการจัดการประชุมย้อนยุคที่เกิดซ้ำเพื่อให้ทุกคนในทีมเข้าใจและคุ้นเคย
เมื่อพูดถึงคุณภาพของซอฟต์แวร์ สมาชิกในทีมทุกคนมีหน้าที่รับผิดชอบในการดูแลรักษาซอฟต์แวร์ ตัวอย่างเช่น นักพัฒนาสามารถเขียนการทดสอบหน่วยและเขียนโค้ดโดยคำนึงถึงความสามารถในการทดสอบ ซึ่งช่วยลดความเสี่ยงตั้งแต่เริ่มต้น
วิธีง่ายๆ วิธีหนึ่งในการสะท้อนถึงการเปลี่ยนแปลงในการคิดเกี่ยวกับการทดสอบคือการเรียกผู้ทดสอบ ไม่ใช่ QA แต่เรียกผู้ทดสอบซอฟต์แวร์หรือวิศวกรด้านคุณภาพ การเปลี่ยนแปลงนี้อาจดูง่ายเกินไปหรือโง่เง่าเกินไป แต่การเรียกใครบางคนว่า "ผู้ประกันคุณภาพซอฟต์แวร์" ทำให้เข้าใจผิดว่าใครเป็นผู้รับผิดชอบคุณภาพของผลิตภัณฑ์ ในแนวปฏิบัติ Agile, CI/CD และ DevOps ทุกคนมีหน้าที่รับผิดชอบต่อคุณภาพของซอฟต์แวร์
ประเด็นสำคัญอีกประการหนึ่งคือการทำความเข้าใจว่าคุณภาพมีความหมายต่อทั้งทีมและสมาชิกแต่ละคน องค์กร และผู้มีส่วนได้ส่วนเสียอย่างไร
ความเข้าใจผิดเกี่ยวกับการเสร็จสิ้นขั้นตอน
หากคุณภาพเป็นกระบวนการทั่วไปที่ต่อเนื่อง จำเป็นต้องมีความเข้าใจร่วมกันเกี่ยวกับการทำให้ขั้นตอนเสร็จสมบูรณ์ คุณจะรู้ได้อย่างไรว่าเมื่อเวทีจบลง? จะเกิดอะไรขึ้นเมื่อขั้นตอนถูกทำเครื่องหมายว่าเสร็จสมบูรณ์บน Trello หรือกระดาน Kanban อื่นๆ
คำจำกัดความของ Done (DoD) เป็นเครื่องมือที่ทรงพลังในบริบทของ CD DevOps/CI ช่วยให้เข้าใจมาตรฐานคุณภาพของสิ่งที่ทีมสร้างขึ้นและอย่างไรได้ดีขึ้น
ทีมพัฒนาจะต้องตัดสินใจว่า "เสร็จสิ้น" หมายถึงอะไร พวกเขาต้องนั่งลงและเขียนรายการคุณลักษณะที่ต้องปฏิบัติตามในแต่ละขั้นตอนจึงจะถือว่าครบถ้วน
DoD ทำให้กระบวนการโปร่งใสมากขึ้น และทำให้ง่ายต่อการใช้งาน CI/CD หากสมาชิกในทีมทุกคนเข้าใจและตกลงร่วมกัน
ขาดเป้าหมายที่สมจริงและชัดเจน
นี่เป็นหนึ่งในคำแนะนำที่มีการยกมาบ่อยที่สุด แต่ก็ต้องมีการทำซ้ำ เพื่อให้ประสบความสำเร็จในความพยายามสำคัญใดๆ รวมถึง CI/CD หรือ DevOps คุณต้องตั้งเป้าหมายที่สมจริงและวัดประสิทธิภาพเทียบกับเป้าหมายเหล่านั้น คุณกำลังพยายามบรรลุผลอะไรด้วย CI/CD? สิ่งนี้ช่วยให้เผยแพร่เร็วขึ้นและมีคุณภาพดีขึ้นหรือไม่
เป้าหมายที่ตั้งไว้จะต้องไม่เพียงแต่โปร่งใสและสมจริงเท่านั้น แต่ยังสอดคล้องกับกิจกรรมในปัจจุบันของบริษัทด้วย ตัวอย่างเช่น ลูกค้าของคุณต้องการแพตช์หรือเวอร์ชันใหม่บ่อยเพียงใด ไม่จำเป็นต้องโอเวอร์โหลดกระบวนการและเผยแพร่เร็วขึ้น หากไม่มีประโยชน์เพิ่มเติมให้กับผู้ใช้
นอกจากนี้ คุณไม่จำเป็นต้องใช้ทั้ง CD และ CI เสมอไป ตัวอย่างเช่น บริษัทที่มีการควบคุมอย่างเข้มงวด เช่น ธนาคารและคลินิกการแพทย์อาจทำงานร่วมกับ CI เท่านั้น
CI ทำหน้าที่เป็นจุดเริ่มต้นที่ดีสำหรับบริษัทใดๆ ก็ตามที่ใช้ DevOps เมื่อนำมาใช้ แนวทางของบริษัทต่างๆ ในการส่งมอบซอฟต์แวร์จะเปลี่ยนไปอย่างมาก เมื่อ CI เชี่ยวชาญแล้ว คุณสามารถคิดถึงการปรับปรุงกระบวนการทั้งหมด เพิ่มความเร็วการเปิดตัว และการเปลี่ยนแปลงอื่นๆ ได้
สำหรับหลายๆ องค์กร CI เพียงอย่างเดียวก็เพียงพอแล้ว และ CD ควรนำไปใช้ก็ต่อเมื่อมันเพิ่มมูลค่าเท่านั้น
ขาดแดชบอร์ดและตัวชี้วัดที่เหมาะสม
เมื่อคุณกำหนดเป้าหมายแล้ว ทีมพัฒนาจะสามารถสร้างแดชบอร์ดเพื่อวัด KPI ได้ ก่อนการพัฒนาควรประเมินพารามิเตอร์ที่จะตรวจสอบก่อน
รายงานและแอปพลิเคชันที่แตกต่างกันมีประโยชน์สำหรับสมาชิกในทีมที่แตกต่างกัน Scrum Master สนใจสถานะและการเข้าถึงมากกว่า ในขณะที่ผู้บริหารระดับสูงอาจสนใจอัตราความเหนื่อยหน่ายของผู้เชี่ยวชาญ
บางทีมยังใช้แดชบอร์ดที่มีตัวบ่งชี้สีแดง เหลือง และเขียวเพื่อประเมินสถานะของ CI/CD เพื่อทำความเข้าใจว่าพวกเขากำลังทำทุกอย่างถูกต้องหรือมีข้อผิดพลาดหรือไม่ สีแดงหมายความว่าคุณต้องใส่ใจกับสิ่งที่เกิดขึ้น
อย่างไรก็ตาม หากแดชบอร์ดไม่ได้มาตรฐาน อาจทำให้เข้าใจผิดได้ วิเคราะห์ข้อมูลที่ทุกคนต้องการ จากนั้นสร้างคำอธิบายที่เป็นมาตรฐานว่าหมายถึงอะไร ค้นหาว่าสิ่งใดที่เหมาะกับผู้มีส่วนได้ส่วนเสียมากกว่า: กราฟิก ข้อความ หรือตัวเลข
ไม่มีการทดสอบด้วยตนเอง
การทดสอบอัตโนมัติวางรากฐานสำหรับไปป์ไลน์ CI/CD ที่ดี แต่การทดสอบอัตโนมัติในทุกขั้นตอนไม่ได้หมายความว่าคุณไม่ควรทำการทดสอบด้วยตนเอง
หากต้องการสร้างไปป์ไลน์ CI/CD ที่มีประสิทธิภาพ คุณต้องมีการทดสอบด้วยตนเองด้วย การทดสอบจะมีบางแง่มุมที่ต้องมีการวิเคราะห์โดยมนุษย์เสมอ
การพิจารณาบูรณาการความพยายามในการทดสอบด้วยตนเองเข้ากับไปป์ไลน์ของคุณเป็นสิ่งที่คุ้มค่า เมื่อการทดสอบกรณีทดสอบบางกรณีด้วยตนเองเสร็จสิ้นแล้ว คุณสามารถไปยังขั้นตอนการปรับใช้ได้
อย่าพยายามปรับปรุงการทดสอบ
ไปป์ไลน์ CI/CD ที่มีประสิทธิภาพจำเป็นต้องเข้าถึงเครื่องมือที่เหมาะสม ไม่ว่าจะเป็นการจัดการทดสอบ หรือการบูรณาการ และการตรวจสอบอย่างต่อเนื่อง
การสร้างวัฒนธรรมที่มุ่งเน้นคุณภาพที่เข้มแข็งมีจุดมุ่งหมายเพื่อ ติดตามการโต้ตอบของลูกค้าหลังการใช้งานและการติดตามการปรับปรุง
คำแนะนำที่เป็นประโยชน์บางประการที่คุณสามารถนำไปปฏิบัติได้อย่างง่ายดายมีดังนี้:
- ตรวจสอบให้แน่ใจว่าการทดสอบของคุณเขียนง่ายและยืดหยุ่นพอที่จะไม่เสียหายเมื่อคุณปรับโครงสร้างโค้ดใหม่
- ควรรวมทีมพัฒนาไว้ในกระบวนการทดสอบ - ดูรายการปัญหาของผู้ใช้และคำขอที่สำคัญในการทดสอบระหว่างไปป์ไลน์ CI
- คุณอาจไม่มีการทดสอบครอบคลุมทั้งหมด แต่ตรวจสอบให้แน่ใจเสมอว่ามีการทดสอบโฟลว์ที่มีความสำคัญต่อ UX และประสบการณ์ของลูกค้า
สุดท้ายแต่ไม่ท้ายสุดประเด็นสำคัญ
การเปลี่ยนไปใช้ CI/CD มักจะขับเคลื่อนจากล่างขึ้นบน แต่ท้ายที่สุดแล้ว การเปลี่ยนแปลงดังกล่าวต้องอาศัยการยอมรับจากผู้นำ เวลา และทรัพยากรจากบริษัท ท้ายที่สุด CI/CD คือชุดของทักษะ กระบวนการ เครื่องมือ และการปรับโครงสร้างวัฒนธรรม การเปลี่ยนแปลงดังกล่าวสามารถดำเนินการได้อย่างเป็นระบบเท่านั้น
มีอะไรอีกให้อ่านในหัวข้อ:
- .
- .
- .
ที่มา: will.com