दो डेवलपर्स के लिए एसक्यूएल परिवर्तन स्क्रिप्ट प्रबंधित करने का सबसे अच्छा तरीका क्या है?

Question

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

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

धन्यवाद।

Answer 1

मैं वर्तमान में एक फ़ोल्डर में मेरी एसक्यूएल परिवर्तन स्क्रिप्ट की दुकान और उन्हें, स्क्रिप्ट आदेश संख्या, tablename, परिवर्तन का वर्णन नाम

1-उपयोगकर्ता-बनाने-table.sql

2-उपयोगकर्ता द्वारा जोड़े गए-columns.sql

...

एन

जब मैं ये स्क्रिप्ट मैं उन्हें एक नए फ़ोल्डर में ले जाते हैं, "रिलीज 2009-09-01" नाम निष्पादित कर दिया है और और फिर अगले संख्या

Answer 2

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

Answer 3

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

Answer 4

हम के रूप में परिवर्तन नियंत्रण स्क्रिप्ट स्रोत के साथ जारी है। एसक्यूएल फाइलें, फिर बैच फ़ाइल में एसक्यूएल फाइलों के लिए निष्पादन का आदेश रखें, जो स्रोत नियंत्रण में भी है।

SQLScripts.Bat:

SET BASEDIR=%%1 
SET SERVER=%%2 
SET DATABASE=%%3 

CALL RUNISQLW CreateUserPresets %BASEDIR% %SERVER% %DATABASE% 
CALL RUNISQLW CreateFundWorkflows %BASEDIR% %SERVER% %DATABASE% 
CALL RUNISQLW spFundWorkflowAddFromTemplate %BASEDIR% %SERVER% %DATABASE% 
CALL RUNISQLW spFundWorkflowListForGrid %BASEDIR% %SERVER% %DATABASE% 
CALL RUNISQLW spWorkflowTasksListForGrid %BASEDIR% %SERVER% %DATABASE% 
CALL RUNISQLW fGetToleranceDate %BASEDIR% %SERVER% %DATABASE% 
CALL RUNISQLW fGetNotifyDate %BASEDIR% %SERVER% %DATABASE% 
CALL RUNISQLW spWorkflowTasksManager %BASEDIR% %SERVER% %DATABASE% 
CALL RUNISQLW spWorkflowTasksAnalyst %BASEDIR% %SERVER% %DATABASE% 
CALL RUNISQLW spWorkflowTasksNotify %BASEDIR% %SERVER% %DATABASE% 
CALL RUNISQLW AddGateFrequency %BASEDIR% %SERVER% %DATABASE% 

pause 

RUNISQLW: 

@REM First Parameter: Name of SQL file, without the .SQL extension. 
@REM Second Parameter: Base Directory to run the file in. 
@REM Third Parameter: Name of the server to run the file on. 
@REM Fourth Parameter: Name of the Database on the server. 

osql -S %3 -d %4 -E -i %2\%1.sql -o %2\Output\%1.txt 

हम तो प्रत्येक विन्यास environemt के लिए एक deployment.bat फ़ाइल से SqlScripts बैच फ़ाइल कहते हैं, देव, स्टेजिंग या बैच फ़ाइल एक पैरामीटर के रूप एसक्यूएल फ़ाइल के साथ OSQL कॉल उत्पादन। यह इसे कॉन्फ़िगरेशन में लगातार रखता है।

Answer 5

यदि आप वीएस टीम संस्करण का उपयोग कर रहे हैं तो आप SQL सर्वर संस्करण का उपयोग कर डेटाबेस प्रोजेक्ट बनाने के लिए डेटाबेस संस्करण का उपयोग कर सकते हैं।

फिर, डेटाबेस से प्रोजेक्ट बनाएं, ताकि आपको परियोजना में सभी फ़ंक्शन, दृश्य, टेबल मिल सकें।

फिर, जब भी आप परिवर्तन करते हैं, इसे प्रोजेक्ट में बनाते हैं, इसलिए यह आसानी से svn में हो सकता है (प्रत्येक फ़ाइल वहां है) और फिर आप बस अपने SQL सर्वर डेटाबेस को सिंक कर सकते हैं।

इस तरह आप अपने डेटा को गड़बड़ किए बिना आपके टीम के साथी को बदलने से अपने डेटाबेस को अपडेट कर सकते हैं।

Answer 6

एक और तरीका है की तरह http://www.red-gate.com/products/SQL_Compare/index.htm

एक उपकरण यह एक तैनाती के लिए एक परिवर्तन स्क्रिप्ट उत्पन्न करता है। अच्छी बात यह है कि आपको डेवलपर्स के अनुशासन पर अब गिनना नहीं है।

इसके अलावा, मुझे अभी भी एसवीएन में डीबी होना पसंद है। मैं इसके लिए SQLScript का उपयोग करता हूं, free utility to script DB objects in ms sql देखें।

संपादित

मैं अब Redgate SQL Version का उपयोग करें। इसके साथ एसवीएन में बदलाव डालना बहुत आसान है। एकमात्र समस्या यह है कि मुझे आवेदन शुरू करना और उपयोग करना है, यह स्वचालित प्रक्रिया नहीं है।

Answer 7

सीखना शुरू करें कि अपने स्रोत नियंत्रण के साथ शाखाओं का उपयोग कैसे करें। सहयोगी रूप से काम करते समय कौन सा मूल्यवान हो सकता है।

कुछ शाखाओं में रणनीति हो सकता है:

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

Answer 8

पैचिंग DBSourceTools में इस्तेमाल इंजन पर एक नज़र डालें।
यह विशेष रूप से डेवलपर्स को स्रोत-कोड नियंत्रण के तहत SQL सर्वर डेटाबेस प्राप्त करने में सहायता करने के लिए डिज़ाइन किया गया है।

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

यह आपको वी 1 से v2 तक लागू होने वाले सभी पैच का परीक्षण करने के लिए एक दोहराने योग्य प्रक्रिया है।
DBSourceTools में इन स्क्रिप्ट को बनाने में आपकी सहायता करने के लिए कार्यक्षमता भी है, यानी स्कीमा तुलना या स्क्रिप्ट डेटा टूल्स।

एक बार जब आप कर लेंगे, तो आपकी पैच निर्देशिका में मौजूद सभी फ़ाइलें आपकी रिलीज बन जाएंगी, और आपके डेटाबेस को v1 से v2 में अपग्रेड कर देगी।

मज़े करें।