คำถามติดแท็ก branching

การแยกในการควบคุมการแก้ไขคือการทำซ้ำของวัตถุภายใต้การควบคุมการแก้ไขเพื่อให้การแก้ไขสามารถเกิดขึ้นในแบบคู่ขนานไปตามกิ่งไม้ทั้งสอง

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

10
คุณจะหลีกเลี่ยงการทำงานผิดสาขาได้อย่างไร
ความระมัดระวังมักเพียงพอที่จะป้องกันปัญหา แต่บางครั้งฉันต้องตรวจสอบสาขาที่ฉันกำลังทำงานอยู่ ( เช่น "อืม ... ฉันอยู่ในdevสาขาใช่มั้ย") โดยการตรวจสอบเส้นทางการควบคุมของแหล่งสุ่ม ไฟล์. ในการมองหาวิธีที่ง่ายขึ้นฉันคิดว่าตั้งชื่อไฟล์โซลูชันตามนั้น ( เช่น MySolution_Dev.sln ) แต่ด้วยชื่อไฟล์ที่แตกต่างกันในแต่ละสาขาฉันไม่สามารถรวมไฟล์โซลูชันได้ มันไม่ได้เป็นเรื่องใหญ่ แต่มีวิธีการหรือ "เคล็ดลับเล็ก ๆ " ที่คุณใช้เพื่อให้แน่ใจว่าคุณอยู่ในสาขาที่ถูกต้องหรือไม่? ฉันใช้ Visual Studio 2010 กับ TFS 2008

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

6
เมื่อใดฉันจึงควรหยุดที่จะให้ความสำคัญกับโครงการใหม่
เมื่อใดก็ตามที่โครงการใหม่เริ่มต้นขึ้นคุณจะต้องเริ่มต้นจากตรงไปที่ต้นแบบจนกว่าคุณจะมีอะไรที่ "มั่นคง" จากนั้นคุณก็เริ่มทำงานในสาขา อย่างน้อยนี่เป็นวิธีที่ฉันทำตามปกติ มีวิธีในการเริ่มกิ่งทันทีจากการกระทำที่สอง? มันสมเหตุสมผลไหมที่จะทำอย่างนี้? เห็นได้ชัดว่า "Initial Commit" จะเป็นผู้เชี่ยวชาญเสมอ แต่หลังจากนั้นฉันจะรู้ได้อย่างไรว่าถึงเวลาที่เหมาะสมที่จะเริ่มสร้างสาขาสำหรับคุณสมบัติใหม่

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

7
ทำอย่างไรจึงจะรักษาประสิทธิภาพได้เมื่องานสร้างเสียหายเกือบตลอดเวลา
ฉันทำงานในทีมขนาดกลางซึ่งแบ่งปันซอร์สโค้ดเดียวกันและในขณะที่ยังคงมีการรวมเข้าด้วยกัน แต่เนื่องจากเราทุกคนต้องทำงานในสาขาเดียวกันการสร้างจึงไม่สามารถทำได้ ในขณะที่เรามีกฎที่ได้รับการแนะนำเมื่อเร็ว ๆ นี้เพื่อบรรเทาการสร้างที่เสียหายซึ่งระบุว่าไม่มีใครได้รับอนุญาตให้เช็คอินในขณะที่การสร้างเป็นสีแดง ต้องบอกว่าในระหว่างวันทุกคนมีหน้าต่างประมาณ 10-15 นาทีซึ่งเราอนุญาตให้เช็คอิน และเมื่อทีมเติบโตขึ้นหน้าต่างของโอกาสในการเช็คอินจะลดลงมากยิ่งขึ้น ที่บังคับให้นักพัฒนาสะสมการเปลี่ยนแปลงในพื้นที่ซึ่งส่งผลให้เกิดการเปลี่ยนแปลงที่ยิ่งใหญ่ซึ่งยากยิ่งกว่าที่จะมั่นใจได้ว่าการเปลี่ยนแปลงจะไม่ทำลายอะไรเลย คุณสามารถดูวงจรอุบาทว์ คุณสามารถแนะนำอะไรให้ฉันทำงานอย่างมีประสิทธิภาพในสภาพแวดล้อมเช่นนี้ นอกจากนี้โปรดทราบว่าฉันเป็นนักพัฒนาไม่ใช่ผู้จัดการและไม่สามารถเปลี่ยนกระบวนการหรือพฤติกรรมของคนอื่นได้มาก

4
คุณจะวางไลบรารี่ต่าง ๆ ในการควบคุมเวอร์ชันได้อย่างไร? คุณใช้แท็กหรือไม่ หรือสาขา หรือวิธีอื่น
ฉันเพิ่งเริ่มวางโค้ดของฉันภายใต้การควบคุมเวอร์ชัน (ในแล็บที่ฉันทำงานอยู่ภายใต้ SVN และรหัสของฉันเองใน GitHub (เห็นได้ชัดกับ git) ก่อนที่จะใช้การควบคุมเวอร์ชันฉันเคยทำอะไรแบบนี้ ฉันมีโฟลเดอร์ชื่อห้องสมุดในหลาย ๆ โฟลเดอร์ที่มีหมายเลขเวอร์ชัน ทุกครั้งที่ฉันต้องการเริ่มทำงานกับเวอร์ชันที่ใหม่กว่าฉันจะทำสำเนาของเวอร์ชันล่าสุดเปลี่ยนชื่อเป็นเวอร์ชันใหม่และเริ่มนำไปใช้ อย่างไรก็ตามวิธีนี้ดูเหมือนจะซ้ำซ้อนเมื่อโฟลเดอร์อยู่ภายใต้การควบคุมเวอร์ชัน นอกเหนือจากความซ้ำซ้อนหากมีคนต้องการรับรุ่นล่าสุดพวกเขาจะดาวน์โหลดทุกรุ่นถ้าเขาเพียงแค่imports / clones ตอนนี้ฉันเห็นหลายวิธีในการทำเช่นนี้ด้วยการควบคุมเวอร์ชัน แต่เนื่องจากฉันใหม่สำหรับมันฉันไม่ทราบว่าจะบำรุงรักษาได้ดีกว่า วิธีที่ 1: ใช้แท็ก หากฉันเข้าใจแท็กอย่างถูกต้องคุณจะมีสาขาหลักของคุณคุณยอมรับการเปลี่ยนแปลงใด ๆ ที่คุณได้รับและแท็กด้วยเวอร์ชัน จากนั้นเมื่อคุณต้องการได้รับสำเนาที่ใช้งานได้คุณจะได้รับแท็กที่แน่นอน (ช่วยแก้ให้ด้วยนะถ้าฉันผิด) วิธีที่ 2: เวอร์ชันการแยกสาขา ในวิธีนี้สาขาหลักจะเป็นสาขาการพัฒนา ทุก ๆ ครั้งที่มีการสร้างเวอร์ชันที่เสถียร (สมมติว่าv1.2.0) คุณสร้างสาขาสำหรับเวอร์ชันนั้นและไม่ผูกมัด ด้วยวิธีนี้หากคุณต้องการดาวน์โหลดเวอร์ชันใดรุ่นหนึ่งคุณจะได้รับรหัสจากสาขานั้น แม้ว่าฉันจะบอกว่าคุณไม่เคยยอมทำ แต่ก็เป็นไปได้ที่จะแก้ไขข้อผิดพลาดและผูกมัดกับสาขาของรุ่นเก่าเพื่อให้รุ่นเก่าทำงานต่อไป ตัวอย่างเช่นหากรุ่นปัจจุบันคือv2.0แต่มีคนที่ต้องการใช้v1.2คุณสามารถรับสาขาอื่นจากv1.2คือv1.2.1และกระทำการแก้ไขข้อบกพร่องหรือเพียงแค่ทำให้รุ่นเดียวกันv1.2และเพียงแค่แก้ไขข้อผิดพลาด ดังนั้นกิ่งจะเป็นดังนี้: v1.2.1 v1.2.2 / / v1.0.0 v1.2.0--------- v2.0.0 / / / …

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

3
ทีมงานควบคุมคุณภาพควรทำการทดสอบในรูปแบบการแยกสาขาของ Gitflow
เราเป็นทีมใหญ่ (นักพัฒนา 10-12 คนและ 4 คน) ทำงานหลายโครงการด้วยที่เก็บ git เดียวกัน มันเป็นบริการเว็บแบ็กเอนด์ในฤดูใบไม้ผลิตาม เรากำลังมองหาการแยกทางและใช้กลยุทธ์ที่ดี นอกจากนี้เรายังมีทีมงาน qa ที่ทำให้มั่นใจว่าคุณสมบัติของเราทำงานได้ตามที่คาดไว้ (ปราศจากข้อบกพร่องในระดับหนึ่ง) หลังจากอ่านบทความไม่กี่ฉันรู้สึกว่าแบบจำลองGitflowทำงานได้ดีสำหรับเรา ที่นี่คำถามของฉันมา ทีม QA ของเราควรทดสอบคุณสมบัติของเราที่ไหน? พวกเขาควรทดสอบสาขาคุณลักษณะที่พวกเขาจะเพิ่มข้อผิดพลาดและนักพัฒนาจะแก้ไขและเมื่อผ่านการทดสอบ QA เรารวมการพัฒนา และ QA จะทำการทดสอบจำนวนเต็มอีกครั้งในสาขาที่กำลังพัฒนา เราควรรวมคุณสมบัติทั้งหมด (หลังการทดสอบหน่วยและการทดสอบพื้นฐานจากผู้พัฒนา) เพื่อพัฒนาสาขาและให้ทดสอบ qa จากที่นั่น การแก้ไขและการทดสอบทั้งหมดจะเกิดขึ้นในการพัฒนาเช่นกัน ฉันอยากรู้ว่าวิธีการใดที่ทำงานได้ดีสำหรับผู้อื่น
23 testing  git  branching  qa  gitflow 

3
กลยุทธ์สำหรับการตรวจสอบโค้ดก่อนที่จะรวมไปถึงต้นแบบจากสาขาคุณลักษณะ
ฉันและทีมของฉันใช้สาขาคุณลักษณะ (พร้อมคอมไพล์) ฉันสงสัยว่าเป็นกลยุทธ์ที่ดีที่สุดในการตรวจสอบโค้ดก่อนที่จะรวมกันเป็นหลัก ฉันเช็คเอ้าท์สาขาใหม่จากหลักให้เรียกมันว่า fb_ # 1 ฉันส่งไปสองสามครั้งและต้องการรวมกลับเป็นหลัก ก่อนที่ฉันจะรวมใครบางคนควรทำการตรวจทานโค้ด ตอนนี้มีความเป็นไปได้ 2 แบบ: 1 ฉันรวมต้นแบบเข้ากับ fb_ # 1 ( ไม่ใช่ fb_ # 1 เป็นหลัก) เพื่อทำให้ทันสมัยที่สุด เพื่อนร่วมทีมจะตรวจทานการเปลี่ยนแปลงระหว่างหัวหน้าหลักและหัวหน้า fb_ # 1 หาก fb_ # 1 ไม่เป็นไรเราจะรวม fb_ # 1 เป็นหลัก ข้อดี: ไม่มีรหัสที่ล้าสมัยในการตรวจสอบ ข้อด้อย: ถ้ามีคนอื่นรวมบางอย่างระหว่าง "1. " และ "2. " การเปลี่ยนแปลงของเขาจะปรากฏในการตรวจสอบแม้ว่าจะเป็นของการตรวจสอบอื่น ครั้งที่ 2 เพื่อนร่วมทีมตรวจสอบการเปลี่ยนแปลงระหว่างจุดชำระเงิน …

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

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

5
ทำไมคอมไพล์จึงไม่บรรจุชื่อสาขาที่สร้างขึ้น?
เมื่อทำงานกับคอมไพล์ในทีมที่ใช้ฟีเจอร์บรานช์ฉันมักจะพบว่ามันยากที่จะเข้าใจโครงสร้างสาขาในประวัติศาสตร์ ตัวอย่าง: สมมติว่ามีฟีเจอร์ branch / make-coffeeฟีเจอร์และการแก้ไขข้อผิดพลาดยังคงดำเนินต่อไปบนมาสเตอร์ขนานกับฟีเจอร์ branch ประวัติอาจมีลักษณะเช่นนี้: * merge feature/make-coffee |\ | * small bugfix | | * | fix bug #1234 | | | * add milk and sugar | | * | improve comments | | * | fix bug #9434 | | | * make coffe …
20 git  branching 

2
ใน git มันเป็นความคิดที่ดีที่จะสร้างแท็กที่มีชื่อเดียวกันกับสาขาที่ถูกลบหรือไม่?
ผมมีโครงการที่มีการแตกแขนงคอมไพล์รูปแบบที่ประมาณดังนี้ว่าnvie ของคอมไพล์ไหล สาขาที่วางจำหน่ายของเรามีชื่ออยู่ในรูปแบบของSemVerเช่นv1.5.2 เมื่อสาขาย่อยได้รับไฟสีเขียวเพื่อการผลิตเราจะปิดสาขาโดยรวมมันเข้ากับต้นแบบใช้แท็กแล้วลบสาขา เมื่อเราลบสาขาที่วางจำหน่ายทันทีเราได้ใช้ตัวระบุเดียวกันสำหรับการติดแท็กสาขาเช่น v1.5.2 นี่คือคำสั่งที่เราใช้ปิดสาขาที่วางจำหน่าย: $ git checkout master $ git merge v1.5.2 $ git tag -a v1.5.2 -m "Version 1.5.2 - foo bar, baz, etc" $ git branch -d v1.5.2 $ git branch -dr origin/v1.5.2 $ git push origin :v1.5.2 $ git push $ git push --tags …

8
ป้องกันการแตกกิ่งก้านสาขา
เราเริ่มพบปัญหาในขณะที่เรามีขนาดใหญ่ขึ้นซึ่งฟีเจอร์ทำให้เป็นระยะสำหรับการทดสอบ แต่เมื่อถึงเวลาที่ทุกอย่างผ่านการทดสอบและได้รับการอนุมัติฟีเจอร์ใหม่ก็จะอยู่ในระยะสำหรับการทดสอบ สิ่งนี้กำลังสร้างสภาพแวดล้อมที่เราแทบจะไม่สามารถผลักดันไปสู่การผลิตได้เพราะเรามีการผสมผสานระหว่างคุณสมบัติที่ผ่านการทดสอบและไม่ได้ทดสอบแล้ว ฉันแน่ใจว่านี่เป็นปัญหาทั่วไป แต่ฉันยังไม่พบแหล่งข้อมูลที่ดีสำหรับเรา เฉพาะบางส่วน: GIT บน BitBucket Jenkins สำหรับการปรับใช้สคริปต์กับ Azure สิ่งที่ฉันหวังไว้คือวิธีที่จะแยกคุณสมบัติเมื่อมันเคลื่อนที่ผ่านสภาพแวดล้อมและผลักดันสิ่งที่พร้อมจะแยงเท่านั้น

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