เวิร์กโฟลว์ที่ดีสำหรับการพัฒนาซอฟต์แวร์ด้วยการต่อสู้และรวมอย่างต่อเนื่อง

ฉันกำลังศึกษาวิธีการที่จะเข้าใจได้ดีขึ้นว่าเวิร์กโฟลว์การรวมต่อเนื่องนั้นเหมาะกับ บริษัท พัฒนาซอฟต์แวร์ด้วยวิธีการแย่งชิงกันอย่างไร

ฉันกำลังคิดเช่นนี้:

นั่นจะเป็นขั้นตอนการทำงานที่ดีหรือไม่?

คุณมีวิธีที่มี แต่ฉันจะขยายไดอะแกรมของคุณค่อนข้าง:

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

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

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

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

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

กระบวนการที่ฉันระบุไว้เป็นสถานการณ์ในอุดมคติกรณีมีหลายสาเหตุที่คุณอาจละทิ้งบางส่วน (ตัวอย่างเช่นสาขานักพัฒนาซอฟต์แวร์ไม่สามารถทำได้ใน SVN) แต่คุณต้องการตั้งเป้าหมายให้มากที่สุดเท่าที่จะทำได้ .

สำหรับวัฏจักรการแย่งชิงของ Scrum ที่เหมาะสมกับสิ่งนี้คุณต้องการให้การเผยแพร่ของคุณเกิดขึ้นบ่อยที่สุดเท่าที่จะเป็นไปได้และอย่าปล่อยไว้จนกว่าจะสิ้นสุดการวิ่งตามที่ได้รับการตอบรับอย่างรวดเร็วว่าเป็นคุณลักษณะ ) เป็นไปได้สำหรับการย้ายไปยังการผลิตเป็นเทคนิคสำคัญสำหรับการตัดทอนความคิดเห็นของคุณกลับไปยังเจ้าของผลิตภัณฑ์ของคุณ

แนวคิดใช่ ไดอะแกรมไม่สามารถจับจุดสำคัญได้มากมายเช่น:

1. การทดสอบหน่วย
2. การกระทำที่เพิ่มขึ้น
3. การจัดเตรียมถูกปรับใช้กับบ่อยครั้งโดยปกติแล้วการผลิตจะไม่ทำ

คุณอาจต้องการวาดระบบที่กว้างขึ้นสำหรับแผนภาพ ฉันจะพิจารณาเพิ่มองค์ประกอบต่อไปนี้:

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

แสดงจุดควบคุมตามเวิร์กโฟลว์ ใครเป็นผู้ตัดสินใจว่าจะอนุญาตให้มีการเปลี่ยนแปลงใน trunk / main / release-branch / etc ... ได้อย่างไร สิ่งที่ codetrees / โครงการสร้างบน CIS? มีจุดตรวจเพื่อดูว่าบิลด์พังหรือไม่ ใครเผยแพร่จาก CIS เพื่อจัดเตรียม / ผลิต

ที่เกี่ยวข้องกับจุดควบคุมคือการระบุว่าวิธีการแยกสาขาของคุณคืออะไรและเหมาะสมกับเวิร์กโฟลว์นี้อย่างไร

มีทีมทดสอบหรือไม่? พวกเขามีส่วนร่วมหรือได้รับแจ้งเมื่อใด มีการทดสอบอัตโนมัติใน CIS หรือไม่ การแตกหักจะถูกป้อนกลับเข้าสู่ระบบได้อย่างไร?

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

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

ฉันใช้คำว่า "การพัฒนาอัตโนมัติ" เพื่อรวมการสร้างอัตโนมัติการสร้างเอกสารการทดสอบการวัดประสิทธิภาพและกิจกรรมการปรับใช้

ดังนั้น "เซิร์ฟเวอร์การพัฒนาอัตโนมัติ" จึงมีการส่งเงินที่คล้ายกัน แต่ค่อนข้างกว้างกว่าเซิร์ฟเวอร์การรวมต่อเนื่อง

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

สคริปต์หลังการกระทำจะกำหนดกิจกรรมการทำงานอัตโนมัติที่จะเรียกใช้ตามเนื้อหาของสาขาเอง ไม่ว่าจะโดยการอ่านไฟล์กำหนดค่าโพสต์คอมมิชชันในตำแหน่งคงที่ในสาขาหรือโดยการตรวจสอบคำเฉพาะ (ฉันใช้ / auto /) เป็นส่วนประกอบของเส้นทางไปยังสาขาในพื้นที่เก็บข้อมูล (กับ Svn)

(การตั้งค่าด้วย Svn ง่ายกว่า Hg)

วิธีนี้ช่วยให้ทีมพัฒนามีความยืดหยุ่นมากขึ้นเกี่ยวกับวิธีจัดระเบียบเวิร์กโฟลว์ทำให้ CI สามารถสนับสนุนการพัฒนาในสาขาที่มีค่าใช้จ่ายในการบริหารน้อยที่สุด (ใกล้เคียงกับศูนย์)

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

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

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

ขึ้นอยู่กับทรัพยากร / เครือข่ายของคุณคุณอาจต้องการพิจารณาเพิ่มเซิร์ฟเวอร์ปลายทางที่แตกต่างกัน เรามี CI build ที่ถูกทริกเกอร์โดย repo และสมมติว่า build และผ่านการทดสอบทั้งหมดจากนั้นจะถูกนำไปใช้กับเซิร์ฟเวอร์การพัฒนาเพื่อให้ devs สามารถตรวจสอบให้แน่ใจว่าเล่นได้ดี (คุณอาจรวมถึงซีลีเนียมหรือการทดสอบ UI อื่น ๆ ) ไม่ใช่ทุกคอมมิชชันคือ build ที่มีเสถียรภาพดังนั้นเพื่อทริกเกอร์การสร้างไปยังเซิร์ฟเวอร์ staging เราต้องติดแท็กการแก้ไข (เราใช้ mercurial) ที่เราต้องการสร้างและปรับใช้อีกครั้งสิ่งนี้เป็นไปโดยอัตโนมัติและทริกเกอร์เพียงแค่ แท็ก การไปผลิตเป็นกระบวนการที่ต้องทำด้วยตนเอง คุณสามารถปล่อยให้มันง่ายเหมือนการบังคับให้บิลด์เคล็ดลับคือการรู้ว่าต้องการแก้ไข / บิลด์ใด แต่ถ้าคุณต้องติดแท็กการแก้ไขอย่างเหมาะสมเซิร์ฟเวอร์ CI สามารถเช็คเอาท์รุ่นที่ถูกต้องและทำสิ่งที่จำเป็น คุณสามารถใช้ MS Deploy เพื่อซิงค์การเปลี่ยนแปลงไปยังเซิร์ฟเวอร์ที่ใช้งานจริงหรือเพื่อจัดทำแพ็กเกจและวาง zip ไว้ที่ใดที่หนึ่งเพื่อให้ผู้ดูแลระบบสามารถปรับใช้ด้วยตนเอง ... ขึ้นอยู่กับความสะดวกสบายของคุณ

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

CruiseControl.Net ใช้ xml เพื่อกำหนดค่าการสร้าง TeamCity ใช้ตัวช่วยสร้างหากคุณต้องการหลีกเลี่ยงผู้เชี่ยวชาญในทีมของคุณความซับซ้อนของการกำหนดค่า XML จะเป็นสิ่งอื่นที่ต้องคำนึงถึง

ประการแรกข้อแม้: การแย่งชิงกันเป็นวิธีการที่ค่อนข้างเข้มงวด ฉันทำงานให้กับองค์กรสองแห่งที่พยายามใช้วิธีการต่อสู้แบบ Scrum หรือแบบ Scrum แต่พวกเขาทั้งสองไม่ได้เข้าใกล้กับการใช้ระเบียบวินัยอย่างเต็มที่ จากประสบการณ์ของฉันฉันเป็นคนที่กระตือรือร้นและคล่องแคล่ว แต่เป็นคนขี้สงสัย

เมื่อฉันเข้าใจแล้ว Scrum และวิธี Agile อื่น ๆ มีวัตถุประสงค์หลักสองประการ:

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

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

การพัฒนาระบบอัตโนมัติรวมถึงการรวมอย่างต่อเนื่องเป็นปัจจัยที่สำคัญที่สุดในความสำเร็จของวิธีการนี้ การค้นหาความเสี่ยงและการเรียนรู้บทเรียนต้องรวดเร็วปราศจากแรงเสียดทานและปราศจากปัจจัยทางสังคมที่สับสน (ผู้คนเรียนรู้เร็วขึ้นมากเมื่อเป็นเครื่องจักรที่บอกพวกเขาว่าพวกเขาผิดมากกว่ามนุษย์คนอื่น - egos จะเข้าสู่การเรียนรู้เท่านั้น)

อย่างที่คุณสามารถบอกได้ - ฉันยังเป็นแฟนตัวยงของการพัฒนาที่ขับเคลื่อนด้วยการทดสอบ :-)

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

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

ดังนั้นโดยสรุป:

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

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