บูรณาการอย่างต่อเนื่อง - ลดความเสี่ยง

มีโอกาสที่จะเกิดข้อผิดพลาดในโครงการ ด้วยการฝึกฝน CI อย่างมีประสิทธิภาพคุณจะพบว่าเกิดอะไรขึ้นในทุกขั้นตอนระหว่างทางแทนที่จะเป็นในภายหลังเมื่อโครงการเข้าสู่วงจรการพัฒนา CI ช่วยให้คุณระบุและลดความเสี่ยงเมื่อเกิดขึ้นทำให้ง่ายต่อการประเมินและรายงานเกี่ยวกับความสมบูรณ์ของโครงการโดยอาศัยหลักฐานที่เป็นรูปธรรม

ส่วนนี้จะเน้นไปที่ความเสี่ยงที่สามารถหลีกเลี่ยงได้โดยใช้การบูรณาการต่อเนื่อง

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

ความเสี่ยง 1 - ขาดซอฟต์แวร์ที่ปรับใช้งานได้

“It works on my machine but does not work on another”- นี่อาจเป็นหนึ่งในวลีที่พบบ่อยที่สุดในองค์กรซอฟต์แวร์ใด ๆ เนื่องจากจำนวนการเปลี่ยนแปลงที่เกิดขึ้นกับซอฟต์แวร์ที่สร้างขึ้นในแต่ละวันบางครั้งจึงมีความมั่นใจเพียงเล็กน้อยว่าการสร้างซอฟต์แวร์ใช้งานได้จริงหรือไม่ ความกังวลนี้มีผลข้างเคียงสามประการดังต่อไปนี้

  • มีความมั่นใจเพียงเล็กน้อยหรือแทบไม่มีเลยว่าเราสามารถสร้างซอฟต์แวร์ได้หรือไม่

  • ขั้นตอนการผสานรวมที่ยาวนานก่อนส่งมอบซอฟต์แวร์ภายใน (เช่นทีมทดสอบ) หรือภายนอก (เช่นลูกค้า) ในช่วงเวลาที่ไม่มีอะไรให้ทำอีก

  • ไม่สามารถผลิตและทำซ้ำงานสร้างที่ทดสอบได้

วิธีการแก้

การกำจัดการมีเพศสัมพันธ์ที่แน่นหนาระหว่าง IDE และกระบวนการสร้าง ใช้เครื่องแยกต่างหากสำหรับการรวมซอฟต์แวร์เท่านั้น ตรวจสอบให้แน่ใจว่าทุกสิ่งที่คุณต้องการในการสร้างซอฟต์แวร์มีอยู่ในที่เก็บการควบคุมเวอร์ชัน สุดท้ายสร้างระบบบูรณาการต่อเนื่อง

เซิร์ฟเวอร์การรวมแบบต่อเนื่องสามารถเฝ้าดูการเปลี่ยนแปลงในที่เก็บการควบคุมเวอร์ชันและรันสคริปต์การสร้างโครงการเมื่อตรวจพบการเปลี่ยนแปลงที่เก็บ ความสามารถของระบบ Continuous Integration สามารถเพิ่มขึ้นเพื่อรวมถึงการสร้างการทำงานผ่านการทดสอบดำเนินการตรวจสอบและปรับใช้ซอฟต์แวร์ในสภาพแวดล้อมการพัฒนาและการทดสอบ ด้วยวิธีนี้คุณจะมีซอฟต์แวร์ที่ใช้งานได้เสมอ

“Inability to synchronize with the database”- บางครั้งนักพัฒนาไม่สามารถสร้างฐานข้อมูลใหม่ได้อย่างรวดเร็วในระหว่างการพัฒนาและด้วยเหตุนี้จึงยากที่จะทำการเปลี่ยนแปลง บ่อยครั้งที่เกิดจากการแยกระหว่างทีมฐานข้อมูลและทีมพัฒนา แต่ละทีมจะมุ่งเน้นไปที่ความรับผิดชอบของตนเองและมีการทำงานร่วมกันเพียงเล็กน้อย ความกังวลนี้มีผลข้างเคียงสามประการดังต่อไปนี้ -

  • กลัวที่จะทำการเปลี่ยนแปลงหรือปรับโครงสร้างฐานข้อมูลหรือซอร์สโค้ด

  • ความยากในการเติมฐานข้อมูลด้วยชุดข้อมูลการทดสอบที่แตกต่างกัน

  • ความยากลำบากในการดูแลสภาพแวดล้อมการพัฒนาและการทดสอบ (เช่นการพัฒนาการรวมระบบการควบคุมคุณภาพและการทดสอบ)

วิธีการแก้

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

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

ทดสอบ (และตรวจสอบ) ฐานข้อมูลของคุณ โดยทั่วไปคุณจะใช้การทดสอบส่วนประกอบเพื่อทดสอบฐานข้อมูลและข้อมูล ในบางกรณีคุณจะต้องเขียนการทดสอบเฉพาะฐานข้อมูล

ความเสี่ยง 2 - การค้นพบข้อบกพร่องล่าช้าในวงจรชีวิต

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

วิธีการแก้

Regression Testing- นี่คือสิ่งที่สำคัญที่สุดของวงจรการพัฒนาซอฟต์แวร์ใด ๆ ทดสอบแล้วทดสอบอีกครั้ง หากมีการเปลี่ยนแปลงที่สำคัญในรหัสซอฟต์แวร์จำเป็นอย่างยิ่งที่จะต้องดำเนินการทดสอบทั้งหมด และสิ่งนี้สามารถทำให้เป็นอัตโนมัติได้ด้วยความช่วยเหลือของเซิร์ฟเวอร์การรวมอย่างต่อเนื่อง

Test Coverage- ไม่มีประเด็นใดในการทดสอบหากกรณีทดสอบไม่ครอบคลุมฟังก์ชันการทำงานทั้งหมดของโค้ด เป็นสิ่งสำคัญเพื่อให้แน่ใจว่ากรณีทดสอบที่สร้างขึ้นเพื่อทดสอบแอปพลิเคชันนั้นสมบูรณ์และมีการทดสอบเส้นทางรหัสทั้งหมด

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

ความเสี่ยง 3 - ขาดการมองเห็นโครงการ

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

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

วิธีการแก้

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

ความเสี่ยง 4 - ซอฟต์แวร์คุณภาพต่ำ

มีข้อบกพร่องและมีข้อบกพร่องที่อาจเกิดขึ้น คุณสามารถมีข้อบกพร่องที่อาจเกิดขึ้นได้เมื่อซอฟต์แวร์ของคุณไม่ได้รับการออกแบบมาอย่างดีหรือหากไม่เป็นไปตามมาตรฐานโครงการหรือมีความซับซ้อนในการดูแลรักษา บางครั้งผู้คนเรียกสิ่งนี้ว่ารหัสหรือกลิ่นการออกแบบ -“ อาการที่อาจมีบางอย่างผิดปกติ”

บางคนเชื่อว่าซอฟต์แวร์คุณภาพต่ำเป็นเพียงต้นทุนโครงการรอการตัดบัญชี (หลังส่งมอบ) อาจเป็นต้นทุนโครงการที่รอการตัดบัญชี แต่ยังนำไปสู่ปัญหาอื่น ๆ อีกมากมายก่อนที่คุณจะส่งมอบซอฟต์แวร์ให้กับผู้ใช้ รหัสที่ซับซ้อนเกินไปรหัสที่ไม่เป็นไปตามสถาปัตยกรรมและรหัสที่ซ้ำกันมักจะนำไปสู่ข้อบกพร่องในซอฟต์แวร์ การค้นหารหัสและกลิ่นการออกแบบเหล่านี้ก่อนที่จะปรากฏเป็นข้อบกพร่องสามารถประหยัดทั้งเวลาและเงินและอาจนำไปสู่ซอฟต์แวร์ที่มีคุณภาพสูงขึ้น

วิธีการแก้

มีส่วนประกอบซอฟต์แวร์เพื่อดำเนินการตรวจสอบคุณภาพโค้ดซึ่งสามารถรวมเข้ากับซอฟต์แวร์ CI ได้ สิ่งนี้สามารถทำงานได้หลังจากสร้างโค้ดเพื่อให้แน่ใจว่าโค้ดเป็นไปตามแนวทางการเข้ารหัสที่เหมาะสม