เป็นเรื่องผิดปกติสำหรับ บริษัท ขนาดเล็ก (นักพัฒนา 15 คน) ที่จะไม่ใช้การควบคุมแหล่งที่มา / รุ่นที่จัดการหรือไม่ [ปิด]

ไม่ใช่คำถามทางเทคนิค แต่มีคำถามอื่น ๆ อีกมากมายเกี่ยวกับการควบคุมแหล่งที่มาและแนวปฏิบัติที่ดีที่สุด

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

ฉันพยายามผลักดันการควบคุมแหล่งที่มาที่มีการจัดการมาระยะหนึ่งแล้ว แต่ดูเหมือนว่าฉันจะไม่ได้รับการสนับสนุนเพียงพอภายใน บริษัท ข้อโต้แย้งหลักของฉันคือ:

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

คำถามของฉันคือ:

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

ฉันขอให้ส่วนใหญ่ได้รับความรู้สึกว่าทำไมฉันถึงมีความต้านทานมากดังนั้นโปรดตอบด้วยความจริงใจ

ฉันจะให้คำตอบกับคนที่ฉันเชื่อว่าใช้วิธีการที่สมดุลที่สุดและตอบคำถามทั้งสาม

ขอบคุณล่วงหน้า

1. มันอาจไม่ปกติแต่อย่างที่ Treb กล่าวมันอาจไม่ใช่เรื่องแปลก

2. อย่างที่คนอื่นพูดไม่มีเหตุผลที่ถูกต้องสำหรับการไม่มีแหล่งควบคุมใน บริษัท ของคุณ ดังนั้นคุณต้องระบุและโจมตีด้วยเหตุผลที่ไม่ถูกต้อง :

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

   b) ความไม่รู้ / ความกลัว / ความไม่แน่นอน : "เราไม่เข้าใจจริงๆว่าการควบคุมแหล่งข้อมูลคืออะไรเราไม่รู้ว่าจะใช้มันอย่างไรเราไม่รู้ว่าจะเลือกเครื่องมือแบบไหน นี่คือเหตุผลหนึ่งที่ฉันจะไม่ส่งพวกเขาที่นี่! อาจเป็นคำสั่งที่ค่อนข้างสูงสำหรับคุณ แต่ฉันคิดว่าจะเพิ่มโอกาสของคุณให้มากที่สุดที่คุณจะต้องนำเสนอโซลูชัน 'เทิร์นคีย์' และไม่แปรเปลี่ยนหรือทางเลือกมากเกินไป คุณต้องการแนวคิดที่ชัดเจนว่า: วิธีที่คุณต้องการปรับเปลี่ยนกระบวนการทำงานของคุณให้ทำงานกับเครื่องมือที่กำหนด อย่างไร / ถ้าคุณวางแผนที่จะ back-port code ที่มีอยู่; คุณคิดว่าคุณสามารถฝึกผู้ใช้ให้เร็วแค่ไหน วิธีที่คุณสามารถจัดการช่วงเวลาการเปลี่ยนแปลง (ถ้ามี) มีแนวโน้มว่าจะ 'ต้นทุน' เท่าใด (เป็นชั่วโมงถ้าไม่ได้อยู่ในหน่วยดอลลาร์)

   c) อาจมีเหตุผลอื่น ๆ (ตัวอย่างเช่นประสบการณ์เลวร้ายกับ VSS ก่อนหน้าหรืออ่าน 'เรื่องสยองขวัญ' เกี่ยวกับเครื่องมือที่ซับซ้อนเกินกว่าที่ถูกกล่าวหา) แต่คุณจะต้องทุบสิ่งเหล่านั้นเป็นรายบุคคลเมื่อคุณค้นพบมัน

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

(คุณเคยอ่าน / เคยได้ยินเกี่ยวกับฟังก์ชั่นเปลี่ยนหรือไม่?)

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

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

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

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

เป็นเรื่องปกติหรือไม่ที่กลุ่มขนาดนี้จะไม่มีการควบคุมแหล่งที่มา

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

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

ดูคำถามนี้ใน SOเพื่อการสนทนาที่ดี คำตอบที่ได้รับการยอมรับกล่าวว่า:
"ไม่มีเหตุผลที่ดีที่จะไม่ใช้การควบคุมเวอร์ชันไม่ใช่เพียงอย่างเดียว"

มีเหตุผลอื่นอีกหรือไม่ที่ฉันสามารถเพิ่มแหล่งข้อมูลลงในคลังแสงได้?

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

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

แค่ไปหาเครื่องมือที่ช่วยคุณ ขนาดไม่สำคัญทุกที่ คุณภาพไม่สำคัญทุกที่

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

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

• แทนที่จะบันทึกการเปลี่ยนแปลงในสเปรดชีตระบบ SCM จะติดตามไม่เพียง แต่สิ่งที่เปลี่ยนแปลง แต่ใครเปลี่ยนและทำไม

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

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

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

(BTW, ฉันใส่เรซูเม่ของฉันและเอกสารอื่น ๆ ภายใต้ SVN จากนั้นอีกครั้งฉันได้เล่นบทบาทของ Configuration and Integration Managers หลายครั้ง)

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

• ผลิตภัณฑ์ที่คุณกำลังพัฒนาคือระบบควบคุมเวอร์ชัน ผู้จัดการมีความกังวลเกี่ยวกับการป้องกันไม่ให้ผลิตภัณฑ์ที่มีอยู่มีอิทธิพลต่อการออกแบบและการใช้งานผลิตภัณฑ์ใหม่

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

• หลีกเลี่ยงการครอบครองเป็นศัตรู ใครอยากได้ชุดพัฒนาซอฟต์แวร์ที่จัดการด้วยวิธีนี้

มีเหตุผลอื่นอีกหรือไม่ที่ฉันสามารถเพิ่มแหล่งข้อมูลลงในคลังแสงได้?

• คุณกำลังควบคุมเวอร์ชันอยู่แล้ว แต่คุณกำลังทำอยู่ในวิธีที่มีประสิทธิภาพน้อยที่สุดโดยใช้แรงงานมากที่สุด การใช้ VCS จะประหยัดเงินประหยัดเวลาและปรับปรุงคุณภาพ

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

• นักพัฒนาหลายคนสามารถทำงานกับไฟล์เดียวกันในเวลาเดียวกันและกระทบยอดแตกต่างกันโดยไม่มีปัญหามากเกินไป แน่นอนว่าการรวมการเปลี่ยนแปลงเป็นไปได้โดยปราศจาก VCS แต่แทบจะเป็นไปไม่ได้เลยที่จะติดตามว่าใครเปลี่ยนอะไรเมื่อใดและทำไมในกรณีนี้

• ให้อิสระกับนักพัฒนาในการลองแนวคิดใหม่ ๆ โดยรู้ว่าพวกเขาสามารถกู้คืนเวอร์ชันใด ๆ ได้ตลอดเวลา

• กระบวนการที่ดีขึ้นทำให้การจ้างและรักษาผู้พัฒนาที่มีความสามารถเป็นเรื่องง่ายขึ้น

เป็นเรื่องปกติหรือไม่ที่กลุ่มขนาดนี้จะไม่มีการควบคุมแหล่งที่มา

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

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

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

มีเหตุผลอื่นอีกหรือไม่ที่ฉันสามารถเพิ่มแหล่งข้อมูลลงในคลังแสงได้?

ใช่มีหลายเหตุผล

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

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

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

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

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

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

มีเหตุผลเป็น # 1 ในการทดสอบ Joel: http://www.joelonsoftware.com/articles/fog0000000043.html

นอกจากนี้ยังทำให้ # 2 และ # 3 เป็นไปได้ในรายการ

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

ทุกคนตามความเหมาะสมและไม่นานก่อนที่เราจะใช้ CI ( CruiseControl ) และปฏิวัติกระบวนการสร้างและการเปิดตัวของเราเพื่อรวมการตรวจสอบอัตโนมัติและคุณภาพ

WTF ?! นี่อาจเป็นคำถามที่ไร้สาระที่สุดที่ฉันเคยเห็น คุณต้องหางานใหม่ 15 นักพัฒนา! คุณคิดว่าเป็นทีมเล็ก ๆ นี่มันบ้าไปแล้ว ผู้จัดการควรยกเลิกทันที สุจริตฉันจะมีฝันร้ายหลังจากอ่านคำถามนี้ กรุณาบอกให้เราทราบผลิตภัณฑ์ที่คุณขายเพื่อให้เราทุกคนรู้ว่าจะไม่ซื้อ! ฉันไม่รู้ว่าอะไรน่ากลัวคำถามนี้หรือคำตอบที่บอกว่าไม่แปลกเลย!

ฉันไม่สามารถจินตนาการได้ว่านักพัฒนา 15 คนสามารถทำงานได้อย่างไร อย่างไรก็ตามจาก:

(... ) ใช้เครือข่ายแชร์เพื่อโฮสต์ซอร์สโค้ด (... )

ฉันคิดว่าคุณได้สร้างการควบคุมเวอร์ชันคนจนของคุณเองเช่นVSS (เช่นเดียวกับโฟลเดอร์ที่แชร์) มันมีความเสี่ยงและไม่มีประสิทธิภาพ

อธิบายหัวหน้าของคุณว่ามันแย่แค่ไหนลงทุนในการฝึกอบรม SVN หรือ GIT 2 วันและเริ่มใช้ระบบควบคุมเวอร์ชันจริงในขณะที่คุณยังมีรหัสอยู่ในเกณฑ์ที่เหมาะสม

ถ้าฉันไม่ได้ทำวันละหลายครั้งหรืออย่างน้อยก็ก่อนออกจากบ้านฉันรู้สึกว่า .. มีบางอย่างหายไปสักอย่างผิดปกติ

ฉันเคยทำงานใน บริษัท ที่มีนักพัฒนาเพียง 2 คน (ฉัน + คนดูแลผมที่มีผมยาว) ย้อนกลับไปในปี 1998 แม้กระทั่งตอนนี้เราก็ใช้ svn มันสะดวกมาก

หลายครั้งในอาชีพการงานของฉันฉันทำงานหลายวันเพราะฉันทำอะไรบางอย่างที่เหมือนกับ mv แทนที่จะเป็น cp แล้วก็ rm -rf ทำให้ฉันร้องไห้และเดินไปตามถนนในเมืองด้วยความสิ้นหวัง

ฉันทำงานใน 5 บริษัท ตลอด 13 ปีที่ฉันอยู่ใน SE เคยไปงานประชุมและไม่เคยเจอ บริษัท ที่ไม่ได้ใช้การควบคุมเวอร์ชัน

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

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

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

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

ตกลงเหตุการณ์ย้อนกลับมาหาฉัน ลงชื่อออก โชคดี.

1. รับนาฬิกาจับเวลา
   • นับเวลาที่คุณใช้ในสเปรดชีตเพียงเพื่อซิงค์เวอร์ชัน
   • นับเวลาที่คุณใช้ซ่อมรุ่นที่ใช้งานไม่ได้
   • นับจำนวนครั้งที่ผู้คนโห่ร้องในโถงทางเดิน " ฉันกำลังแก้ไข main.c! เพียงเพื่อให้แน่ใจว่าไม่มีใครอยู่ในขณะนี้!" .
   • นับจำนวนข้อร้องเรียนที่คุณได้รับจากลูกค้าเนื่องจากข้อผิดพลาดของพวกเขามีการเปลี่ยนแปลงอื่น ๆ
   • นับเวลาล่าช้าของการเปิดตัวเพียงเพราะคุณไม่สามารถซิงก์เวอร์ชันได้
2. สร้าง PowerPoint ด้วยข้อมูลนี้เปรียบเทียบกับ vcs
3. แสดงการจัดการ

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

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

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

LordScree ฉันอยู่ในสถานการณ์ที่เกือบจะเหมือนคุณทีมของฉันมีนักพัฒนาประมาณ 15 คน ฉันไม่เชื่อ (เกือบจะสยองขวัญ) ที่ไม่ได้ใช้การควบคุมแหล่งที่มา การตอบกลับเริ่มต้นของฉันต่อ "เราควรใช้การควบคุมแหล่งที่มา" คือ "เราไม่มีเวลาดำเนินการ" สำหรับฉันเช่นการสวมชุดชั้นในการควบคุมแหล่งข้อมูลนั้นไม่จำเป็น หลังจากผ่านไปสองสามเดือนฉันก็มีการอนุมัติให้ใช้ TFS ซึ่งองค์กรดังกล่าวเลือกเพราะเป็น MS และมาพร้อมกับการทดลอง 90 วัน ที่สำคัญที่สุดคือมันยากมากที่จะโน้มน้าวองค์กรที่ต้องการการควบคุมแหล่งที่มาเมื่อพวกเขาถูกพาไปโดยไม่มีมัน ฉันบอกผู้พัฒนาว่าเมื่อใดก็ตามที่คุณพบว่าตัวเองกำลังสำรองไฟล์โดยเฉพาะกับวันที่ในชื่อไฟล์หรือไดเรกทอรีที่สำรองไว้นั้นเป็นตัวอย่างของเวลาที่คุณวางบางสิ่งไว้ในแหล่งควบคุม ฉันไม่ ' ไม่มีคำตอบที่ยอดเยี่ยมสำหรับคุณ แต่ฉันเชื่อว่านี่เป็นเรื่องแปลก ฉันกำลังต่อสู้ในการต่อสู้เดียวกันและจะแจ้งให้คุณทราบถึงความคืบหน้า และหวังว่าจะมีความคืบหน้าอย่างอื่นฉันอาจมองหาที่อื่นเพราะฉันไม่สามารถทำงานได้ในความสับสนวุ่นวาย!

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

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

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

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

เพียงแค่บอกพวกเขาว่ามันยอดเยี่ยมแค่ไหนในการค้นหาว่าแอปนี้มีอะไรในวันที่ 1 มกราคมปีนี้

วิธีการเกี่ยวกับเฮ้ฟังก์ชันนี้ถูกบันทึกมีนาคมผมคิดว่าเราจำเป็นต้องขยายอีกเล็กน้อยเกี่ยวกับเรื่องนี้

ว้าวข้อผิดพลาดนี้ได้รับการแก้ไข 154256 ในการกระทำนี้

ฉันสามารถแยกแอพออกและส่งการปรับใช้ไม่มีปัญหาคุณสามารถทำงานต่อไปได้

สิ่งนี้สามารถดำเนินต่อไปและ ...

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

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

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

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

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

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

ในงานที่จริงจังครั้งแรกของฉันในปี 1990 ฉันเป็นนักพัฒนาเพียงคนเดียวที่ทำงานในแผนกของฉันและไม่รู้ว่าจะใช้การควบคุมแหล่งที่มา

หลังจากนั้นไม่นานฉันก็เรียนรู้หลังจากนั้นฉันไม่เคยเห็นโครงการที่ไม่ได้ทำให้เป็นหนึ่งในสิ่งแรกที่พวกเขาตั้งขึ้น

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

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

ฉันได้ระบุสิ่งนี้ไว้มากมาย ... ใน บริษัท วิศวกรรม / อิเล็กทรอนิกส์ขนาดเล็กที่พวกเขาทำซอฟต์แวร์ / ฮาร์ดแวร์ในตัวจำนวนมาก

ในสถานที่เหล่านี้ SCM ไม่ได้เป็นส่วนหนึ่งของวัฒนธรรมวิศวกรรมอิเล็กทรอนิกส์ พวกเขามักจะมีวิศวกรหนึ่งคนต่อโครงการที่เพิ่งจะสำรองข้อมูลรีลีสล่าสุด

ดังนั้นการแบรนช์ / การรวมและแม้แต่การแชร์รหัสก็ถือว่าไม่เกี่ยวข้อง นอกจากนี้ บริษัท เหล่านี้อาจมี ISO9000 ดังนั้นกระบวนการแปลกประหลาดอาจถูกบันทึกไว้

ไม่ว่าในกรณีใด I / ผู้พัฒนารายอื่นเพิ่งเริ่มใช้ SCM เป็นการส่วนตัว

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

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

เหตุผลที่ดีที่สุดที่ฉันเคยได้ยินเมื่อไม่ใช้ฟอสซิลหรือ VCS อื่น ๆ คือ:

1. "โปรแกรมเมอร์" หลายคนเป็น kiddies สคริปต์และไม่เข้าใจวิธีการใช้งาน
2. ผู้ที่สามารถเรียนรู้คิดว่ามันเป็นความรำคาญที่จะใช้
3. คนเหล่านี้เป็นยามเก่าสบาย ๆ กับโฟลเดอร์เครือข่ายดังนั้นทุกคนควรจะเป็น
4. ไม่มีใครมีเวลาตั้งค่าอย่างถูกต้องหรือเรียนรู้วิธีใช้งาน
5. แม้ว่าคุณสมบัติอาจยอดเยี่ยม แต่ก็ไม่มีความจำเป็น

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

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

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

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

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

คุณควรควบคุม GIT เวอร์ชันด้วยตัวเองทันที คุณสามารถใช้งานได้จาก Google Code Project Hosting เมื่อคนอื่นเห็นว่าคุณยอมรับการเปลี่ยนแปลงในคลิกเดียวในขณะที่พวกเขาคัดลอกสิ่งต่าง ๆ ด้วยตนเองบางทีพวกเขาอาจเปลี่ยนใจ

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

ตัวอย่างเช่นเรากำลังทำงานบนเครือข่ายสังคม ab เกรดที่เขียนใน PHP และลูกค้าต้องการฟังก์ชั่นเพื่อให้สามารถสมัครสมาชิกโปรไฟล์ผู้ใช้ โดยพื้นฐานแล้วฟังก์ชันการทำงานถูกห่อด้วยเช็คเช่นนี้หาก (ENABLE_SUBSCRIBE_FUNCTIONALITY == true) {จากนั้นเรียกใช้รหัส}

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

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

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

คุณสามารถหาข้อมูลได้ที่นี่: http://www.internetcontact.be/scm/?page_id=358

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