विकास के तरीके जब एक ही समाधान पर सौ डेवलपर्स काम कर रहे हैं?


19

हम लगभग 200 डेवलपर्स से जुड़े एक संगठन हैं जो एक एकल उत्पाद (संशोधन नियंत्रण Git का उपयोग करके) पर लगातार काम कर रहे हैं जिसे एक निश्चित तिथि पर जारी करने की योजना है।

डेवलपर्स की भारी संख्या के कारण, हम प्रत्येक टीम में लगभग 10 डेवलपर्स के साथ "क्रॉस फंक्शनल" टीम बनाने की कोशिश कर रहे हैं, जिसके परिणामस्वरूप संगठन में लगभग 20 विकास दल हैं।

चूंकि हम मुख्य रिपॉजिटरी में उत्पाद के निरंतर "उच्च मानक" (जिसका अर्थ है कि जब डेवलपर एक पुल बनाता है, तो उत्पाद को कम से कम संकलित किया जाना चाहिए, आदि) होना चाहिए, हम कुछ प्रकार के गुणवत्ता वाले फाटकों का उपयोग करना चाहते हैं।

मैं थोड़ा अनिश्चित हूं कि प्रश्न का वाक्यांश कैसे बनाया जाए, लेकिन मैं सोच रहा हूं कि क्या मैं किसी एकल उत्पाद पर काम करने वाले डेवलपर्स के इतने बड़े समूह के लिए विकास के तरीकों की कुछ सलाह प्राप्त कर सकता हूं।

हमारी राय में, स्पेक्ट्रम का एक छोर प्रत्येक डेवलपर को मुख्य रिपॉजिटरी को सीधे प्रतिबद्ध करने की अनुमति देता है, हालांकि हमें डर है कि डेवलपर्स की उच्च संख्या के कारण / यह कहता है कि "मुख्य रिपॉजिटरी" लगातार टूटे हुए चरण में हो सकती है, कारण हम प्रत्येक कमिटमेंट के लिए "क्वालिटी गेट" की मांग नहीं कर सकते।

स्पेक्ट्रम के दूसरे छोर की तरह हो सकता है (हम सोचते हैं कि लिनुस टॉर्वाल्ड्स / लिनक्स यह करता है) एक पेड़ या पिरामिड संरचना है, जहां "मुख्य भंडार" में केवल तीन पुल स्रोत हैं, इन तीनों में केवल विश्वसनीय पुल स्रोतों आदि का एक मुट्ठी भर है। हालांकि, हमें लगता है कि परिवर्तन जैसी संरचना के साथ "मुख्य भंडार" में आने के लिए चढ़ाई करने के लिए एक लंबी श्रृंखला है। प्लस कि अगर एक मर्ज संघर्ष होता है, तो समस्या "मूल डेवलपर" की तुलना में किसी अन्य डेवलपर पर आ जाती है।

इस सभी पृष्ठभूमि की जानकारी और राय के साथ, हम इतने सारे डेवलपर्स के लिए अनुशंसित विकास विधियों को कैसे सीख और पढ़ सकते हैं? बड़े संगठन (Microsoft, Facebook, Ubuntu, इत्यादि) अपने विकास को कैसे बनाते हैं?


3
मुझे उत्तर पर यकीन नहीं है, लेकिन वास्तव में बड़ी प्रणालियों में, यहां तक ​​कि सबसे बड़ी / सबसे अच्छी (/ सबसे अधिक नफरत?) कंपनियां मुद्दों का सामना कर सकती हैं: moishelettvin.blogspot.co.uk/2006/11/…
ozz

13
बड़ी परियोजनाएँ एक-दूसरे से बात करते हुए बहुत कम परियोजनाएँ हैं ...
जॉरिस टिम्मरमन्स

1
फूट डालो और जीतो
SuperM

कॉनवेज लॉ यहां लागू होता है। अपनी टीम को फिट करने के लिए अपने आर्किटेक्चर को समायोजित करें।
डेव हिलियर

जवाबों:


23

आपको इंटरफ़ेस टीम के साथ मॉड्यूल में उत्पाद को विभाजित करने पर विचार करना चाहिए, उन घटक मॉड्यूल को एक उत्पाद में एक साथ लाना। बदले में इसका मतलब होगा कि मॉड्यूल विभाजन और पदानुक्रम के मिलान के लिए रिपॉजिटरी को विभाजित करना। यदि ऐसा प्रतीत होता है कि आप ऐसा नहीं कर सकते हैं, तो परियोजना संभवतः एक मर्ज से प्रेरित पड़ाव को पीस देगी, जिसमें योगदान करने वाले डेवलपर्स की संख्या पर विचार किया जाएगा।

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

बिल्ड सत्यापन के बारे में आपको एक निरंतर एकीकरण (CI) सर्वर की आवश्यकता होगी जिसका उद्देश्य कोड को स्वचालित रूप से बनाना और सत्यापित करना है। कोड सत्यापित करके मेरा मतलब है कि कोड सफलतापूर्वक संकलित करता है और परीक्षण पास करता है। Infact Jenkins (CI Server) को जेरिट सत्यापन चरण के भाग के रूप में जेरिट कोड समीक्षा प्रणाली से जोड़ा जा सकता है , जो पूरी तरह से प्रक्रिया को स्वचालित करता है।

इन एकीकरण साधनों के अलावा, समय विलय को कम करने के लिए विकास पद्धति के भाग के रूप में लगातार एकीकरण के लिए प्रयास करना महत्वपूर्ण है।

यह एक चुस्त विकास प्रक्रिया पर विचार करने के लायक हो सकता है जैसे कि स्क्रैम जिसका उद्देश्य एक जटिल उत्पाद को उत्पाद वृद्धि (मैनेजर्स) कहा जाता है। ये रिपॉजिटरी के बीच एकीकरण के अवसर प्रदान करेंगे।


7

स्पष्ट रूप से, 200 व्यक्ति विकास दल के साथ, आपके पास कुछ प्रकार की पदानुक्रमित संरचना होनी चाहिए। एक व्यक्ति या लोगों का एक छोटा समूह सॉफ्टवेयर उत्पाद के डिजाइन के बारे में निर्णय ले रहा है। आपकी विकास प्रक्रिया को यह प्रतिबिंबित करना चाहिए: आपको यह सुनिश्चित करने के लिए कोड समीक्षा और परीक्षण की आवश्यकता है कि सॉफ्टवेयर वास्तव में बनाया जा रहा है जो आप बनाना चाहते थे (साथ ही गुणवत्ता के उद्देश्य से)।

यहां तक ​​कि छोटी टीमों को नेताओं को टीमों का मार्गदर्शन करने और व्यक्तिगत घटकों के विकास के रूप में अपने काम की समीक्षा करने की आवश्यकता होती है। उनकी टीम स्तर पर गुणवत्ता नियंत्रण प्रक्रियाएं होनी चाहिए, साथ ही साथ।

तो, हाँ, आपको रिपॉजिटरी के संबंध में एक पदानुक्रमित संरचना का पालन करना चाहिए। यह समग्र रूप से परियोजना की पदानुक्रमित संरचना से मेल खाता है।

व्यक्तिगत घटकों को पर्याप्तता के एक निश्चित स्तर पर निर्मित और परीक्षण किया जाना चाहिए, इससे पहले कि आप उन सभी को एक साथ रखने के बारे में भी सोचें। 200 लोगों को सीधे मुख्य परियोजना के लिए प्रतिबद्ध करना अराजकता होगी। आपके पास प्रत्येक समूह के लिए अलग-अलग क्षेत्र होने चाहिए जहाँ व्यक्ति परियोजना के मुख्य निर्माण को प्रभावित किए बिना, दिन-प्रतिदिन के आधार पर अपने बदलाव कर सकते हैं।

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

यह भी एक अच्छी बात है कि "यदि मर्ज संघर्ष होता है, तो समस्या दूसरे डेवलपर पर आ जाती है" - विशेष रूप से, एक उच्च स्तरीय डेवलपर को यह तय करना चाहिए कि संघर्ष कैसे हल किया जाए।


5

जब आपके पास कुछ बड़ा होता है और (परिणामस्वरूप) असहनीय तरीके से इसे छोटे और प्रबंधनीय टुकड़ों में विभाजित किया जाता है।

कई कदम हैं जो आपको टीम और परियोजना को बेहतर बनाए रखने में मदद करेंगे:

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

  2. स्पष्ट दस्तावेज हैं। जब बहुत सारे लोग एक साथ काम कर रहे हों, तो चीजें आसानी से भुला दी जा सकती हैं या गलत समझा जा सकता है। इसलिए आपको आवश्यकताओं से लेकर वास्तु समाधान तक सभी दस्तावेजों पर विशेष ध्यान देने की आवश्यकता है।

  3. कार्यों के लिए लोग (लोगों के लिए कार्य कभी नहीं)। कार्यक्षमता को छोटे सेटों में विभाजित करने के बाद, इन सेटों पर काम करने के लिए टीमें बनाएं। इस स्तर पर टीम बनाना आसान होगा, क्योंकि आप पहले से ही जानते हैं कि प्रत्येक टीम को क्या काम करना है। और प्रत्येक टीम के अंदर कोड समीक्षा जैसे कार्य किए जाएंगे।

  4. कार्यों की स्पष्ट प्रणाली। 200 डेवलपर्स में से प्रत्येक को स्पष्ट रूप से पता होना चाहिए कि किस पर काम करना है। इससे आपको यह पता लगाने में मदद मिलेगी कि पहले से क्या किया गया है, प्रत्येक व्यक्ति क्या काम कर रहा है और कितना काम बाकी है।

  5. स्रोत नियंत्रण। (मुझे लगता है कि यह अन्य उत्तरों में अच्छी तरह से उल्लिखित है))

और अंत में, जितना संभव हो सके टीमों और मॉड्यूल की सरल संरचना बनाने की कोशिश करें। आप इतनी बड़ी परियोजना के साथ जटिलता बर्दाश्त नहीं कर सकते।


2

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


1

हॉटपॉटो के उत्तर (जो सीधे IMHO के निशान पर है) के अलावा, मैं कुछ स्रोत नियंत्रण फाटकों को लागू करने का भी सुझाव दूंगा, जैसा कि आप सुझाव देते हैं। जब हमने SCM के लिए एक बड़ी टीम और कोड बेस बनाया, तो हमने आपके द्वारा वर्णित मॉडल के समान "परोपकारी तानाशाह" विधि का उपयोग करने का निर्णय लिया।

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


0

मैंने एक विशाल प्रणाली पर काम किया है जिसमें लगभग 150M SLOC के साथ कई सौ डेवलपर्स ने एक साथ काम किया था। यह एक मेनफ्रेम पर था, इसलिए हम विजुअल स्टूडियो से बात नहीं कर रहे हैं, लेकिन सिद्धांतों को अभी भी अपनाया जा सकता है।

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

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

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

उदाहरण के लिए आपके पास एक नामस्थान या पैकेज के रूप में Organisation.Security.DirectoryServices होगा। अपने प्रासंगिक क्षेत्रों में सभी तर्क रखने से, टीमों ने काफी स्वायत्तता से काम किया। स्पष्ट रूप से कई टीमों से इनपुट की आवश्यकता वाली बड़ी परियोजनाएं हुईं, लेकिन वे बड़े पैमाने पर सुचारू संचालन थे।

आशा है कि ये आपकी मदद करेगा।

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