2011-10-06 7 views
6

मैं अपने उत्पादों के निर्माण की देखभाल करता हूं और आवश्यकता होने पर विभिन्न शाखाओं के निर्माण के लिए मौजूदा निर्माण परिभाषा को अनुकूलित करने के तरीके के साथ आने के लिए कहा गया है।क्या एकाधिक शाखाओं के लिए एक एकल टीएफएस 2010 निर्माण परिभाषा का उपयोग किया जा सकता है?

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

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

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

मैं भी इस परीक्षण कार्यक्रम निर्माण परिभाषा यह है कि एक से अधिक शाखा

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

1 अंतर - मैं एक कार्यस्थान चर और बनाता संदर्भ उनके संबंधित शाखाओं, फ़ोल्डर संपत्ति का विशेष रूप से ServerItem संपत्ति के फ़ोल्डर संपत्ति देखा

2 अंतर - प्रोजेक्ट फ़ाइलें बनाया जा रहा (BuildSettings.ProjectsToBuild) संबंधित शाखाओं

2 का निर्माण इन

मुख्य प्रश्न यहाँ के अलावा अन्य लॉग्स के बीच किसी भी अन्य मतभेद नहीं देखा है से आ रहे हैं:

क्या एक एकल निर्माण परिभाषा के लिए बनाई जा रही शाखाओं को स्वैप करने का एक मानक तरीका है?

यदि नहीं, तो क्या निर्माण के कतार में प्रवेश की गई शाखा में कस्टमाइज्ड वर्कफ़्लो टेम्पलेट (वर्कस्पेस और बिल्डसेटिंग.प्रोजेक्ट्स टूबिल्ड में) में डिफ़ॉल्ट मुख्य शाखा में सभी संदर्भों को बस बदलना संभव होगा? किसी भी और सभी मदद

उत्तर

4

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

  1. मैंने वर्कफ़्लो में एक तर्क जोड़ा ताकि निर्माण कतार में आवश्यक शाखा दर्ज की जा सके।

  2. मैं निर्माण के लिए ड्रॉप स्थान परिवर्तित कर दिया है ताकि यह प्रवेश किया शाखा (वैकल्पिक)

  3. निर्माण मशीन शाखा के लिए पर एक अलग स्रोतों निर्देशिका बनाया गया निर्माण

  4. initialised के लिए प्रासंगिक है वर्कस्पेसनाम और स्रोत डायरेक्ट्री ताकि वे नए वर्कस्पेस नाम और स्रोत निर्देशिका फ़ोल्डर से मेल खाते हैं

  5. मैंने BuildSettings.ProjectsToBuild में परियोजनाओं/समाधानों की सूची बदलने के लिए एक कस्टम गतिविधि बनाई है ताकि वे संदर्भ दे रहे हों उन्हें दर्ज शाखा से

  6. मैंने अपने परीक्षण चरण के माध्यम से देखा कि भले ही प्रवेश शाखा के लिए मेरा नया कार्यक्षेत्र प्रारंभिक रूप से दर्ज की गई शाखा का उपयोग अपने सर्वरइटम के रूप में करने के लिए किया गया था, फिर भी यह सर्वरइटम के साथ वर्कस्पेस बनायेगा निर्माण परिभाषा में प्रवेश किया। इस के आसपास पाने के लिए, मैं शाखा कार्यक्षेत्र को पुन: मैप करने के लिए इतना है कि ServerItem सही शाखा की ओर इशारा करते था एक और कस्टम गतिविधि बनाया

कुछ अन्य चीजें हैं जो मैं अपने कार्यप्रवाह में शामिल कर रहे हैं, लेकिन वे और अधिक कर रहे हैं मेरे डेवलपर्स ने अनुरोध किया है कि उपरोक्त चरणों के परिणामस्वरूप कई शाखाएं एकल निर्माण परिभाषा के लिए बनाई गई हैं।

+0

के बजाय चयनित शाखा का संदर्भ देने के लिए काम कर रहे होंगे यदि आप इस समस्या को हल करने के तरीके के बारे में अधिक जानकारी देंगे, तो मैं ऊपर उठाऊंगा। –

+1

@ वर्मीन: सहमत ... मैं आपका समाधान भी देखना चाहता हूं। –

0

संक्षेप में के लिए पहले से

हमेशा की तरह, धन्यवाद: नहीं और हाँ :-)

एक थोड़ा और अधिक विस्तार उन उत्तरों पर, TFS सिस्टम डिफ़ॉल्ट टेम्पलेट्स एक भी शामिल किया जाना पसंद आप जिस शाखा को बनाना चाहते हैं, उसके लिए परिभाषा बनाएं, या उन सभी शाखाओं को निर्दिष्ट करें जिन्हें ऑनस पर निर्माण करने की आवश्यकता है, लेकिन एक एकल निर्माण परिभाषा में। आपके पास कतार के नए निर्माण संवाद में उपलब्ध शाखाओं में से चुनने का एक मानक तरीका नहीं है।

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

यह काम करना चाहिए, हालांकि, मुझे इस बात की दिलचस्पी है कि आप इस क्षमता को कैसे चाहते हैं? क्या आप वीएस समाधान फाइलों का उपयोग नहीं कर रहे हैं?

+0

हाय, आपकी मदद के लिए धन्यवाद। मैंने अपने कार्यप्रवाह में परिवर्तन करने की उम्मीद की है (उम्मीद है कि) मेरे लक्ष्य को प्राप्त करें। आपके प्रश्न के उत्तर में, समाधान फ़ाइल के लिए प्रोजेक्ट फ़ाइलों को बनाने के लिए बिल्ड परिभाषा स्थापित नहीं की गई है, न कि समाधान फ़ाइल स्वयं। – Vermin

+0

इसके अलावा, भवन में शाखाओं को जोड़ने के विरोध में बिल्डिंग परिभाषा में बनाई गई डिफ़ॉल्ट शाखा को बदलने का एक मामला अधिक है, इसलिए वर्तमान में चुने गए शाखा के लिए एक अलग वर्कस्पेस का उपयोग करने पर काम कर रहा हूं (वर्कफ़्लो तर्क के माध्यम से दर्ज किया गया है जब कतार में निर्माण) और फिर BuildSetting.ProjectsToBuild को डिफ़ॉल्ट शाखा – Vermin

1

मैं अपनी बिल्ड परिभाषाओं में कुछ और शाखा चपलता भी चाहता था, इसलिए मैंने परियोजनाओं को बदलने के लिए एक कोड गतिविधि लागू की (जैसे उपरोक्त चरण 5 ऊपर)। यहाँ कोड (हटाया परियोजना विशिष्ट सामान) है: ConvertProjects() के लिए इकाई परीक्षण

[BuildActivity(HostEnvironmentOption.All)] 
public sealed class ConvertProjectsAccordingToBranch : CodeActivity 
{ 
    public static string s_MainBranch = "$/MyTeamProject/Main"; 

    public InArgument<IBuildDetail> BuildDetail { get; set; } 
    public InArgument<BuildSettings> BuildSettingsOriginal { get; set; } 
    public OutArgument<BuildSettings> BuildSettingsConverted { get; set; } 

    protected override void Execute(CodeActivityContext context) 
    { 
     Logger.Instance.Init(context); 
     IBuildDetail buildDetail = BuildDetail.Get(context); 
     BuildSettingsConverted.Set(context, ConvertProjects(BuildSettingsOriginal.Get(context), buildDetail.BuildDefinition)); 
    } 

    /// <summary>Returns a BuildSettings with ProjectsToBuild converted according to the build definition's workspace</summary> 
    public BuildSettings ConvertProjects(BuildSettings settingsOriginal, IBuildDefinition buildDefinition) 
    { 
     var mappings = buildDefinition.Workspace.Mappings; 
     if (mappings.Count() != 1) 
     { 
      throw new BuildProcessException(string.Format(CultureInfo.InvariantCulture, 
       "Build definition must have exactly one workspace mapping. Build definition ID:{0} has {1} mappings", 
       buildDefinition.Id, // IBuildDefinition doesn't have any Name property, seriously! 
       mappings.Count())); 
     } 

     string definitionBranch = mappings.First().ServerItem; 
     var settingsConverted = new BuildSettings() 
     { 
      PlatformConfigurations = settingsOriginal.PlatformConfigurations, 
     }; 

     foreach (string projectOriginal in settingsOriginal.ProjectsToBuild) 
     { 
      var projectConverted = projectOriginal.Replace(s_MainBranch, definitionBranch); 
      if (!projectConverted.StartsWith(definitionBranch)) 
      { 
       throw new BuildProcessException(string.Format(CultureInfo.InvariantCulture, 
        "Project {0} is not under main branch {1}, Definition branch: {2}", 
        projectOriginal, s_MainBranch, definitionBranch)); 
      } 

      settingsConverted.ProjectsToBuild.Add(projectConverted); 
      Logger.Instance.Log("Converted ProjectToBuild: {0}, original: {1}", projectConverted, projectOriginal); 
     } 

     return settingsConverted; 
    } 
} 

मैं भी है, लेकिन यह स्थानीय सामान पर निर्भर है, तो मैं इसे यहाँ पोस्ट नहीं किया था। यह मामूली है, और निश्चित रूप से लिखने लायक है!

1

मुझे पता है कि यह बहुत पुराना है, लेकिन अगर किसी को यह पोस्ट मिल जाए तो।

हमारे पास एक ही आवश्यकता है: विकास में विलय करने से पहले परीक्षण के लिए उपयोग की जाने वाली विशिष्ट सुविधा का निर्माण करने के लिए एक सुविधा शाखा बनाने में सक्षम होना।

यह हम इसे कैसे किया है:

दृश्य स्टूडियो एक्सटेंशन के एक सेट निर्मित:

  • शाखा का निर्माण
  • लॉन्च शाखा का निर्माण बनाएं
  • हटाएं शाखा

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

लॉन्च शाखा निर्माण बिल्ड निर्माण परिभाषा और निर्माण लॉन्च करेगा।

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

संबंधित मुद्दे