การโค่นล้ม / การควบคุมแหล่งสำหรับรหัสการผลิตเท่านั้น?

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

นี่เป็นเรื่องปกติหรือไม่? ดูเหมือนว่าฉันจะชอบเราเสียประโยชน์มากมายจากการควบคุมแหล่งรวมถึง:

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

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

หากโครงการเสร็จสมบูรณ์ภายในระยะเวลาที่คาดการณ์ไว้จะปลอดภัยหรือไม่ที่จะถือว่าลูกค้าเป็นลูกค้าที่มีความสุข :)

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

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

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

มีความเคารพและคุณอาจท้ายจะได้ยิน

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

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

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

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

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

ใส่กันคำถามที่ว่าโจถูกหรือผิด (ผิดเขาโดยวิธีการ) มันดูเหมือนว่าฉันว่าการประนีประนอมอาจจะถึงถ้าคุณใช้ระบบการควบคุมเวอร์ชันกระจายเช่นGitหรือMercurial

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

ไม่มีเหตุผลสำหรับเหตุผลที่คุณระบุไว้ มันเหมือนกับการใช้การควบคุมเวอร์ชันโดยไม่ได้รับประโยชน์จากการใช้การควบคุมเวอร์ชัน

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

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

ฉันขอแนะนำให้คุณใช้เครื่องมือที่มีประสิทธิภาพมากกว่า SVN คุณสามารถดูการแนะนำที่ดีเกี่ยวกับความเป็นไปได้ที่http://hginit.com/โดย Joel Spoelsky

เขาใช้ Mercurial และมีคู่แข่งหลายคนในวันนี้ Git ถือว่ามีประสิทธิภาพมากและhttps://github.com/มีเครื่องมือที่มีประโยชน์และมีประโยชน์มากและให้บริการบัญชีเริ่มต้นฟรีเพื่อให้คุณสามารถทดลองใช้งานได้จริง

Joe ดูไม่เหมือนรู้เรื่อง SVN ลองค้นหาเกี่ยวกับ Branches, Tags และ Trunk ... Tags สอดคล้องกับสิ่งที่ Joe ต้องการ การอ่านแนวทางปฏิบัติที่ดีที่สุดของ SVN บางคนจะไม่เจ็บ

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

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

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

ในระยะเวลาอันสั้นฉันคาดหวังว่า Joe จะดูว่าคุณทำงานอย่างไรและเริ่มทำเช่นเดียวกัน ในปีหรือสองปีเซิร์ฟเวอร์ SVN จะกลายเป็น repo Git

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

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

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

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

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