ใช้การทดสอบสาขาใน Git

เรามีใครบางคน (เรียกเขาว่าเท็ด) ที่รับผิดชอบการทดสอบคุณสมบัติใหม่และการแก้ไขข้อบกพร่อง

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

โครงการอยู่ใน PHP

ฉันต้องการให้กระบวนการทดสอบเป็นไปตามนี้:

ผู้พัฒนาต้องการทำงานกับคุณสมบัติใหม่ (สมมติว่าคุณสมบัติ / ข้อผิดพลาด # 123 เป็นเอกสาร Ted ในตัวติดตามปัญหา) ดังนั้นเขาจึงดึงorigin/developmentไปdevelopmentที่ที่เก็บในเครื่องของเขาและสร้างสาขาใหม่ (สมมติว่าissue-123) จากที่นั่น
originเมื่อเขามีความสุขกับการทำงานของเขาเขามุ่งมั่นและผลักดันสาขาใหม่ของเขาไป
เท็ดเชื่อมต่อtest.ourproject.com/choose-branchและดูรายการของสาขาoriginและเลือกที่จะเปิดissue-123(มันควรจะทำได้ผ่านหน้าเว็บ) จากนั้นเขาก็test.ourproject.comทำการทดสอบนรกจากเว็บแอปพลิเคชั่น (เขาเป็นคนที่ไร้ความปราณี) และหลังจากกลับมากับนักพัฒนาเขามีความสุขกับคุณสมบัตินี้
เท็ดบอกนักพัฒนาที่ว่าเขาสามารถผสานissue-123เข้าสู่บนdevelopmentorigin
ล้างและทำซ้ำ

สำหรับขั้นตอนที่สามฉันสามารถแฮ็คสิ่งที่ทำงาน (แสดงและสลับสาขาจากหน้าเฉพาะ) แต่ฉันรู้สึกว่าสิ่งที่ฉันอธิบายไว้เป็นรูปแบบทั่วไปมาก

ดังนั้นคำถามของฉันคือ: นี่เป็นเวิร์กโฟลว์ที่ดี / ยั่งยืน / บำรุงรักษาได้สำหรับการแยกหรือไม่ คุณสามารถสำรองคำตอบของคุณโดยอ้างตัวอย่างของโครงการอื่น ๆ ที่ติดตามเวิร์กโฟลว์นี้หรือไม่?

testing git integration

— CPA
แหล่งที่มา

"ทดสอบนรกจากเว็บแอพ (เขาประมาทจริง ๆ ) และหลังจากใช้งาน dev ไปมาเขามีความสุขกับฟีเจอร์นี้" - บุคคลนี้ต้องใกล้เคียงอัจฉริยะ เขารู้จริงหรือไม่ว่ารหัสที่เป็นปัญหานั้นเกี่ยวกับอะไร มีโครงการเช่นนี้ แต่ฉันสงสัยในผลลัพธ์ของขั้นตอนที่ 3

— SChepurin

ฉันควรทำให้ชัดเจนยิ่งขึ้นissue-123ถึงการอ้างอิงข้อผิดพลาด / คุณสมบัติ # 123 เป็นเอกสารเท็ดทุกข้อบกพร่อง / คุณสมบัติใหม่ในการติดตามปัญหาของเรา

— cpa

@ CPA: กว่าทำให้ชัดเจน คำถามสามารถแก้ไขได้

— Jan Hudec

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

— Jan Hudec

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

— mjs

คำตอบ:

เวิร์กโฟลว์สาขาฟังดูเหมือน gitflow มากhttp://jeffkreeftmeijer.com/2010/why-arent-you-using-git-flowและมีเครื่องมือสนับสนุนอยู่รอบตัว ขอแนะนำอย่างยิ่ง

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

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

ฉันขอแนะนำให้อ่านhttp://sethrobertson.github.com/GitBestPractices/ซึ่งกล่าวถึงเรื่องเหล่านี้ทั้งหมดและมีการอ้างอิงที่ดีมากมาย

— เซทโรเบิร์ตสัน
แหล่งที่มา

git-flowไม่ใช่สิ่งที่ฉันกำลังมองหา แต่มันเป็นสิ่งที่เราต้องการ! ขอบคุณ!

— cpa

ฉันไม่แน่ใจว่าหน้าการสลับเองเป็นรูปแบบทั่วไป โครงการส่วนใหญ่อาจมีเพียงผู้ทดสอบตรวจสอบด้วยคำสั่ง git

วิธีการทั่วไปนั้นฟังดูสมเหตุสมผล

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

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

— Jan Hudec
แหล่งที่มา

หากการทดสอบของคุณทำโดยอัตโนมัติมากกว่าด้วยตนเองฉันคิดว่าเทรวิส (ระบบ CI สำหรับ GitHub) จะทำสิ่งที่คุณต้องการ - มันจะทำการทดสอบโดยอัตโนมัติสำหรับคำขอดึงทั้งหมด ( ข้อมูลเพิ่มเติมเกี่ยวกับกระบวนการนี้รวมถึงภาพหน้าจอ )

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

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

— MJS
แหล่งที่มา

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

— Ash

@Ash รหัสไม่ได้ผสานเข้ากับ master จริง ๆ ; ตามที่ฉันเข้าใจแล้วการทดสอบนั้นดำเนินการในสาขาชั่วคราวซึ่งเป็นผลมาจากการรวมสาขาย่อยภายใต้การทดสอบเข้ากับต้นแบบ

— mjs