ฉันจะโน้มน้าวให้โปรแกรมเมอร์คาวบอยใช้การควบคุมแหล่งที่มาได้อย่างไร

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

• ทีมที่ไม่ได้ใช้ในการใช้TFS ฉันมีการฝึกอบรม 2 ครั้ง แต่ได้รับการจัดสรรเพียง 1 ชั่วโมงเท่านั้นซึ่งไม่เพียงพอ
• สมาชิกในทีมปรับเปลี่ยนรหัสบนเซิร์ฟเวอร์โดยตรง สิ่งนี้จะทำให้รหัสไม่ซิงค์กัน ต้องการการเปรียบเทียบเพื่อให้แน่ใจว่าคุณกำลังทำงานกับรหัสล่าสุด และปัญหาการรวมที่ซับซ้อนเกิดขึ้น
• การประเมินเวลาที่นักพัฒนาซอฟต์แวร์นำเสนอไม่รวมเวลาที่ต้องใช้ในการแก้ไขปัญหาเหล่านี้ ดังนั้นถ้าฉันบอกว่าไม่ใช่จะใช้เวลานานกว่า 10 เท่า ... ฉันต้องอธิบายปัญหาเหล่านี้อย่างต่อเนื่องและเสี่ยงตัวเองเพราะตอนนี้ผู้บริหารอาจมองฉันว่า "ช้า"
• ฟิสิคัลไฟล์บนเซิร์ฟเวอร์แตกต่างกันในวิธีที่ไม่รู้จักมากกว่า ~ 100 ไฟล์ การผสานต้องการความรู้เกี่ยวกับโครงการในมือและดังนั้นความร่วมมือของนักพัฒนาซอฟต์แวร์ซึ่งฉันไม่สามารถทำได้
• โครงการอื่น ๆ หลุดออกจากกัน นักพัฒนายังคงมีความไม่ไว้วางใจในการควบคุมแหล่งที่มาและทำให้เกิดปัญหาโดยไม่ได้ใช้ตัวควบคุมแหล่งที่มา
• นักพัฒนาให้เหตุผลว่าการใช้การควบคุมแหล่งที่มานั้นสิ้นเปลืองเพราะการผสานนั้นเกิดข้อผิดพลาดได้ง่ายและยาก นี่เป็นจุดที่ยากที่จะโต้แย้งเนื่องจากเมื่อการควบคุมแหล่งที่มานั้นไม่ถูกต้องใช้อย่างไม่ถูกต้องและการควบคุมแหล่งที่มาข้ามอย่างต่อเนื่องมันเป็นข้อผิดพลาดได้ง่ายแน่นอน ดังนั้นหลักฐาน "พูดเพื่อตัวเอง" ในมุมมองของพวกเขา
• นักพัฒนายืนยันว่าการปรับเปลี่ยนรหัสเซิร์ฟเวอร์โดยตรงการเลี่ยง TFS จะช่วยประหยัดเวลา นี่เป็นเรื่องยากที่จะโต้แย้ง เนื่องจากการรวมที่จำเป็นในการซิงโครไนซ์รหัสที่จะเริ่มต้นนั้นใช้เวลานาน ทวีคูณโดย 10+ โครงการที่เราบริหาร
• ไฟล์ถาวรมักถูกเก็บไว้ในไดเรกทอรีเดียวกับโครงการเว็บ ดังนั้นการเผยแพร่ (การเผยแพร่เต็มรูปแบบ) จะลบไฟล์เหล่านี้ที่ไม่ได้อยู่ในการควบคุมแหล่งที่มา สิ่งนี้ยังทำให้เกิดความไม่ไว้วางใจในการควบคุมแหล่งข้อมูล เนื่องจาก "การเผยแพร่การแบ่งโครงการ" การแก้ไขนี้ (การย้ายไฟล์ที่เก็บไว้ออกจากโฟลเดอร์ย่อยของโซลูชัน) ใช้เวลานานและทำการดีบั๊กเนื่องจากตำแหน่งเหล่านี้ไม่ได้ตั้งค่าไว้ใน web.config และมักจะมีอยู่ในจุดรหัสหลาย ๆ จุด

ดังนั้นวัฒนธรรมยังคงมีอยู่ การฝึกฝนที่ไม่ดีทำให้เกิดการฝึกฝนที่ไม่ดีมากขึ้น การแก้ปัญหาที่ไม่ดีทำให้เกิดแฮ็กใหม่เพื่อ "แก้ไขปัญหา" ที่ลึกกว่าและใช้เวลานานกว่า เซิร์ฟเวอร์พื้นที่ของฮาร์ดไดรฟ์นั้นยากมากที่จะเกิดขึ้น แต่ความคาดหวังของผู้ใช้เพิ่มขึ้น

สิ่งที่สามารถทำได้ในสถานการณ์นี้?

มันไม่ได้เป็นปัญหาการฝึกอบรม แต่เป็นประเด็นปัจจัยมนุษย์ พวกเขาไม่ต้องการและกำลังสร้างบล็อกถนน จัดการกับพลวัตของกลุ่มที่แตกสลายสาเหตุของการคัดค้านของพวกเขาคืออะไร - มักจะกลัวนั่นเป็นเพียงความกลัวต่อการเปลี่ยนแปลงหรือเป็นเรื่องที่น่ากลัวมากกว่า

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

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

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

การผสานจะไม่เพียง แต่มีความรู้ที่ดีของโครงการ

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

ถ้าฉันเป็นคุณฉันจะพิจารณาโอกาสในการทำงานของฉัน ...

บางครั้งปัญหาในโลกแห่งความจริงทำให้ไม่สามารถใช้งานได้จริง

เท็จ

หากทีมไม่คุ้นเคยกับการใช้การควบคุมแหล่งที่มาปัญหาการฝึกอบรมอาจเกิดขึ้นได้

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

ถ้าสมาชิกในทีมปรับเปลี่ยนรหัสบนเซิร์ฟเวอร์โดยตรงปัญหาต่าง ๆ สามารถเกิดขึ้นได้

นั่นคือปัญหาการฝึกอบรม อีกครั้ง ไม่มีส่วนเกี่ยวข้องกับการควบคุมซอร์สโค้ดและทุกอย่างเกี่ยวกับการฝึกอบรม

นักพัฒนายังคงมีความไม่ไว้วางใจในการควบคุมแหล่งที่มาและทำให้เกิดปัญหาโดยไม่ได้ใช้ตัวควบคุมแหล่งที่มา

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

สิ่งที่สามารถทำได้ในสถานการณ์ประเภทนี้?

เริ่มการฝึกอบรมทุกคนเกี่ยวกับวิธีใช้การควบคุมซอร์สโค้ด

ปรับปรุง

นักพัฒนายืนยันว่าการปรับเปลี่ยนการควบคุมแหล่งที่มาโดยตรงช่วยประหยัดเวลา

เนื่องจากมันผิดดังนั้นการรวบรวมข้อมูลเพื่อแสดงให้เห็นอย่างแม่นยำว่ามันผิดอย่างไร

อย่างไรก็ตามน่าเสียดายที่ฝ่ายบริหารดูเหมือนจะให้รางวัลแก่การตอบสนองทันทีที่มีค่าใช้จ่ายสูงในระยะยาว

วิธีเดียวที่จะเอาชนะระบบรางวัลนี้ได้คือ

A) ระบุว่าต้นทุนระยะยาวสูงกว่ามูลค่าระยะสั้นที่ชัดเจน

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

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

D) ฝึกฝนผู้คนในรางวัลที่คุณพบในระยะยาว มูลค่าซึ่งชัดเจนกว่าการตอบสนองอย่างรวดเร็วในระยะสั้น

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

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

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

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

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

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

หากไม่สำเร็จให้เรียกใช้

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

ผู้คนมีแนวโน้มที่จะตอบสนองต่อตัวอย่างที่ดีกว่าการมองเห็นดังนั้นฉันขอแนะนำ "แก้ไข" ด้วยตัวคุณเอง:

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

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

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

ถ้าทุกอย่างดูเหมือนว่าจะพยายามมากเกินไป (ตามที่ได้กล่าวไว้ในคำตอบอื่น ๆ ทุกข้อ) - หางานอื่น พวกเขาไม่คุ้มค่ากับเวลาของคุณ

ขั้นตอนที่ 1 - ผู้จัดการไฟไร้ความสามารถ!

หากคุณไม่สามารถทำขั้นตอนที่ 1 ได้ให้พยายามให้ผู้จัดการ จำกัด การปรับใช้กับ prod เป็นสคริปต์ที่นำมาจากแหล่งควบคุมเท่านั้น หากนักพัฒนาซอฟต์แวร์ (ที่ไม่ควรมีสิทธิ์การผลิตใน prod ให้ดูขั้นตอนที่ 1 ถ้าพวกเขาต้องการ) สิ่งที่พวกเขาปรับใช้มันต้องมาจากการควบคุมแหล่งที่มา ที่แก้ไขปัญหาของเราที่ไม่ได้ใช้การควบคุมแหล่งที่มาค่อนข้างดีเมื่อเรา swtiched ครั้งแรกที่จะใช้มันสำหรับสิ่งที่ฐานข้อมูลเช่นเดียวกับรหัส C #

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

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

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

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

นอกเหนือจากการหางานใหม่ที่ชัดเจนฉันคิดว่าคำตอบคือทั้งหมดที่กล่าวมาข้างต้น

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

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

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

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

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

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

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

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

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

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

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

เราทำโครงการกับกลุ่มผู้รับเหมาคาวบอยที่ทำสิ่งเลวร้ายเหล่านั้นทั้งหมด ฉันใช้เวลา 4 สัปดาห์ในการทำความสะอาดหลังจากนั้นจากนั้นจึงวางแนวทางปฏิบัติด้านบน โครงการไม่มีปัญหากับสิ่งเหล่านี้ตั้งแต่นั้นมา

อ้างถึง:

ทีมไม่คุ้นเคยกับการใช้ TFS

TFS กลายเป็น Microsoft Team Foundation Server

สัญชาตญาณแรกของฉันบอกว่า: "นี่เป็น Microsoft Visual SourceSafe รุ่นล่าสุด"

ฉันจะเป็นเพื่อนร่วมงานของคุณและต่อต้านสิ่งนี้