เหตุใด บริษัท การเงิน / ประกันภัยขนาดใหญ่ควรใช้ git และ / หรือ gitub

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

บริษัท ของฉันมีทีมพัฒนาซอฟต์แวร์มากมาย พวกมันอยู่เหนือแผนที่พร้อมการควบคุมเวอร์ชันใช้ภาษา / กรอบงานเพียงอย่างเดียว บางคนไม่ใช้ (ฉันรู้) บางคนใช้ PVCS บางคนใช้ VSS และใช้ SVN ที่รู้แจ้งมากที่สุด

ฉันต้องการนำคอมไพล์มาสู่องค์กรของฉัน โดยเฉพาะฉันต้องการนำ GitHub (ที่เก็บส่วนตัว) ฉันรู้ว่าคนที่เหมาะสมในการพูดคุยเกี่ยวกับเรื่องนี้ แต่ขอให้ซื่อสัตย์อีกครั้งการเคลื่อนไหวที่รุนแรงเช่นนี้มักจะถูกยิงในองค์กรขนาดใหญ่เนื่องจากความกังวลด้านความปลอดภัยที่คลุมเครือหรือความจริงที่ว่าไม่มีคู่แข่งของเราใช้งาน อ้างอิงเฉพาะ jQuery, Ruby on Rails, Facebook และอื่น ๆ เป็นข้อมูลอ้างอิง)

ดังนั้นคำถามของฉันคือสิ่งนี้ อะไรคือเหตุผลที่น่าสนใจที่สุดว่าทำไมองค์กรขนาดใหญ่ควรช้าและตั้งใจเปลี่ยนจาก PVCS / VSS / SVN เป็นโซลูชัน git ที่โฮสต์เช่น GitHub (repo ส่วนตัว) แน่นอนส่วนหนึ่งของแผนของฉันเกี่ยวข้องกับ POC สำหรับโครงการพัฒนาที่ไม่จำเป็น

มีบางสิ่งที่ฉันอาจเกี่ยวข้องด้วยในฐานะบุคคลที่สามที่ไม่สนใจ ดังนั้นฉันจะโยนคำถามที่คุณว่าคุณควรเตรียมพร้อมที่จะตอบ (แผนกไอทีของคุณ):

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

นี่เป็นคำถามแรกที่จะเกิดขึ้น สำหรับ VSS และ PVCS คุณอาจมีข้อโต้แย้งที่ดีพอสมควร (เช่น VSS ที่ทำให้ประวัติศาสตร์เสียหาย) SVN จะยากขึ้นอีกเล็กน้อย ฉันขอแนะนำให้คุณมุ่งเน้นไปที่ความสามารถในการผสานของ GIT และแนะนำให้เปิดใจเกี่ยวกับ Mercurial ทุกข้อโต้แย้งสำหรับ GIT ก็เป็นข้อโต้แย้งสำหรับ Mercurial เช่นกันและ Mercurial ก็รองรับ Windows ที่เป็นผู้ใหญ่มากกว่า

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

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

สำหรับ Windows โฮสติ้งนั่นเป็นองค์กรตามปัญหาขององค์กร หลาย บริษัท กลืน Windows koolaid บ้างก็กลืน Linux koolaid คนอื่นพิจารณาเป็นกรณีไป คุณจะต้องเล่นตามกฎที่แผนกไอทีกำหนดไว้สำหรับองค์กรของคุณ ตราบใดที่วิธีการแก้ปัญหาของคุณสามารถโฮสต์ในทั้งคุณเป็นทอง

ในที่สุดในองค์กรขนาดใหญ่มีการรับประกันว่าจะเป็นศักดินาทุกคนต้องการทำสิ่งที่พวกเขาทำ พวกเขาทั้งหมดมีข้อโต้แย้งที่น่าเชื่อถือว่าทำไมพวกเขาเลือก VSS, PVCS, SVN หรืออะไรที่มีคุณ พวกเขาเหมือนกันทั้งหมด วิธีเดียวที่จะรวมภายในองค์กรที่มีขนาดใหญ่คือการมีคำสั่งมาจากคำสั่งจากด้านบน คำสั่งดังกล่าวมักจะพบกับการต่อต้านและอาจไม่ใช่สิ่งที่ บริษัท ของคุณต้องการทำเว้นแต่จะมีข้อดีของต้นทุนการเป็นเจ้าของ (TCO) โดยรวมที่ชัดเจนว่ามีระบบควบคุมเวอร์ชันมาตรฐาน

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

ในการกล่าวถึงสิ่งนี้ภายในองค์กรของคุณคุณต้องพิจารณาบางสิ่งก่อน:

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

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

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

บริษัท ดังกล่าวจะต้องการให้มีที่เก็บส่วนกลาง SVN และ VSS ad PVCS มีสิ่งหนึ่งที่เหมือนกันนั่นคือทั้งหมดเป็นสถาปัตยกรรมไคลเอนต์ - เซิร์ฟเวอร์ Git ได้รับการออกแบบในฐานะ VCS แบบกระจายและโดยธรรมชาติจะกระจายอำนาจ

GitHub - ยิ่งเป็นปัญหา มันเป็นบริการภายนอก ซอร์สโค้ดในบริการภายนอกเป็นสิ่งที่การจัดการมักจะไม่ยอมรับ

อย่างไรก็ตามมีวิธีแก้ปัญหาที่สามารถทำให้ทั้งสองฝ่ายพอใจ Git มีgit-svnคำสั่ง โดยทั่วไปคุณจะมีที่เก็บ SVN แต่นักพัฒนาซอฟต์แวร์บางคนอาจเลือกที่จะมี repo GIT ในพื้นที่ของตัวเองและซิงโครไนซ์มันกับ repo SVN ส่วนกลาง ทางเลือกที่ดีสำหรับสาขาส่วนตัวหรือส่งแพทช์ที่ไม่มีข้อ จำกัด ดีวิธีการสำหรับการรวม Git-SVN

คำตอบเหล่านี้จำนวนมากล้าสมัยอย่างมากเกี่ยวกับความคิดเห็นเกี่ยวกับ GitHub และความปลอดภัยเนื่องจากการเปลี่ยนแปลงที่ GitHub ตั้งแต่มีการโพสต์

• GitHub ไม่ได้บังคับให้คุณเป็นโฮสต์ภายนอก
• ฟรีรุ่นของ GitHub คือสิ่งที่ทำให้ข้อ จำกัด นี้ในสถานที่
• มีรุ่นองค์กรของ GitHub พร้อมใช้งานสำหรับสำหรับพื้นที่ภายใน https://enterprise.github.com/home มันไม่ฟรีและค่าใช้จ่าย $ แน่นอน

บริษัท ที่ฉันทำงานอยู่เพิ่งเริ่มใช้งานและเรามีข้อกังวลเดียวกันทุกประการเพราะรหัสของเราเป็นความลับทางการค้าเราอยู่ในภาคการเงิน นอกเหนือจากนั้นยังมีวิธีอื่นในการใช้ GIT ที่ไม่เกี่ยวข้องกับ GitHub ที่คล้ายกัน redmine, gitosis ฯลฯ ...

เกี่ยวกับคำถาม "ใครกำลังใช้งานอยู่": PayPal, Etsy, rackspace, vimeo, SAP, JPL ของ NASA , Linux Kernel

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

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

• ทุกครั้งที่ฉันต้องใช้ SVN ในสภาพแวดล้อมที่หวาดระแวงเหมือน บริษัท การค้าการ 'ปฏิบัติตาม' และ 'ความปลอดภัย' ที่ไร้สาระนั้นเป็นอันตรายอย่างยิ่งต่อประสิทธิภาพการทำงาน

ตั้งแต่ฉันคัดสรรปัญหาการใช้งานด้านเทคนิคจากผู้ที่คาดหวังในอนาคตฉันจะพูดอย่างนี้ ด้วยการใช้งานรวมกว่า 15 ปีฉันได้ใช้ CVS, SVN, CMVC, clearcase, perforce และระบบอื่น ๆ ในการตั้งค่าระดับมืออาชีพพร้อมกับ GIT หากมีคนต้องการให้ฉันใช้สิ่งอื่นที่ไม่ใช่ GIT (ยกเว้น bzr, mercurial, perforce และ clearcase (ขึ้นอยู่กับการตั้งค่าของสองคนสุดท้าย)) ฉันจะรู้ทันทีว่าเวลาของฉันดีกว่าที่อื่น ฉันเกือบจะได้ข้อสรุป (แม้ว่าจะขยายค่าเผื่อ CVS และ SVN เล็กน้อย) กลับไปในปี 2009 ฉันรู้สึกเบื่อหน่ายกับการตกสั้น ๆ ของการใช้ SVN ในที่ทำงานของฉันฉันเริ่มใช้ GIT เป็นลูกค้า SVN ของฉันในต้นปี 2010 ก่อน ช่วยโน้มน้าวให้เราเปลี่ยนมาใช้ GIT