स्रोत कोड हैंडओवर योजना तैयार करें [बंद]


12

हमारी कंपनी एक विशाल उत्पाद के स्रोत कोड का अधिग्रहण करने वाली है।

जब हैंडओवर शुरू होता है, तो यह सुनिश्चित करने के लिए कि हमारे पास सब कुछ है और भविष्य में उस उत्पाद को बनाए रखने में सक्षम होने के लिए क्या चीज है?


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

हम पर्याप्त भाग्यशाली नहीं हैं। हम ऐसा नहीं कर सकते हैं कि अधिकतम हम कर सकते हैं कुछ इंजीनियर 3-4 सप्ताह के लिए उपलब्ध है।
अहमद असवानी

मुझे एक संबंधित उत्तर मिला है जो मुझे लगता है कि यह पूरा करता है जो यहां सबसे अधिक उत्तर देता है।
अहमद असवानी

जवाबों:


8

सबसे पहले शुभकामनाएँ।

यहां कुछ चीजें दी गई हैं, जिनके बारे में आपको संभवतः पूछना चाहिए / प्रदान किया जाना चाहिए।

  • ज्ञात दोषों की सूची।
  • घटना और समस्या रिकॉर्ड की सूची।
  • पिछले दो रिलीज पर विवरण जैसे; उन्हें लागू करने में कितना समय लगा, क्या रिलीज के बाद बढ़ी घटनाओं की अवधि थी, आदि।
  • प्रमुख विषय विशेषज्ञ कौन हैं।
  • संचालन और प्राथमिक सहायता के घंटे क्या हैं।
  • उत्पाद कितने समय से अस्तित्व में है और कोड बेस कितना स्थिर है।
  • उत्पाद रोडमैप क्या है।
  • क्या है टेक्नोलॉजी स्टैक।
  • एकीकरण बिंदु क्या हैं, और कौन एकीकृत प्रणालियों का समर्थन करता है।
  • क्या कोई डीआर घटक हैं
  • DR पर आक्रमण करने के लिए कौन जिम्मेदार है
  • आवेदन SLA या सेवा लक्ष्य क्या हैं।
  • फ़ाइल सिस्टम / डेटाबेस / संदेश कतारों की अपेक्षित वृद्धि क्या है।
  • सिस्टम बैकअप कब किया जाता है, कौन जिम्मेदार है और बहाली की रणनीति क्या है।
  • उत्पाद बैकलॉग के प्रबंधन के लिए कौन जिम्मेदार है।
  • क्या विक्रेता SLA और संपर्क विवरण जगह में हैं।
  • क्या कोई बैच शेड्यूल या लंबे समय तक चलने वाली प्रक्रियाएं हैं।
  • क्या सिस्टम पूरी तरह से ट्रांजेक्शनल है और कॉन्सेप्ट कैसे मैनेज किया जाता है।
  • आवेदन के लिए प्रमुख घटना प्रबंधन प्रक्रिया क्या है।
  • क्या, कब, कौन और कैसे हितधारक परिवर्तन और आउटेज की सूचना देते हैं।
  • सहमत आउटेज अवधि / समय क्या हैं।
  • सोर्स कोड कहां रखा गया है।
  • स्रोत कोड का बैकअप, पुनर्स्थापना और परिवर्तन लॉग कैसे प्रबंधित किया जाता है।
  • कहां, क्या और कौन समाधान वास्तुकला का मालिक है।
  • तैनाती लक्ष्य क्या है (DEV, ST, UAT, Pre PROD, PROD, DR)।
  • जब 3 पार्टी लाइसेंस का नवीनीकरण किया जाता है।
  • क्या कोई आरएसीआई चार्ट है
  • कितने उपयोगकर्ता हैं और वे कहाँ स्थित हैं।
  • सामान्य समस्या निवारण समस्याएं या शिकायतें क्या हैं।
  • सिस्टम एक्सेस देने के लिए कौन जिम्मेदार है।
  • जब पंच परीक्षण / सुरक्षा ऑडिट किए जाते हैं।
  • जहां CI और स्वचालित निर्माण प्रक्रिया है।
  • स्रोत नियंत्रण और सर्वर बनाने के लिए कौन जिम्मेदार है।
  • स्थापना गाइड कहां हैं।
  • क्या लक्ष्य के बुनियादी ढाँचे और नेटवर्क के लिए प्रलेखन है।
  • हाल की घटनाओं से गंभीरता और प्रभाव के प्रकार क्या हैं।
  • क्या डेवलपर वर्कस्टेशन सेटअप निर्देश हैं।
    • विकास सहयोगी और चौखटे क्या उपयोग किए जाते हैं और क्या वे आपकी टीम के लिए लाइसेंस प्राप्त हैं।

इस समय मैं यही सोच सकता हूं।


8
कृपया "DR", "DEV, ST, UAT, प्री PROD, PROD, DR" और "RACI" को परिभाषित करें। ध्यान दें कि यह कुछ स्रोत कोड के लिए अप्रासंगिक है (यानी, RACI चार्ट संगठनात्मक हैं, कोड संबंधित नहीं हैं।)
S.Lott

मैं केवल स्रोत कोड के वर्तमान संस्करणों के लिए नहीं, जो स्रोत स्रोत कोड रिपॉजिटरी तक पहुंच प्राप्त करूंगा। इसमें टिप्पणियाँ अक्सर टेलिउ को क्यों कोड को एक विशेष तरीके से बदल दिया गया था। यह बनाए रखने के लिए iknwo करने के लिए महत्वपूर्ण है।
HLGEM

@HLGEM खेद है कि सभी घटकों के लिए पूर्ण स्रोत कोड निहित स्रोत कोड के वर्तमान संस्करणों पर मेरा बयान (वैसे भी मेरे लिए अच्छा है)।
केन

@ S.Lott DR का उपयोग "आपदा वसूली" का वर्णन करने के लिए किया जाता है। देव "विकास पर्यावरण" के लिए एक सामान्य शब्द है, जो भी आपके पर्यावरण के लिए शामिल है। ST सिस्टम टेस्टिंग एन्वायरमेंट के लिए एक संक्षिप्त नाम है। मैं असहमत हूं कि आरएसीआई एक संगठनात्मक उपकरण है क्योंकि इसका उपयोग यह वर्णन करने के लिए किया जाता है कि कौन जिम्मेदार, जवाबदेह, सूचित और परामर्शित है। तो जब कोड प्रतिबद्ध है तो इसके लिए कौन जिम्मेदार है? सहकर्मी समीक्षा के हिस्से के रूप में किसे सलाह दी जाती है? किसे सूचित किया जाता है कि एक निर्माण सफल हुआ / असफल? और इसी तरह
केन

@kame: कृपया उत्तर को परिभाषाओं के साथ अपडेट करें । कृपया उत्तर में अभी और टिप्पणियाँ न जोड़ें। कृपया जवाब अपडेट करें।
एसएलटी

6

जब हैंडओवर शुरू होता है, तो यह सुनिश्चित करने के लिए कि हमारे पास सब कुछ है और भविष्य में उस उत्पाद को बनाए रखने में सक्षम होने के लिए क्या चीज है?

जिन चीजों को आपको सुनिश्चित करना चाहिए, वे हैं:

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

बाकी सब कुछ वर्तमान अनुरक्षक को सौंपने के लिए है।


2
मेरा सुझाव है कि इन शब्दों को संशोधित करने के लिए "आपको उन्हें देखना होगा ..." जैसे, "आपको उन्हें कोड बनाने के लिए देखना होगा" और "आपको उन्हें यूनिट परीक्षण चलाने के लिए देखना होगा", आदि साक्ष्य यहां महत्वपूर्ण हैं।
लोट

@ S.Lott वे एक दस्तावेज़ में दिखाते हैं, या लिखते हैं, इससे कोई फर्क नहीं पड़ता। अहमद असवानी और उनकी टीम आवेदन को बनाए रखने जा रही है, और अपने दम पर उपरोक्त सभी कदम उठाने में सक्षम होना चाहिए। मैंने उत्तर को थोड़ा संशोधित किया है, लेकिन मुझे यकीन नहीं है कि यदि आपने सुझाव दिया है।
B

1
एक दावा है कि कोड का निर्माण वैसा नहीं है जैसा कि वास्तव में कोड का निर्माण होता है। वहाँ गया। हो गया। प्रलेखन अस्पष्ट, या भ्रमित या अधूरा हो सकता है। यह पुराना "ट्रस्ट लेकिन वेरिफाई" सिद्धांत है। जब तक आप इसे नहीं देखते, तब तक इस पर विश्वास न करें।
S.Lott

1
@ S.Lott ठीक है समझ में आता है। अब जब मैं इसके बारे में सोचता हूं, मैं पहले भी ऐसी ही स्थिति में था, जहां उन्होंने हमें टूटे हुए एचडब्ल्यू बोर्डों पर कुछ लागू करने के लिए बनाया। हमने यह पता लगाने में 4 महीने बिताए कि वास्तव में क्या गलत है।
B27ови

5

आपको यह सुनिश्चित करने की आवश्यकता है कि कोड सौंपने वाली टीम समय की अवधि के लिए समर्थन प्रदान करेगी। इसे एक हस्ताक्षरित अनुबंध बनाएं!

आपके पास बाद में प्रश्न होंगे कि आपको नहीं पता था कि आपको अग्रिम पूछना है, इसलिए उन्हें आपको समझाने के लिए "चारों ओर छड़ी" की जरूरत है ताकि आप कोड, डॉक्स और जो भी परियोजना पर हों, उन्हें न दें।

जब आपके पास एक प्रोजेक्ट हैंडओवर होता है तो आप एक महत्वपूर्ण चीज को ढीला करते हैं: मूल टीम का अनुभव।

आपको कभी-कभी कुछ ऐसा भी मिलता है जिसकी आपको उम्मीद नहीं थी: उनकी दुश्मनी।

क्या कंपनी हैंडओवर कर रही है, जो हैंडओवर के साथ अच्छी डील कर रही है? यदि वे व्यापार को ढीला कर देते हैं क्योंकि वे आपको परियोजना को बदल देते हैं, तो (गर्व) डेवलपर्स ने कोड बनाया जो इस तथ्य को नाराज कर सकता है कि उनका "बच्चा" दूर दिया गया है। आपको इस तरह की प्रतिक्रियाएं मिल सकती हैं: "यह आपके द्वारा प्राप्त डॉक्स में है ... भले ही यह नहीं है।"

तकनीकी पहलुओं को कवर करना अच्छा है, लेकिन इसके मानवीय पक्ष को भी ध्यान में रखना चाहिए।

YMMV!


0

क्या कोड टेस्ट-सूट के साथ आता है? क्या परीक्षण-सूट पास में सभी परीक्षण हैं? सुइट में कितना कवरेज है?

मेरा सुझाव है कि, एक परीक्षण सूट याद आ रही है, तो आप परीक्षण सूट और संबंधित ढांचे के निर्माण को अपनी पहली प्राथमिकता बनाते हैं।

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