आज, मेरे एक सहकर्मी और मेरी एक बहस है "क्या हमें एसवीएन जैसे स्रोत नियंत्रण प्रणाली में विनिर्देशन दस्तावेज़ रखना चाहिए?"। मेरी राय में, यह होना चाहिए। विकासशील परियोजना से संबंधित सब कुछ स्रोत नियंत्रण प्रणाली के साथ सावधानीपूर्वक नियंत्रित किया जाना चाहिए। क्या सॉफ्टवेयर विकास प्रक्रिया में यह गलत अवधारणा है?
जवाबों:
तो क्या होगा यदि अधिकांश स्रोत नियंत्रण प्रणाली केवल उन्हें ब्लूबस के रूप में संग्रहीत करती हैं? अधिकांश लोग डॉक्स के बीच अंतर के बारे में एक चीर नहीं देते हैं, लेकिन यदि आप करते हैं, तो आप हमेशा दो संस्करण प्राप्त कर सकते हैं और उन्हें अलग करने के लिए संलेखन प्रणाली की सुविधा का उपयोग कर सकते हैं।
हार्ड डिस्क स्थान पेनीज़ पर प्रति माह प्रति गीगाबाइट के साथ, स्रोत नियंत्रण प्रणाली में दस्तावेज़ नहीं लगाने का कोई अच्छा कारण नहीं है, और यह उपयोगी होने की संभावना है। मेरी व्यक्तिगत प्राथमिकता इनलाइन मार्कअप, जैसे विकी मार्कअप या डॉकबुक का उपयोग करके दस्तावेज़ लिखना है । यह दस्तावेज़ तुलना और संशोधन के लिए शक्तिशाली उपकरणों के उपयोग की अनुमति देता है।
संस्करण विनिर्देशन दस्तावेज़ निश्चित रूप से एक योग्य लक्ष्य है।
हालाँकि, क्या आपके विनिर्देशन दस्तावेज़ केवल-पाठ और एक सादे पाठ फ़ाइल में हैं ? यदि हां, तो यह एक अच्छा समाधान हो सकता है।
यदि नहीं, तो स्रोत नियंत्रण शायद उनके लिए सही जगह नहीं है - स्रोत नियंत्रण बाइनरी फ़ाइलों के लिए खराब है ।
आमतौर पर, सादे पाठ फ़ाइलें न तो स्वरूपण के लिए या जल्दी देखने के लिए उतनी ही अच्छी होती हैं, इसलिए संस्करण के साथ विकि एक बेहतर विचार है।
सभी दस्तावेज संग्रह के किसी न किसी रूप में होना चाहिए (अधिमानतः संशोधन नियंत्रण के साथ)।
स्रोत नियंत्रण प्रणाली एक समाधान है। लेकिन आमतौर पर इन प्रणालियों को सादे पाठ दस्तावेजों के लिए डिज़ाइन किया गया है। इस प्रकार वर्ड या आरटीएफ डॉक्यूमेंट आदि चीजें इतनी अच्छी तरह से फिट नहीं होती हैं (खासकर जब आप कोशिश करते हैं और विभिन्न संस्करण की तुलना करते हैं)।
लेकिन विशेष रूप से दस्तावेजों के लिए डिज़ाइन किए गए अन्य समाधान हैं। SharePoint मन को पसंद करता है, लेकिन मुझे यकीन है कि अन्य लोग भी हैं।
निश्चित रूप से। समस्याएँ जो दस्तावेज़ बायनेरिज़ के रूप में संग्रहीत की जाती हैं (उदाहरण के लिए शब्द दस्तावेज़) कष्टप्रद है। यदि आप एक कछुआ उपकरण (मैंने SVN और Mercurial की कोशिश की है) का उपयोग करने पर एक अच्छा समाधान यह है कि आप "विजुअल डिफ" का चयन कर सकते हैं जो आपको डॉकडिफ़ चुनने की अनुमति देता है। Docdiff के साथ आपको रंगों और सामानों के साथ सभी बदलाव देखने को मिलते हैं :-) मुख्य नुकसान यह है कि हर बार जब आप बदलाव करते हैं तो पूरा दस्तावेज़ फिर से शुरू हो जाता है (केवल परिवर्तन नहीं)। लेकिन यह देखते हुए कि पाठ दस्तावेज़ सामान्य रूप से विशाल नहीं हैं और यह स्थान संभवतः आपका मुख्य मुद्दा नहीं है, यह कोई समस्या नहीं है।
मुझे यकीन है कि आप कछुए के बिना डॉकडिफ़ का उपयोग कर सकते हैं, यह सिर्फ इतना है कि मैंने इसे आज़माया नहीं है।
एक वैकल्पिक दृष्टिकोण है जिस पर आपको चर्चा करनी चाहिए: बीडीडी
कृपया निष्पादन योग्य विनिर्देशों के साथ व्यवहार प्रेरित विकास पर विचार करें। आपके विनिर्देशों को दी जाने वाली श्रृंखला में सरलीकृत किया जाता है - जब - तब बयानों के सेट जो पाठ फ़ाइलों में संग्रहीत होते हैं। ककड़ी या SpecFlow जैसे एक BDD टूल उन पाठ फ़ाइलों को निष्पादन योग्य परीक्षणों में परिवर्तित करता है, जो आपके बिल्ड टूल निष्पादित कर सकते हैं।
ककड़ी: http://cukes.info/ - रूबी के लिए बीडीडी
SpecFlow: http://www.specflow.org/ - .Net के लिए BDD
SpecFlow जैसे टूल के साथ वर्कफ़्लो के त्वरित डेमो के लिए, रोब कॉनरी के SpecFlow के माध्यम से चेकआउट करें: http://tekpub.com/view/concepts/5
अब, न केवल आप अपने कोड, बल्कि आपके विनिर्देशों, और आपके कंटीन्यूअस इंटीग्रेशन टूल (टीमकिट, क्रूज़कंट्रोल, हडसन, आदि) को लागू कर रहे हैं कि सभी विनिर्देश अभी भी हर निर्माण पर मान्य हैं ... क्या आप इसके लिए मूल्यवान हैं?