@ सिमोन के जवाब के अलावा।
सभी सॉफ्टवेयर इंजीनियरिंग में प्रोग्रामिंग, डिजाइनिंग या मॉडलिंग के बारे में नहीं है। काम के दिनों में हम लगातार काम करते हैं। आपने पहले ही एक का उल्लेख किया है - आईडीई के बाहर परियोजना का निर्माण - लेकिन कई और भी हैं।
अनुभवी / सक्रिय डेवलपर्स इन कार्यों को स्वचालित करते हैं। कुछ, यहां तक कि उपकरण तब बनाते हैं जब ये कार्य SDLC का हिस्सा बन जाते हैं और वे थकाऊ होते हैं - और गलती से - हाथ से करने के लिए। कार्यक्रम दोहराव वाले काम करने में अच्छे हैं, चाहे वे कितने भी थकाऊ क्यों न हों। हम - इंसान - वो अच्छे नहीं हैं।
इन उपकरणों / लिपियों के अन्य सकारात्मक प्रभाव हैं
- उत्पादकता
- ज्ञान का हस्तांतरण
- स्वायत्तता (नए लोगों के लिए)
तो, हाँ स्क्रिप्ट एससीएम में होनी चाहिए और उन्हें डेवलपर के टूलबॉक्स में एक और उपकरण होना चाहिए।
फ़ोल्डर के बारे में /scriptsमैं कहूंगा कि यह कोई फर्क नहीं पड़ता। सादगी के लिए मैं उन्हें परियोजना की मूल निर्देशिका में छोड़ देता हूं ताकि स्क्रिप्ट में घोषित सभी मार्ग परियोजना के फ़ोल्डर के सापेक्ष हों । अगर मुझे बाहरी फ़ोल्डर या फ़ाइलों तक पहुंच की आवश्यकता है, तो मैं नरम लिंक बनाता हूं ।
SCM में स्क्रिप्ट की जाँच करने से पहले विचार करने योग्य बातें।
सुरक्षा के लिए, सुनिश्चित करें कि लिपियों में कोई हार्डकॉन्ड क्रेडेंशियल्स नहीं हैं - आदर्श रूप से, लिपियों को अच्छी तरह से पैराड्राइज्ड होना चाहिए -
सुनिश्चित करें कि स्क्रिप्ट सिस्टम के लिए अजीब चीजें नहीं करते हैं, उदाहरण के लिए आदेशों को निष्पादित करने के लिए जो पूर्ववत नहीं किया जा सकता है (सबसे विशिष्ट rm -rf)।
चूंकि ये परियोजना के स्रोत का हिस्सा बन जाते हैं, इसलिए दस्तावेज़ीकरण की बहुत सराहना की जाती है।
स्क्रिप्टिंग रॉकेट साइंस नहीं है। स्क्रिप्ट संक्षिप्त करें। एक के बजाय उन सभी पर शासन करने के लिए ... और अंधेरे में उन्हें बांधें , अधिक, छोटे और संक्षिप्त बनाएं। मानो आप SRP लगा रहे थे।