मेरे एसवीएन ट्रंक को साफ रखने और तैनाती के लिए तैयार रखने की भावना में, मैं the following source control model का उपयोग कर रहा हूं। अधीर के लिए, मूल अवधारणा यह है कि आप वास्तविक विकास करने के लिए विकास शाखाएं बनाते हैं, और किसी भी समय ट्रंक को साफ और तैनाती के लिए तैयार करते हैं (ट्रंक में कोई जंक नहीं)।टीमसिटी प्रोजेक्ट्स और एकाधिक एसवीएन शाखाएं
इसके अतिरिक्त, मैं निरंतर एकीकरण के लिए टीमसिटी को कॉन्फ़िगर कर रहा हूं। टीमसिटी के भीतर, मैं यह सुनिश्चित करना चाहता हूं कि सभी विकास शाखाएं, साथ ही तैनाती-तैयार शाखा (मेरे मामले में ट्रंक) सही ढंग से निर्माण करें और सभी यूनिट परीक्षणों को पास करें।
यह एक बेवकूफ सवाल हो सकता है, लेकिन टीमसिटी से अत्यधिक परिचित नहीं होने पर, क्या मुझे प्रत्येक शाखा के लिए एक नई टीमसिटी परियोजना बनाना चाहिए? तैनाती-तैयार शाखा, विशेष रूप से, विकास शाखा की तुलना में कुछ अतिरिक्त नियम हैं। उदाहरण के लिए, रिलीज को सिस्टम सिस्टम पर संस्करणित निर्देशिकाओं में सहेजा जाना चाहिए (उदाहरण के लिए, सी: \ प्रोजेक्ट्स \ MyProject \ 1.0.187 ..., सी: \ प्रोजेक्ट्स \ MyProject \ 1.0.188 ...) आसान पहुंच को सक्षम करने के लिए समय पर किसी भी समय द्विआधारी। दूसरी ओर, विकास शाखाओं में असेंबली की संस्करणित प्रतियों की बचत आवश्यक नहीं है और हार्ड डिस्क स्थान बर्बाद कर देगा।
टीमसिटी के भीतर, मैं प्रत्येक सॉफ्टवेयर प्रोजेक्ट के लिए केवल एक ही प्रोजेक्ट देखना पसंद करूंगा। दूसरे शब्दों में, यदि मेरी कंपनी विकास परियोजनाओं की एक्स संख्या पर काम कर रही है, तो मैं यह देखना चाहता हूं कि परियोजना केवल एक बार सूचीबद्ध है, एक्स * 2 नहीं (मान लीजिए कि प्रत्येक प्रोजेक्ट में केवल दो शाखाएं हैं)।