กลยุทธ์การแยกส่วน Git ที่รวมเข้ากับกระบวนการทดสอบ / QA

131

ทีมพัฒนาของเราใช้กลยุทธ์GitFlow branching และมันยอดเยี่ยมมาก!

เมื่อเร็ว ๆ นี้เราได้คัดเลือกผู้ทดสอบสองรายเพื่อปรับปรุงคุณภาพซอฟต์แวร์ของเรา แนวคิดคือผู้ทดสอบทุกคนควรทดสอบ / QA

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

ผู้ทดสอบควรทดสอบคุณสมบัติใหม่ในสาขาใด

เห็นได้ชัดว่ามีสองทางเลือก:

  • ในแต่ละสาขาคุณลักษณะ
  • ในdevelopสาขา

การทดสอบในสาขาการพัฒนา

ในขั้นต้นเราเชื่อว่านี่เป็นวิธีที่แน่นอนเพราะ:

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

ปัญหาที่ใหญ่ที่สุดคือ:

  • developสาขาปนเปื้อนมีข้อบกพร่อง

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

การทดสอบในสาขาคุณลักษณะ

ดังนั้นเราจึงคิดอีกครั้งและตัดสินใจว่าเราควรทดสอบฟีเจอร์ในสาขาฟีเจอร์ ก่อนที่เราจะทดสอบเราจะรวมการเปลี่ยนแปลงจากdevelopสาขาไปยังสาขาคุณลักษณะ (ตามลำดับdevelopสาขา) ดีจัง:

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

อย่างไรก็ตามมีข้อบกพร่องบางประการ

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

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

git  testing  qa  git-flow 
— เดวิดลิน
แหล่งที่มา
5
คำถามนี้ดูเหมือนจะเหมาะกว่าสำหรับโปรแกรมเมอร์เนื่องจากไม่ได้จัดการกับปัญหาการเขียนโปรแกรม แต่เป็นกระบวนการพัฒนามากกว่า ใครสามารถย้ายข้อมูลได้หรือไม่?
4
— Joshua Goldberg
2
รุ่นเราเหมือนกันเป๊ะ ฉันสนใจที่จะรับทราบว่าทีม QA ของคุณรายงานปัญหาเกี่ยวกับสาขาคุณลักษณะที่แตกต่างจากปัญหาในสนามหรือปัญหาในระหว่างกระบวนการ UAT อย่างไร (หากคุณมี) เราใช้ Atlassian JIRA และเรามีขั้นตอนการทำงานที่แตกต่างกันสำหรับทั้งสอง
— void.pointer
2
ตัดสินใจในสิ่งเดียวกันในขณะนี้ นอกจากนี้เนื่องจากสภาพแวดล้อมของเราเป็นแอปพลิเคชัน java spring จึงใช้เวลาประมาณ 20 นาทีในการสร้างและปรับใช้เพื่อทดสอบสภาพแวดล้อม มีคนที่มีความสุขถามข้อสงสัยเดียวกันกับฉัน
— digao_mb
ข้อเสียเปรียบประการแรกไม่ได้อยู่ที่กระบวนการทดสอบในสาขาคุณลักษณะ เครื่องมือเช่น Github Enterprise และ Bitbucket มีความสามารถในการขออนุมัติสำหรับคำขอดึงและผู้รับผิดชอบด้าน QA สามารถอนุมัติการส่งสัญญาณไปยังผู้พัฒนาว่ามีอิสระที่จะรวมเข้ากับการพัฒนา
— Derek Greer

คำตอบ:

102

วิธีที่เราทำมีดังต่อไปนี้:

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

  1. นักพัฒนาสร้างสาขาคุณลักษณะสำหรับทุกคุณลักษณะใหม่
  2. สาขาคุณลักษณะถูกปรับใช้ (โดยอัตโนมัติ) ในสภาพแวดล้อมการทดสอบของเราโดยทุกคอมมิตเพื่อให้นักพัฒนาทำการทดสอบ
  3. เมื่อนักพัฒนาเสร็จสิ้นในการปรับใช้และคุณลักษณะนั้นพร้อมที่จะทดสอบเขาจะรวมสาขาการพัฒนาในสาขาคุณลักษณะและปรับใช้สาขาคุณลักษณะที่มีการเปลี่ยนแปลงการพัฒนาล่าสุดทั้งหมดใน TEST
  4. ผู้ทดสอบทำการทดสอบใน TEST เมื่อเขาทำเสร็จแล้วเขาจะ "ยอมรับ" เรื่องราวและรวมสาขาคุณลักษณะในการพัฒนา เนื่องจากก่อนหน้านี้ผู้พัฒนาได้รวมสาขาการพัฒนากับคุณลักษณะโดยปกติแล้วเราจึงไม่คาดว่าจะมีข้อขัดแย้งมากเกินไป อย่างไรก็ตามหากเป็นเช่นนั้นนักพัฒนาสามารถช่วยได้ นี่เป็นขั้นตอนที่ยุ่งยากฉันคิดว่าวิธีที่ดีที่สุดในการหลีกเลี่ยงคือการรักษาคุณลักษณะให้เล็ก / เฉพาะเจาะจงที่สุดเท่าที่จะทำได้ ในที่สุดคุณลักษณะต่างๆจะต้องถูกรวมเข้าด้วยกันไม่ทางใดก็ทางหนึ่ง แน่นอนว่าขนาดของทีมมีบทบาทต่อความซับซ้อนของขั้นตอนนี้
  5. สาขาการพัฒนายังถูกปรับใช้ (โดยอัตโนมัติ) บน TEST เรามีนโยบายว่าแม้ว่าการสร้างสาขาคุณลักษณะจะล้มเหลวสาขาการพัฒนาก็ไม่ควรล้มเหลว
  6. เมื่อเรามาถึงจุดหยุดคุณสมบัติแล้วเราจะสร้างรุ่นจากการพัฒนา สิ่งนี้ทำให้ใช้งานได้โดยอัตโนมัติบน STAGING การทดสอบตั้งแต่ต้นจนจบอย่างครอบคลุมจะเกิดขึ้นที่นั่นก่อนการปรับใช้การผลิต (โอเคบางทีฉันพูดเกินจริงไปหน่อยพวกเขาไม่ได้กว้างขวางมากนัก แต่ฉันคิดว่ามันควรจะเป็น) ผู้ทดสอบ / เพื่อนร่วมงานรุ่นเบต้าตามอุดมคติเช่นผู้ใช้จริงควรทดสอบที่นั่น

คุณคิดอย่างไรกับแนวทางนี้?

— Aspasia
แหล่งที่มา
2
เราจะแน่ใจได้อย่างไรว่า feature1 และ feature2 ที่ได้รับการทดสอบโดยอิสระนั้นเข้ากันได้ดี (ดังที่กล่าวไว้ในคำถาม)
— Kumar Deepak
2
เราทำทางอ้อมโดยการรวมหนึ่งแล้วอีกอันหนึ่งเพื่อพัฒนา เป็นขั้นตอนที่ 4 ของกระบวนการข้างต้นและเกี่ยวข้องกับลำดับเวลา ดังนั้นหากฟีเจอร์ 2 พร้อมที่จะรวมเข้าด้วยกัน แต่ฟีเจอร์ 1 ถูกรวมเข้าด้วยกันแล้วผู้พัฒนาและผู้ทดสอบฟีเจอร์ 2 ต้องตรวจสอบให้แน่ใจว่าการผสานจะทำงานได้
— Aspasia
1
ฉันคิดว่าอย่างไรก็ตามตามโมเดลการแยกส่วนคอมไพล์นี้คุณไม่ควรรวมสองสาขาคุณสมบัติเข้าด้วยกัน
— Aspasia
1
เราประสบปัญหาในขั้นตอนที่ 6 โดยเฉพาะอย่างยิ่งในช่วงเวลาที่มีการหยุดทำงานซึ่งมีการย้ายฟีเจอร์หลายรายการไปพัฒนาเนื่องจากการผสานที่ไม่สำคัญซึ่งเกิดขึ้นหลังจากที่ QA ได้ลงชื่อออกในสาขาคุณลักษณะแม้ว่าจะรวม devlop เข้ากับฟีเจอร์ช้าที่สุดก็ตาม ฉันแสดงความคิดเห็นในรายละเอียดเพิ่มเติมที่นี่: stackoverflow.com/a/25247382/411282
— Joshua Goldberg
8
คุณมี TEST Environment (DB, Server, Client และอื่น ๆ ) สำหรับแต่ละสาขาฟีเจอร์หรือไม่ หรือพวกเขาแชร์สภาพแวดล้อมและมีชื่อที่แตกต่างกัน (เช่น app-name_feature1- app-name_feature2 เป็นต้น)
— hinneLinks
41

ก่อนการทดสอบเรารวมการเปลี่ยนแปลงจากสาขาการพัฒนาไปยังสาขาคุณลักษณะ

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

ทำให้นักพัฒนาทำการrebase ของfeatureสาขาของตนที่ด้านบนdevelและผลักดันfeatureสาขานั้น (ซึ่งได้รับการตรวจสอบโดยนักพัฒนาว่ารวบรวมและทำงานกับdevelสถานะสาขาล่าสุด)
ที่ช่วยให้:

  • การผสานรวมที่ง่ายมากในสาขาคุณลักษณะ (การผสานไปข้างหน้าอย่างรวดเร็วเล็กน้อย)
  • หรือตามคำแนะนำของAspasiaด้านล่างในการแสดงความคิดเห็นเป็นคำขอดึง (GitHub)หรือคำขอผสาน (GitLab) : ผู้ดูแลไม่ผสานระหว่างคุณลักษณะสาขาประชาสัมพันธ์ / MR และdevelopแต่ถ้าไม่ได้มีการตรวจพบความขัดแย้งโดย GitHub / GitLab

ทุกครั้งที่ผู้ทดสอบตรวจพบข้อบกพร่องผู้ทดสอบจะรายงานให้ผู้พัฒนาทราบและลบสาขาคุณลักษณะปัจจุบัน
ผู้พัฒนาสามารถ:

  • แก้ไขข้อบกพร่อง
  • rebase ที่ด้านบนของสาขาการพัฒนาที่เพิ่งดึงมา (อีกครั้งเพื่อให้แน่ใจว่าโค้ดของเขา / เธอทำงานร่วมกับคุณสมบัติอื่น ๆ ที่ได้รับการตรวจสอบแล้ว)
  • ผลักดันfeatureสาขา

แนวคิดทั่วไป: ตรวจสอบให้แน่ใจว่าผู้พัฒนาทำส่วนการผสาน / การรวมเข้าด้วยกันโดยปล่อยการทดสอบไปยัง QA

— VonC
แหล่งที่มา
คุณกำลังบอกว่า "ไม่ใช้การผสานใช้ rebase แทน" ใช่ไหม ถ้าเป็นเช่นนั้นฉันสับสนเนื่องจากคำถามที่พบบ่อยของ Git เกี่ยวกับความแตกต่างระหว่างทั้งสอง: git.wiki.kernel.org/index.php/…
— Vicki Laidler
1
@VickiLaidler ใช่หาก QA ปฏิเสธสาขาคุณลักษณะผู้พัฒนาจะต้อง rebase ไม่ใช่ผสาน ( stackoverflow.com/a/804178/6309 )
— VonC
1
@VonC ฉันเห็นด้วยอย่างยิ่ง แต่มีปัญหาบางประการ: 1) การลบสาขาจะส่งผลกระทบต่อเครื่องมืออื่น ๆ เช่นคำขอดึงที่เก็บ (การลบสาขาเป็นการปิด PR) ชอบแรงผลัก 2) หากเป็นสาขาคุณลักษณะขนาดใหญ่ที่มีคนสองคนทำงานร่วมกันในช่วงชีวิตการรวมจะเป็นที่ต้องการมากกว่าการคืนเงิน การเปลี่ยนใหม่ในตอนท้ายจะทำให้เกิดฝันร้ายของความขัดแย้งเนื่องจากการรวมคอมมิชชันจะถูกลบออกและหากโค้ดขึ้นอยู่กับการเปลี่ยนแปลงการผสานเหล่านั้นการแก้ไขก็ไม่สำคัญ
— void.pointer
1
เมื่อมองย้อนกลับไปที่คำตอบของฉันฉันก็จะทำการ rebase และไม่ใช่การรวมเพื่อประวัติศาสตร์ที่สะอาดกว่า
— Aspasia
1
@Aspasia จุดดี. ฉันได้รวมคำขอดึงไว้ในคำตอบเพื่อให้มองเห็นได้มากขึ้น
— VonC
12

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

พึ่งพาการทดสอบอัตโนมัติให้มากที่สุดและเริ่มการสร้างโดยอัตโนมัติด้วยการทดสอบหน่วยโดย Jenkins ให้นักพัฒนาดำเนินการทั้งหมดโดยรวมการเปลี่ยนแปลงเข้ากับสาขาหลักและจัดเตรียมการทดสอบหน่วยสำหรับโค้ดทั้งหมดของพวกเขา

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

สำหรับข้อมูลเพิ่มเติมโปรดดูที่ลิงค์นี้

— จอห์นนี่ซี
แหล่งที่มา
คุณยังสามารถทำ CI ด้วยกิ่งไม้ + การรีเบตใน Git
— void.pointer
9

เราใช้สิ่งที่เรียกว่า "ทอง" "เงิน" และ "บรอนซ์" สิ่งนี้อาจเรียกว่า prod, staging และ qa

ฉันเรียกสิ่งนี้ว่าโมเดลหลอม มันทำงานได้ดีสำหรับเราเพราะเรามีความต้องการ QA อย่างมากในด้านธุรกิจเนื่องจากข้อกำหนดอาจเข้าใจยากเทียบกับเทคนิค

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

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

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

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

การแก้ไขฉุกเฉินจะถูกเสียบเข้ากับต้นไม้ทองโดยตรง หากการเปลี่ยนแปลงนั้นง่ายและยากสำหรับ QA ก็สามารถเปลี่ยนเป็นสีเงินได้โดยตรงซึ่งจะหาทางไปยังแผนภูมิทดสอบ

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

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

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

"การอบ" ก็เป็นผลข้างเคียงที่ดีเช่นกัน หากคุณมีการเปลี่ยนแปลงพื้นฐานบางอย่างที่คุณต้องการปล่อยให้นั่งสักพักมีสถานที่ที่ดีสำหรับมัน

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

— Eric Twilegar
แหล่งที่มา
1

ฉันจะไม่พึ่งพาการทดสอบด้วยตนเองเพียงอย่างเดียว ฉันจะทำการทดสอบฟีเจอร์แต่ละสาขาโดยอัตโนมัติกับ Jenkins ฉันตั้งค่าห้องปฏิบัติการ VMWare เพื่อเรียกใช้การทดสอบ Jenkins บน Linux และ Windows สำหรับเบราว์เซอร์ทั้งหมด เป็นโซลูชันการทดสอบข้ามเบราว์เซอร์ที่ยอดเยี่ยมอย่างแท้จริง ฉันทดสอบฟังก์ชัน / การทำงานร่วมกับ Selenium Webdriver การทดสอบซีลีเนียมของฉันทำงานภายใต้ Rspec และฉันเขียนไว้เป็นพิเศษเพื่อให้ jRuby โหลดบน Windows ฉันเรียกใช้การทดสอบหน่วยแบบดั้งเดิมภายใต้การทดสอบ Rspec และ Javascript ภายใต้ Jasmine ฉันตั้งค่าการทดสอบแบบไร้หัวด้วย Phantom JS

— Natus Drew
แหล่งที่มา
1

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

แนวทางของเราในการทำงานกับ GIT คือ

เราได้นำ "Git Flow" มาใช้ใน บริษัท ของเรา เราใช้ JIRA และเฉพาะตั๋ว JIRA ที่ได้รับอนุมัติเท่านั้นที่ควรนำไปผลิต สำหรับการอนุมัติการทดสอบเราขยายด้วยการสร้างสาขาการทดสอบแยกต่างหาก

ขั้นตอนในการประมวลผลตั๋ว JIRA ได้แก่ :

  1. สร้างสาขาใหม่จาก Develop-Branch
  2. ทำการเปลี่ยนแปลงโค้ดใน Feature-Branch
  3. ดึงจากคุณลักษณะการเปลี่ยนแปลงสาขาการทดสอบ / QA
  4. หลังจากการอนุมัติทางธุรกิจเราจะดึงการเปลี่ยนแปลงจากสาขาคุณลักษณะมาพัฒนา
  5. การพัฒนาเกิดขึ้นบ่อยครั้งในการเปิดตัวและในที่สุดก็เป็นสาขาหลัก

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

กระบวนการทั้งหมดมีลักษณะดังนี้: ใส่คำอธิบายภาพที่นี่

— Christian Müller
แหล่งที่มา
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.