บอสสงสัยในการใช้ระบบควบคุมเวอร์ชันสำหรับโปรเจ็กต์ใหม่

ดู/software/109817/superior-refusing-to-use-subversion

คำถามของฉันคล้ายกัน แต่นี่คือความแตกต่างหลักในสถานการณ์ของฉัน:

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

• ทีมนักพัฒนาของฉันประกอบด้วยฉันและเจ้านายของฉัน เราเป็นแผนก "IT" ของ บริษัท ที่ค่อนข้างเล็ก

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

ข้อเสนอของเจ้านายของฉันวางโดยตรงจากอีเมล:

• ควรส่งการอัปเดตเป็นแพ็คเกจในโฟลเดอร์ SUBMISSIONS แพ็คเกจควรมีไฟล์ที่เกี่ยวข้องทั้งหมดรวมถึงไฟล์ 'UPDATE.NFO' ที่มีคำอธิบายของการอัปเดตรายชื่อไฟล์ใหม่ทั้งหมดที่มี (รวมถึงคำอธิบาย) และรายการไฟล์ที่แก้ไขทั้งหมดพร้อมรายละเอียดการแก้ไข

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

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

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

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

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

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

กรุณาไม่แสดงความคิดเห็น "รับงานอื่น" นั่นไม่เป็นประโยชน์ต่อการอภิปราย

อย่าถามเขา อย่าบอกเขา แสดงให้เขาเห็น.

ติดตั้ง svn หรือ git หรือสิ่งที่คุณต้องการในเครื่องเสริมบางอย่าง ฝึกฝนใช้มันด้วยตัวเองจนกว่าคุณจะรู้สึกสบายใจไม่ใช่แค่ใช้มัน แต่อธิบายได้ หากคุณจะทำให้เขาคุ้นเคยกับระบบใหม่ของคุณคุณจะต้องสบายใจกว่าด้วยตัวคุณเอง คุณจะต้องสามารถช่วยให้เขาฟื้นตัวได้อย่างง่ายดายเมื่อเขาไขการรวมหรือตรวจสอบบางสิ่งผิดที่

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

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

ให้แผ่นโกงเขาซึ่งจะทำให้ง่ายสำหรับเขาที่จะใช้ระบบควบคุมเวอร์ชันของคุณ

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

ประโยชน์ที่ได้รับจากการควบคุมซอร์สโค้ดจะช่วยให้นักพัฒนาซอฟต์แวร์หลายคนทำงานบนโค้ดชิ้นเดียวได้ Eric Sink ผู้ก่อตั้งSourceGearแสดงเหตุผลที่น่าสนใจบางประการในการใช้การควบคุมซอร์สในฐานะนักพัฒนาเพียงผู้เดียว :

- It's an undo mechanism.
- It's a historical archive.
- It's a reference point for diff.
- It's a backup.
- It's a journal of my progress. 
- It's a server. 

เอริคยังเกิดขึ้นที่จะมีการเริ่มต้นที่ดีมากการควบคุมแหล่งที่มาของวิธีการ มีการสอน Mercurialออนไลน์ฟรีโดย Joel Spolsky Mercurial เป็นระบบควบคุมเวอร์ชันกระจายที่ได้รับความนิยม

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

และในที่สุดก่อนที่คุณพยายามที่จะโน้มน้าวให้เจ้านายของคุณคุณอาจต้องการที่จะเจาะเข้าไปในหัวข้อของการคัดค้านการจัดการ มันคือ 101 จากยอดขาย

หากไม่สำเร็จ - เดินหน้าต่อไปโดยเร็วที่สุดเท่าที่จะทำได้ไม่ต้องเสียเวลาไปกับการทำกังหันลมมากนัก

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

SVN - หรือระบบควบคุมเวอร์ชันใด ๆ ก็ช่วยให้คุณทำได้เช่นกัน แต่การผสานเป็นปัญหาเล็กน้อย

หากฉันไม่สามารถโน้มน้าวเขาได้จะมีประเด็นที่ฉันจะใช้เพื่อตัวเองเท่านั้นหรือไม่?

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

ไม่ไม่มีประโยชน์เพราะหัวหน้าของคุณทำโครงการของคุณซ้ำอีกครั้งเพื่อทำสิ่งที่ไม่มีประโยชน์เพราะพวกเขาทำสิ่งสกปรก

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

หมายเลข 2 ความสามารถในการตรวจสอบย้อนกลับของการเปลี่ยนแปลงใครทำอะไรเมื่อใด ฯลฯ ผสานรวมเลิกทำ หมายเลข 3 กระจายเครื่องมือวิเศษสำหรับ # 2 และอีกหลายกรณี หมายเลข 4 สาขาหมายเลข 5 การแท็กเวอร์ชันการเผยแพร่ ฯลฯ

คุณสามารถหาข้อมูลเพิ่มเติมเกี่ยวกับหนึ่งในเวิร์กโฟลว์ git ที่พบมากที่สุดได้ที่นี่: https://nvie.com/posts/a-successful-git-branching-model/

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

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