बड़ी वित्तीय / बीमा कंपनियों को git और / या github का उपयोग क्यों करना चाहिए


12

मैं वित्तीय / बीमा उद्योग में एक बड़े उद्यम (30K कर्मचारियों) के लिए काम करता हूं। जबकि "आईटी" हमारा मुख्य ध्यान नहीं है, चलो ईमानदार रहें, ये सूचना संचालित उद्योग हैं और बेहतर तकनीकी लाभ वाली कंपनियां तेजी से आगे बढ़ रही हैं।

मेरी कंपनी में कई सॉफ्टवेयर डेवलपमेंट टीम हैं। वे संस्करण नियंत्रण के साथ नक्शे पर सभी हैं, अकेले भाषाओं / रूपरेखाओं का उपयोग करते हैं। कुछ किसी का उपयोग नहीं करते हैं (मुझे पता है), कुछ पीवीसीएस का उपयोग करते हैं, कुछ वीएसएस का उपयोग करते हैं, और सबसे प्रबुद्ध एसवीएन का उपयोग करते हैं।

मैं अपने उद्यम में पकड़ लाना चाहता हूं। विशेष रूप से, मैं GitHub (निजी रिपॉजिटरी) लाना चाहता हूं। मैं इस बारे में बात करने के लिए सही लोगों को जानता हूं, लेकिन चलो फिर से ईमानदार हों, इस तरह से कठोर चालें आम तौर पर अस्पष्ट सुरक्षा चिंताओं या इस तथ्य के कारण बड़े उद्यम की स्थापना में गोली मार देती हैं कि हमारे प्रतियोगियों में से कोई भी इसका उपयोग नहीं कर रहा है (और मैं कर सकता हूं) केवल संदर्भों के रूप में jQuery, रूबी ऑन रेल्स, फेसबुक, आदि का हवाला देते हैं)।

तो मेरा सवाल ये है। एक बड़े उद्यम को धीरे-धीरे और जानबूझकर पीवीसीएस / वीएसएस / एसवीएन से गीटहब (निजी रेपो) जैसे होस्ट किए गए गिट समाधान के लिए स्विच क्यों करना चाहिए, इसके सबसे सम्मोहक कारण हैं। बेशक, मेरी योजना के हिस्से में गैर-आवश्यक विकास परियोजना के लिए एक पीओसी शामिल है।


2
मैं उसी प्रक्रिया में हूं (बड़ी वित्तीय कंपनी, 100K कर्मचारी ...): देखें stackoverflow.com/questions/3597747/…
VonC

3
आप एक आंतरिक गिट रिपॉजिटरी से शुरुआत कर सकते हैं। आप समझ सकते हैं कि गिट अच्छा है, लेकिन कभी भी, कोड "बाहर" डालने की अनुमति न दें।

@VonC: अन्य प्रश्न के लिए धन्यवाद। अन्य: सभी महान जवाब / टिप्पणियों के लिए अब तक धन्यवाद। मैं हालांकि इस सवाल के साथ विशेष रूप से GitHub के आसपास रहना चाहूंगा क्योंकि मुझे लगता है कि यह एक बहुत अच्छा UI है और कुछ "तकनीकी दर्द" को दूर
रखता है

4
GitHub अब GitHub Enterprise प्रदान करता है जो आपको अपने निजी नेटवर्क पर GitHub की मेजबानी करने की अनुमति देता है, लेकिन आपके आटे को बाहर निकालने के लिए तैयार रहें।
एम। डडले

जवाबों:


25

वहाँ कुछ चीजें मैं एक तीसरे पक्ष के रूप में एक असंतुष्ट के साथ संबंध हो सकता है। तो मुझे आप पर कुछ सवाल टॉस करने चाहिए, जिसका उत्तर देने के लिए आप बेहतर तरीके से तैयार होंगे (अपने आईटी विभाग को):

  • कोई भी संस्करण नियंत्रण किसी से बेहतर नहीं है। हमारे पास चुनने के लिए बहुत कुछ है, इसमें क्या गलत है?
  • वितरित संस्करण नियंत्रण? वह क्या है? हम इसे कैसे नियंत्रित करते हैं?
  • इसकी कीमत क्या है? न केवल सॉफ्टवेयर, बल्कि सर्वर, लाइसेंस, रखरखाव, आदि।
  • मुझे GitHub, या किसी भी आउटसोर्स होस्टिंग पर भरोसा नहीं है । हमें घर में सब कुछ करने की जरूरत है। हम अपना स्वयं का सर्वर क्यों सेट नहीं कर सकते?
  • क्या हम इसे विंडोज पर चला सकते हैं? हमें इसे अपनी वर्तमान आधार रेखा पर रखना होगा, आप जानते हैं।
  • हम बात को कैसे सुरक्षित करते हैं? एसवीएन हमें मिलता है, लेकिन यह मुझे डराता है।

ये बहुत पहले प्रश्न हैं जो सामने आएंगे। वीएसएस और पीवीसीएस के रूप में, आप संभवतः यथोचित अच्छे तर्कों के एक समूह के साथ आ सकते हैं (जैसे कि वीएसएस भ्रष्ट संस्करण इतिहास)। एसवीएन थोड़ा और मुश्किल होगा। मैं अत्यधिक GIT की मर्ज क्षमताओं पर ध्यान केंद्रित करने की सलाह देता हूं, और मर्क्यूरियल के बारे में खुले दिमाग रखने की भी सलाह देता हूं। जीआईटी के लिए प्रत्येक तर्क भी मर्क्यूरियल के लिए एक तर्क है - और मर्क्यूरियल में अधिक परिपक्व विंडोज समर्थन है।

वित्तीय और सरकारी संस्थानों के लिए सुरक्षा सर्वोपरि है। वे बाहरी रूप से होस्ट किए गए संसाधनों के लिए बेहद प्रतिरोधी होंगे । जोखिम प्रबंधन के दृष्टिकोण से, विचार करें कि क्या हो सकता है अगर किसी ने GitHub को हैक किया और स्रोत कोड चुरा लिया, या समस्या ट्रैकर में दर्ज सुरक्षा भेद्यता की खोज की। यह कंपनी के लिए विनाशकारी होगा। शुद्ध प्रबंधन के दृष्टिकोण से, यदि कंपनी कानूनी रूप से हैआपके द्वारा काम करने वाले प्रत्येक घंटे के लिए आपको भुगतान करने की आवश्यकता होती है, वे कैसे निगरानी रख सकते हैं कि क्या आप घर से काम कर रहे हैं जब संसाधन उनके वीपीएन नेटवर्क के बाहर हैं? एक अन्य नोट पर, कंपनी के बाहर से सभी संसाधन उपलब्ध होने पर वे आपको कुछ कॉर्पोरेट जासूसी करने से कैसे रोक सकते हैं? ये होस्टिंग आउटसोर्सिंग के खिलाफ आईटी और प्रबंधन तर्क हैं। एक बड़ी कंपनी को इस तरह से चीजों को देखना होगा। एक छोटी कंपनी के लिए, आप नीचे की रेखा को देखते हैं और उन सभी सेवाओं को लगाने में कितना खर्च आएगा।

यह वास्तव में बड़ी कंपनी के लिए घर में करना सस्ता है। उनके पास पहले से ही आईटी संसाधन हैं, उन्हें बस जिम्मेदारियों को थोड़ा सा फेरबदल करने की आवश्यकता है। और अगर समाधान काफी हद तक केवल आवधिक रखरखाव (बैकअप और उपयोगकर्ता प्रबंधन) के साथ ही देखभाल करता है, तो सभी इसे कॉर्पोरेट दरवाजे के साथ रखने का कारण है।

विंडोज होस्टिंग के रूप में, कि संगठन के मुद्दे से एक संगठन है। कई कंपनियों ने विंडोज कूलड निगल लिया है। दूसरों ने लिनक्स कुलैड को निगल लिया है। दूसरे इसे केस के आधार पर मानते हैं। आईटी विभाग द्वारा आपके संगठन के लिए निर्धारित नियमों से आपको खेलना होगा। जब तक आपके समाधान को होस्ट किया जा सकता है, तब तक आप सुनहरे हैं।

अंत में, इस तरह के एक बड़े संगठन में सभी चीजों को अपने तरीके से करने की इच्छा वाले चोर होने की गारंटी है। उन सभी के पास तर्क है कि उन्होंने वीएसएस, पीवीसीएस, एसवीएन, या आपके पास क्या चुना है। आईटी के लिए वे सभी समान हैं। एक संगठन के भीतर समेकित करने का एकमात्र तरीका यह है कि बड़े को आदेश ऊपर से fiat द्वारा आना है। इस तरह के आदेश हमेशा प्रतिरोध के साथ मिलते हैं, और यह संभवत: ऐसा कुछ नहीं है जब तक आपकी कंपनी ऐसा नहीं करना चाहती जब तक कि एक मानकीकृत संस्करण नियंत्रण प्रणाली होने के लिए कुल लागत का स्वामित्व (TCO) लाभ न हो।


1
+1: यहां तक ​​कि अगर तर्क दिया गया कि यह मान्य नहीं है, तो मैं इसे "fief" शब्द के रचनात्मक उपयोग के लिए +1 करूंगा।
जोएल इथरटन

1
मैं बस उस तरीके को पेश करना चाहता था जैसे बड़े निगम चीजों को देखते हैं। कोई भी ऐसा नहीं करता है कि वे सभी मान्य हैं, लेकिन आपको उनके लिए जवाब देना होगा।
बेरिन लोरिट्श

1
मैं इनमें से किसी भी बिंदु पर असहमत नहीं हूं। वे सभी हर संगठन के लिए मान्य नहीं हो सकते हैं, लेकिन वे प्रत्येक कई संगठनों के लिए मान्य हैं।
जोएल एथर्टन

1
जैसा कि पिछले 5 वर्षों में बार-बार बदला गया है, आप इन-हाउस या कुछ अन्य वेरिएंट को होस्ट कर सकते हैं। पानी को और गन्दा करने के लिए, Microsoft टीम फ़ाउंडेशन सर्वर GIT का उपयोग कर रहा है, जो कोर में है, और Visual Studio के पास अब GIT के लिए समर्थन है। GIT के लिए तर्क अब पहले की तुलना में अधिक मजबूत है। ऐसा भी लगता है कि GIT ने सभी टूल विक्रेता एकीकरण के साथ Mercurial को छोड़ दिया है। अच्छी खबर यह है कि इन सभी को कॉर्पोरेट इन्फ्रास्ट्रक्चर के साथ एकीकृत किया जा सकता है (जैसे प्रमाणीकरण के लिए ActiveDirectory या कॉर्पोरेट LDAP का उपयोग करना)
Berin Loritsch

GitHub को अब बाहरी रूप से होस्ट करने की आवश्यकता नहीं है।
UpAndAdam

8

मैं एक वित्तीय / बीमा उद्यम में भी काम करता हूं (हालांकि आप जितने बड़े वर्तमान में काम कर रहे हैं उतने बड़े नहीं हैं)। हमारे पास कई विकास दल भी हैं, और जब उद्यम ने विशेष रूप से Microsoft उत्पादों को चुना है, तो अभी भी कोई मास्टर आर्किटेक्चर, भाषा या स्रोत नियंत्रण नहीं है। हम सभी .Net का उपयोग कर रहे हैं, लेकिन हमारे पास फ्रेमवर्क के विभिन्न संस्करणों और विभिन्न भाषाओं में कई परियोजनाएं हैं। कुछ परियोजनाएं वीएसएस अन्य टीएफएस का उपयोग करती हैं। हमारे पास अब क्यूए प्रबंधक के रूप में एक नया उच्च स्तरीय वास्तुकार है और उसने हमारे हॉज-पॉज बग ट्रैकिंग, स्रोत नियंत्रण, फ्रेमवर्क के उपयोग से लेकर टीएफएस के अधिक सार्वभौमिक कार्यान्वयन तक अधिक उद्यम संक्रमण की अगुवाई की है। यह केवल इस तथ्य से संभव हो जाता है कि वह सॉफ्टवेयर की प्रकृति में बहुत ही अनुभवी है)

अपने संगठन के भीतर इसे संबोधित करते हुए, आपको पहले कुछ बातों पर विचार करना होगा:

  1. क्यों आप जवाब के रूप में GitHub के साथ आसक्त हैं? क्या आप सामान्य स्रोत नियंत्रण की तलाश कर रहे हैं या आप जिस चीज के साथ सहज हैं उसे लागू करने के लिए एक कारण की तलाश कर रहे हैं? मुझे जवाब नहीं पता (और स्पष्ट रूप से परवाह नहीं है), लेकिन यह एक ऐसा सवाल है जो तब आएगा जब आप अन्य लोगों के व्यवसाय में घूमना शुरू करेंगे।
  2. क्या आप वर्तमान में इनमें से किसी सॉफ़्टवेयर टीम से संबद्ध हैं? यदि हां, तो आपको अवधारणा को चैंपियन करने के लिए एक अप्रभावित, अच्छी तरह से तैनात व्यक्ति को खोजने की आवश्यकता हो सकती है। अन्यथा अन्य विकास दल सिर्फ महसूस कर सकते हैं कि आप उन पर अपनी सोच छापने का प्रयास कर रहे हैं। यह उन्हें अवधारणा के लिए और भी अधिक प्रतिरोधी बना देगा क्योंकि उनके पास पहले से ही कुछ है जो काम करता है (उनकी राय में)।
  3. क्या आपने अवधारणा को खरीदने के लिए अन्य टीमों के व्यक्तियों को कोई आउटरीच बनाया है? क्या अन्य डेवलपर्स के पास समान राय या चिंताएं हैं? इसे पूरा करने के लिए एक और अवसर काम करने वाले लोगों के बीच एक महत्वपूर्ण द्रव्यमान का निर्माण करना है। जैसा कि अधिक लोग आम स्रोत भंडार की मांग करना शुरू करते हैं, प्रबंधन को नोटिस लेना होगा।
  4. क्या आप अन्य टीमों के कोड / प्रक्रियाओं / आवश्यकताओं से पर्याप्त रूप से परिचित हैं कि यह कहने के लिए पर्याप्त है कि उनके लिए GitHub काम करेगा (या नहीं)?

आपके अंतिम (या वास्तविक?) प्रश्न के रूप में, व्यापार प्रबंधकों के दृष्टिकोण से लंबे समय में एकमात्र सही सम्मोहक कारण यह है कि पैसे की बचत होती है। ये बचत कम डाउनटाइम, बढ़ी हुई कोड सुरक्षा, डेवलपर की उत्पादकता में वृद्धि, कोड-बेस अतिरेक (बैकअप के लिए), आदि, एट अल के रूप में हो सकती है। आपको अंततः उन सभी को समझाने की आवश्यकता होगी जो इस बात के लिए चेक लिखते हैं कि इस तरह के मॉडल को बदलने में लगने वाला समय, प्रयास और धन उनके निवेश पर वापसी के रूप में अंत में इसके लायक होगा। आपको यह भी दिखाना होगा कि भविष्य में उसी मॉडल का समर्थन तब होगा जब "धीरे-धीरे और जानबूझकर" आखिरकार होगा।

ऐसा बहुत कुछ है जो इस तरह के उद्यम परिवर्तन में बदल जाता है, इसलिए यह बहुत ही जमीनी शैली के उत्साह को ले जाएगा और अवधारणा को चैंपियन बनाने के लिए आपको निश्चित रूप से वीपी स्तर पर किसी की आवश्यकता होगी। एक प्रबंधक काम कर सकता है, लेकिन एक कार्यकारी के पास अन्य समूहों पर अवधारणाओं को छापने के लिए बहुत अधिक अधिकार होंगे।


4

ऐसी कंपनियां अपने रिपॉजिटरी को केंद्रीकृत करना चाहेंगी। SVN, VSS ad PVCS में एक चीज समान है - वे सभी क्लाइंट-सर्वर आर्किटेक्चर हैं। Git को वितरित VCS के रूप में डिज़ाइन किया गया है, और स्वभाव से विकेंद्रीकृत है।

GitHub - और भी अधिक समस्याग्रस्त। यह एक बाहरी सेवा है। बाहरी सेवा में स्रोत कोड कुछ ऐसा है जिसे प्रबंधन सबसे अधिक संभावना कभी स्वीकार नहीं करेगा।

हालांकि ऐसा समाधान है जो दोनों पक्षों को संतुष्ट रख सकता है। Git के पास git-svnकमांड है। मूल रूप से आपके पास SVN रिपॉजिटरी होगी, लेकिन कुछ डेवलपर्स अपने स्थानीय GIT रेपो को चुन सकते हैं, और इसे केंद्रीकृत SVN रेपो के साथ सिंक्रनाइज़ कर सकते हैं। निजी शाखाओं के लिए अच्छा विकल्प या बिना किसी पैच के आसपास भेजना। Git-svn एकीकरण के लिए अच्छा कैसे


केंद्रीयकृत रिपॉजिटरी वरीयता पर सहमत। Git-SVN इंटरॉप के रूप में: GitHub अब Git रिपॉजिटरी को SVN एक्सेस प्रदान करता है; और कंपनी द्वारा होस्ट किए गए रिपॉजिटरी, सबजीट जैसे उपकरणों से लाभान्वित हो सकते हैं ।
वदिशेव

github doesn't को बाहरी होना होगा
UpAndAdam

1

GitHub और सुरक्षा के बारे में टिप्पणियों के संबंध में इनमें से कई उत्तर महत्वपूर्ण हैं क्योंकि पोस्ट किए जाने के बाद से GitHub में परिवर्तन किए गए थे।

  • GitHub आपको बाहरी रूप से होस्ट करने के लिए बाध्य नहीं करता है
  • मुफ्त GitHub के संस्करण क्या जगह में इस प्रतिबंध डालता है।
  • आंतरिक होस्टिंग के लिए GitHub का एंटरप्राइज संस्करण उपलब्ध हैhttps://enterprise.github.com/home । यह मुफ़्त नहीं है और $ जरूर खर्च होता है

जिस कंपनी में मैं काम करता हूं, बस उसका उपयोग करना शुरू कर दिया है और हमें वही चिंताएं थीं क्योंकि हमारा कोड एक व्यापार रहस्य है, हम वित्त क्षेत्र में हैं। इसके अलावा GIT का उपयोग करने के अन्य तरीके हैं जो GitHub को शामिल नहीं करते हैं जो समान, रेडमिन, गिटोसिस, आदि हैं ...

"जो इसका उपयोग कर रहा है" प्रश्न के बारे में: पेपाल, एटीसी, रैकस्पेस, वीमियो, एसएपी, नासा का जेपीएल , लिनक्स कर्नेल

सम्मोहक तकनीकी कारण बहुत से हैं। यहां ध्यान देने योग्य एकमात्र चीज उच्च स्तर के बड़े उद्यम मुद्दे हैं जो अन्य उत्तर बताते हैं। सबसे बड़ी जो मैं सोच सकता हूं वह है स्थिरता, एकरूपता, स्पष्ट ऑडिटिंग, ऑडिटिंग की सरलता। हालांकि इन अन्य VCS प्रणालियों में से कई के साथ समस्याओं का खज़ाना हल करना एक बड़ी बात है।

उन सभी विभागों में डुप्लिकेट किए गए प्रयासों में कटौती होती है, जिन्हें अलग-अलग प्रणालियों के बीच एकीकृत करने के लिए, उन्हें ऑडिट करने और उन पर रिपोर्ट करने और उन्हें नियंत्रित करने के लिए विभिन्न निराला स्क्रिप्ट लिखना पड़ता है।

  • हर बार मुझे एसवीएन को एक व्यपारी माहौल में ट्रेडिंग फर्म की तरह इस्तेमाल करना पड़ा, बेतुका 'अनुपालन' और 'सुरक्षा' हुक प्रदर्शन के लिए बेहद हानिकारक थे।

चूँकि मैं एक संभावित भावी से तकनीकी उपयोग के मुद्दों पर चमक रहा हूँ, मैं यह कहूँगा। कुल उपयोग के 15+ वर्षों के साथ मैंने GIT के साथ सीवीएस, एसवीएन, सीएमवीसी, क्लियरकेस, पेरफोर्स और एक पेशेवर सेटिंग में अन्य प्रणालियों का उपयोग किया है। अगर कोई चाहता था कि मैं जीआईटी के अलावा किसी और चीज़ का इस्तेमाल करूं (अपवाद के तौर पर शायद बज़्र, मर्क्यूरियल, पेरफोर्स और क्लीयरकेस (पिछले दो के सेटअप के आधार पर)) तो मुझे तुरंत पता चलेगा कि मेरा समय कहीं और अच्छा व्यतीत होता है। मैं 2009 में वापस सीवीएस और एसवीएन के लिए थोड़ा सा भत्ता देने के आरोप में उस निष्कर्ष पर था। मैं अपने कार्यस्थल पर एसवीएन का उपयोग कैसे किया जाता था, से मैं इतना तंग आ गया था कि मैंने 2010 की शुरुआत में अपने एसवीएन ग्राहक के रूप में जीआईटी का उपयोग करना शुरू कर दिया। जीआईटी को बदलने के लिए हमें समझाने में मदद करना।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.