একাধিক ক্লায়েন্টের জন্য কীভাবে একই সফ্টওয়্যারটির বিভিন্ন, কাস্টমাইজড সংস্করণ বজায় রাখা যায়

Question

আমাদের বিভিন্ন প্রয়োজন সহ একাধিক ক্লায়েন্ট রয়েছে। যদিও আমাদের সফ্টওয়্যারটি একটি ডিগ্রিতে মডিউলাইজড করা হয়েছে, এটি প্রায় নিশ্চিত যে আমাদের প্রতিটি মডিউলটির ব্যবসায়ের যুক্তি এখানে এবং প্রতিটি গ্রাহকের জন্য সামঞ্জস্য করতে হবে। প্রতিটি ক্লায়েন্টের জন্য পৃথক (শারীরিক) মডিউলে বিভাজনকে ন্যায়সঙ্গত করার পক্ষে পরিবর্তনগুলি সম্ভবত খুব সামান্য, আমি বিল্ড, একটি সংযোগকারী বিশৃঙ্খলা নিয়ে সমস্যার আশঙ্কা করি। তবুও, এই পরিবর্তনগুলি খুব বড় এবং অনেকগুলি কনফিগারেশন ফাইলের স্যুইচগুলি দ্বারা এটি কনফিগার করতে পারে না, কারণ এটি মোতায়েনের সময় সমস্যা হতে পারে এবং বিশেষত টিঙ্কার-টাইপ অ্যাডমিনগুলির সাহায্যে প্রচুর সমর্থনের সমস্যা হতে পারে।

আমি বিল্ড সিস্টেমটি একাধিক বিল্ড তৈরি করতে চাই, প্রতিটি ক্লায়েন্টের জন্য একটি, যেখানে প্রশ্নগুলির একক শারীরিক মডিউলের একটি বিশেষ সংস্করণে পরিবর্তনগুলি রয়েছে। সুতরাং আমার কিছু প্রশ্ন আছে:

আপনি কি বিল্ড সিস্টেমকে একাধিক বিল্ড তৈরি করার পরামর্শ দিবেন? বিশেষত এসএনএন উত্স নিয়ন্ত্রণে আমি বিভিন্ন কাস্টমাইজেশন কীভাবে সংরক্ষণ করব?

Comments

আপনার #ifdefজন্য কাজ করে?

— ওহহো

প্রাক প্রসেসরের নির্দেশাবলী দ্রুত খুব জটিল হয়ে উঠতে পারে এবং কোডটি পড়া আরও কঠিন এবং ডিবাগ করা আরও কঠিন।

— ফ্যালকন

ভাল উত্তরের জন্য আপনার প্রকৃত প্ল্যাটফর্ম এবং অ্যাপ্লিকেশনের ধরণ (ডেস্কটপ / ওয়েব) সম্পর্কে বিশদ অন্তর্ভুক্ত করা উচিত। ডেস্কটপ সি ++ অ্যাপ্লিকেশনটিতে কাস্টমাইজ করা পিএইচপি ওয়েব অ্যাপের চেয়ে সম্পূর্ণ আলাদা।

— গ্র্যান্ডমাস্টারবি

@ ফ্যালকন: যেহেতু আপনি ২০১১ সালে একটি উত্তর বেছে নিয়েছেন আমার সম্পর্কে প্রচুর সন্দেহ রয়েছে, আপনি কি আমাদের সাথে পরামর্শ করতে পারেন যে প্রস্তাবিত উপায়ে এসভিএন ব্যবহারের কোনও অভিজ্ঞতা পেয়েছেন? আমার আপত্তি কি প্রতিষ্ঠিত?

— ডক ব্রাউন

@ ডক ব্রাউন: শাখা করা এবং মার্জ করা ক্লান্তিকর এবং জটিল ছিল। তারপরে, আমরা ক্লায়েন্ট নির্দিষ্ট প্লাগইন বা "প্যাচগুলি" সহ একটি প্লাগইন সিস্টেম ব্যবহার করেছি যা আচরণ বা কনফিগারেশনে পরিবর্তন করে। আপনার কিছু ওভারহেড থাকবে তবে এটি Dependendy Injection দিয়ে পরিচালনা করা যায় managed

— ফ্যালকন

Answer 1

আপনার যা প্রয়োজন তা হ'ল বৈশিষ্ট্যগুলি শাখার মতো কোড সংগঠন। আপনার নির্দিষ্ট দৃশ্যে এটিকে ক্লায়েন্ট-নির্দিষ্ট ট্রাঙ্ক ব্রাঞ্চিং বলা উচিত কারণ আপনি নতুন স্টাফগুলি বিকাশ করার সময় (বা বাগগুলি সমাধান করার জন্য) সম্ভবত বৈশিষ্ট্য শাখা ব্যবহার করবেন likely

http://svnbook.red-bean.com/en/1.5/svn.branchmerge.commonpatterns.html

নতুন বৈশিষ্ট্যগুলির শাখাগুলিতে একত্রীকরণের কোড ট্রাঙ্কের ধারণা। আমি বলতে চাইছি সমস্ত অ-ক্লায়েন্ট-নির্দিষ্ট বৈশিষ্ট্য।

তারপরে আপনার ক্লায়েন্ট-নির্দিষ্ট শাখাও রয়েছে যেখানে আপনি প্রয়োজনীয় বৈশিষ্ট্যগুলির একই শাখাগুলিও মার্ভ করে (চেরি-পিকিং আপনি যদি চান)।

এই ক্লায়েন্ট শাখাগুলি বৈশিষ্ট্য শাখাগুলির অনুরূপ দেখায় যদিও এগুলি অস্থায়ী বা স্বল্প-জীবনী নয়। এগুলি দীর্ঘ সময়ের জন্য রক্ষণাবেক্ষণ করা হয় এবং এগুলি মূলত কেবলমাত্র একত্রে মিশে যায়। যতটা সম্ভব ক্লায়েন্ট-নির্দিষ্ট বৈশিষ্ট্যযুক্ত শাখার বিকাশ হওয়া উচিত।

ক্লায়েন্ট-নির্দিষ্ট শাখাগুলি ট্রাঙ্কের সমান্তরাল শাখা এবং নিজেই ট্রাঙ্ক হিসাবে সক্রিয় থাকে এবং এমনকি কোথাও পুরো একত্রিত হয় না।

            feature1
            ———————————.
                        \
trunk                    \
================================================== · · ·
      \ client1            \
       `========================================== · · ·
        \ client2            \
         `======================================== · · ·
              \ client2-specific feature   /
               `——————————————————————————´

Comments

বৈশিষ্ট্য শাখার জন্য +1। আপনি প্রতিটি ক্লায়েন্টের জন্যও একটি শাখা ব্যবহার করতে পারেন। আমি কেবল একটি বিষয় প্রস্তাব করতে চাই: এটি সম্পাদনের জন্য এসভিএন / সিভিএসের পরিবর্তে বিতরণকৃত ভিসিএস (এইচজি, গিট, বিজেআর) ব্যবহার করুন;)

— হারবার্থ অমরাল

-1। "বৈশিষ্ট্য শাখা" এর জন্য যা তা নয়; এটি তাদের সংজ্ঞাটিকে "অস্থায়ী শাখাগুলি হিসাবে মিশ্রিত করে যা কোনও বৈশিষ্ট্যের বিকাশ শেষ হলে মার্জ হয়" হিসাবে তাদের বিরোধিতা করে।

— পি শেভেড

আপনাকে এখনও সেই সমস্ত ডেল্টা উত্স নিয়ন্ত্রণে বজায় রাখতে হবে এবং এগুলি সারিবদ্ধভাবে রাখতে হবে - চিরতরে। স্বল্পমেয়াদী এটি কাজ করতে পারে। দীর্ঘমেয়াদী এটি ভয়ানক হতে পারে।

— দ্রুত_ এখন

-1, এটি নামকরণের সমস্যা নয় - বিভিন্ন ক্লায়েন্টের জন্য বিভিন্ন শাখা ব্যবহার করা কোড নকলের অন্যরকম একটি রূপ। এটি আইএমএইচও এটি একটি অ্যান্টি-প্যাটার্ন, এটি কীভাবে করবেন না তার একটি উদাহরণ।

— ডক ব্রাউন

রবার্ট, আমি মনে করি আপনি সম্পাদনার আগেও আপনি যে পরামর্শ দিয়েছেন তা আমি বেশ ভালভাবে বুঝতে পেরেছি, তবে আমি মনে করি এটি একটি ভয়ঙ্কর পদ্ধতির। ধরে নিন আপনার এন ক্লায়েন্ট রয়েছে, যখনই আপনি ট্রাঙ্কে একটি নতুন মূল বৈশিষ্ট্য যুক্ত করবেন, মনে হয় এসসিএম নতুন বৈশিষ্ট্যটিকে এন শাখায় প্রচার করা সহজ করে দেবে। তবে এইভাবে শাখা ব্যবহার করা ক্লায়েন্ট-নির্দিষ্ট পরিবর্তনগুলির স্পষ্ট বিভাজন এড়াতে খুব সহজ করে তোলে। ফলস্বরূপ, আপনার এখন ট্রাঙ্কের প্রতিটি পরিবর্তনের জন্য মার্জ সংঘাত পাওয়ার সম্ভাবনা রয়েছে। তদতিরিক্ত, আপনাকে এখন একটি পরিবর্তে এন সংহতকরণ পরীক্ষা চালাতে হবে tests

— ডক ব্রাউন

Answer 2

এসসিএম শাখা দিয়ে এটি করবেন না। সাধারণ কোডটিকে একটি পৃথক প্রকল্প তৈরি করুন যা একটি গ্রন্থাগার বা প্রকল্পের কঙ্কাল শিল্পকর্ম তৈরি করে। প্রতিটি গ্রাহক প্রকল্প একটি পৃথক প্রকল্প যা নির্ভরতা হিসাবে সাধারণের উপর নির্ভর করে।

আপনার সাধারণ বেস অ্যাপটি যদি স্প্রিংয়ের মতো নির্ভরতা ইনজেকশন কাঠামো ব্যবহার করে তবে এটি সবচেয়ে সহজ, যাতে কাস্টম বৈশিষ্ট্যগুলি প্রয়োজনীয় হিসাবে আপনি সহজেই প্রতিটি গ্রাহক প্রকল্পের বিভিন্ন প্রতিস্থাপনের বৈকল্পগুলি ইনজেক্ট করতে পারেন। আপনার যদি ইতিমধ্যে একটি ডিআই কাঠামো না থাকে তবে একটি যুক্ত করা এবং এটি এভাবে করা আপনার সর্বনিম্ন বেদনাদায়ক পছন্দ হতে পারে।

Comments

জিনিসগুলি সহজ রাখার জন্য অন্য পদ্ধতির হ'ল নির্ভরতা ইনজেকশন ব্যবহার না করে উত্তরাধিকার (এবং একটি একক প্রকল্প) ব্যবহার করে একই প্রকল্পে সাধারণ কোড এবং কাস্টমাইজেশন উভয় রেখে (উত্তরাধিকার, আংশিক শ্রেণী বা ইভেন্টগুলি ব্যবহার করে)। এই নকশাটি সহ, ক্লায়েন্ট-শাখাগুলি সূক্ষ্মভাবে কাজ করবে (নির্বাচিত উত্তরে বর্ণিত হিসাবে) এবং কেউ সর্বদা সাধারণ-কোড আপডেট করে ক্লায়েন্ট-শাখাগুলি আপডেট করতে পারে।

— ড্রিজিন

আমি যদি কিছু মিস না করি তবে আপনি যা পরামর্শ দিচ্ছেন তা হ'ল আপনার যদি 100 জন গ্রাহক থাকে তবে আপনি (100 x সংখ্যাঅফচ্যাঞ্জডপ্রজেক্টস ) তৈরি করবেন এবং সেগুলি পরিচালনা করতে ডিআই ব্যবহার করবেন? যদি এটি হয় তবে আমি সংজ্ঞায়িতভাবে এই ধরণের সমাধান থেকে দূরে থাকব কারণ রক্ষণাবেক্ষণযোগ্যতা ভয়াবহ হবে ..

— সটেন

Answer 3

একক শাখায় সমস্ত ক্লায়েন্টের জন্য সফ্টওয়্যার সঞ্চয় করুন। বিভিন্ন ক্লায়েন্টের জন্য করা পরিবর্তনগুলি ডাইভারেজ করার দরকার নেই। সর্বাধিক তীব্রভাবে, আপনি চাইবেন যে আপনার সফ্টওয়্যারটি সমস্ত ক্লায়েন্টের জন্য সর্বোত্তম মানের হয়ে উঠুক এবং আপনার মূল অবকাঠামোতে থাকা বাগফিক্সটি অপ্রয়োজনীয় মার্জিং ওভারহেড ছাড়াই প্রত্যেককে প্রভাবিত করবে, এটি আরও বেশি বাগ প্রবর্তন করতে পারে।

সাধারণ কোডটি মডুলারি করুন এবং কোডটি বিভিন্ন ফাইলে আলাদা হয় বা এটি বিভিন্ন সংজ্ঞা দিয়ে রক্ষা করে। আপনার বিল্ড সিস্টেমে প্রতিটি ক্লায়েন্টের জন্য নির্দিষ্ট লক্ষ্যবস্তু তৈরি করুন, প্রতিটি লক্ষ্য কেবল একটি ক্লায়েন্টের সাথে সম্পর্কিত কোড সহ একটি সংস্করণ সংকলন করে। আপনার কোডটি যদি সি হয়, উদাহরণস্বরূপ, আপনি #ifdefকনফিগারেশন পরিচালনার জন্য আপনার ভাষাতে যে কোনও প্রক্রিয়া আছে বা বিভিন্ন ক্লায়েন্টের জন্য বৈশিষ্ট্যগুলি রক্ষা করতে চান এবং ক্লায়েন্টের জন্য যে পরিমাণ বৈশিষ্ট্য প্রদান করা হয়েছে তার পরিমাণের সাথে সংজ্ঞাযুক্ত একটি সেট প্রস্তুত করতে পারেন।

আপনি যদি এটি পছন্দ না করেন তবে ifdef"ইন্টারফেস এবং বাস্তবায়ন", "ফান্টেক্টর", "অবজেক্ট ফাইল" বা আপনার ভাষা বিভিন্ন স্থান এক জায়গায় সংরক্ষণের জন্য যে কোনও সরঞ্জাম সরবরাহ করে use

যদি আপনি আপনার ক্লায়েন্টগুলিতে উত্স বিতরণ করেন তবে আপনার বিল্ড স্ক্রিপ্টগুলির বিশেষ "উত্স বিতরণ লক্ষ্যমাত্রা" তৈরি করা ভাল। আপনি যখন এই জাতীয় লক্ষ্যবস্তুটি শুরু করেন, এটি আপনার সফ্টওয়্যারগুলির উত্সগুলির একটি বিশেষ সংস্করণ তৈরি করে , সেগুলি একটি পৃথক ফোল্ডারে অনুলিপি করে যাতে আপনি সেগুলি চালনা করতে পারেন এবং সেগুলি সংকলন করেন না।

Answer 4

যেমনটি অনেকে বলেছেন: আপনার কোডটি যথাযথভাবে ফ্যাক্ট করুন এবং সাধারণ কোডের উপর ভিত্তি করে কাস্টমাইজ করুন - এটি রক্ষণাবেক্ষণকে উল্লেখযোগ্যভাবে উন্নতি করবে। আপনি কোনও অবজেক্ট-ভিত্তিক ভাষা / সিস্টেম ব্যবহার করছেন বা না থাকুক না কেন, এটি সম্ভব (যদিও সত্যিকারের অবজেক্ট ওরিয়েন্টেড এমন কোনও কিছু থেকে সিতে করা কিছুটা বেশি কঠিন)। এটি হ'ল সমস্যাটির ধরণ যা উত্তরাধিকার এবং এনক্যাপসুলেশন সমাধান করতে সহায়তা করে!

Answer 5

খুব সতর্কভাবে

বৈশিষ্ট্য ব্রাঞ্চিং একটি বিকল্প তবে আমি এটি কিছুটা ভারী বলে মনে করি। এছাড়াও এটি গভীর পরিবর্তনগুলি সহজ করে তোলে যা নিয়ন্ত্রণের মধ্যে না রাখলে আপনার অ্যাপ্লিকেশনটির একদম দৃ .়তা সৃষ্টি করতে পারে। আদর্শভাবে আপনি আপনার মূল কোড বেসটি যতটা সম্ভব সাধারণ এবং জেনেরিক হিসাবে রাখার চেষ্টায় কাস্টমাইজেশনগুলি যথাসম্ভব চাপ দিতে চান।

এখানে আমি কীভাবে এটি করব যদিও আমি জানি না যে এটি ভারী পরিবর্তন এবং পুনরায় ফ্যাক্টরিংগুলি ব্যতীত আপনার কোড বেসে প্রযোজ্য কিনা। আমার অনুরূপ একটি প্রকল্প ছিল যেখানে বেসিক কার্যকারিতা একই ছিল তবে প্রতিটি গ্রাহকের জন্য খুব নির্দিষ্ট বৈশিষ্ট্যগুলির একটি সেট প্রয়োজন। আমি মডিউল এবং ধারকগুলির একটি সেট তৈরি করেছি যা আমি তারপরে কনফিগারেশনের মাধ্যমে সংগ্রহ করি (I la IoC)।

তারপরে প্রতিটি গ্রাহকের জন্য আমি একটি প্রকল্প তৈরি করেছি যা মূলত তাদের সাইটের জন্য সম্পূর্ণরূপে কনফিগার করা ইনস্টলেশন তৈরির জন্য কনফিগারেশন এবং বিল্ড স্ক্রিপ্ট ধারণ করে। মাঝে মাঝে আমি এই ক্লায়েন্টটির জন্য কাস্টম তৈরি কিছু উপাদান রাখি। তবে এটি বিরল এবং যখনই সম্ভব আমি এটিকে আরও জেনেরিক আকারে তৈরি করার চেষ্টা করেছি এবং এটিকে নীচে ঠেলে দিচ্ছি যাতে অন্যান্য প্রকল্পগুলি সেগুলি ব্যবহার করতে পারে।

শেষ ফলাফলটি আমার প্রয়োজনীয় কাস্টমাইজেশনের স্তরটি পেয়েছি, আমি কাস্টমাইজড ইনস্টলেশন স্ক্রিপ্টগুলি পেয়েছি যাতে আমি গ্রাহক সাইটে পৌঁছানোর সময় আমার মনে হয় না যে আমি সমস্ত সময় সিস্টেমে টিকেট করছি এবং যুক্ত হওয়া খুব বেশি গুরুত্বপূর্ণ বোনাস হিসাবে পেয়েছি রিগ্রেশন পরীক্ষাগুলি তৈরি করতে সক্ষম হবার জন্য সরাসরি বিল্ডে আবদ্ধ। এইভাবে যে কোনও সময় আমি একটি বাগ পেয়েছি যা গ্রাহক নির্দিষ্ট, আমি একটি পরীক্ষা লিখতে পারি যা এটি স্থাপন করার সাথে সাথে সিস্টেমটিকে দৃsert়ভাবে জানায় এবং এভাবে সেই স্তরে এমনকি টিডিডিও করতে পারে।

সংক্ষেপে:

1. একটি ফ্ল্যাট প্রকল্প কাঠামো সহ ভারী মডুলারাইজড সিস্টেম।
2. প্রতিটি কনফিগারেশন প্রোফাইলের জন্য একটি প্রকল্প তৈরি করুন (গ্রাহক, যদিও একাধিক একটি প্রোফাইল ভাগ করতে পারে)
3. প্রয়োজনীয় কার্যকারিতা সেটগুলিকে আলাদা পণ্য হিসাবে জমা দিন এবং এটির মতো আচরণ করুন।

যদি সঠিকভাবে সম্পন্ন হয় তবে আপনার পণ্য সমাবেশে কয়েকটি কনফিগারেশন ফাইল বাদে সবগুলি থাকা উচিত।

কিছুক্ষণ ব্যবহার করার পরে আমি এমন মেটা-প্যাকেজ তৈরি শেষ করেছি যা বেশিরভাগ ব্যবহৃত বা প্রয়োজনীয় সিস্টেমগুলিকে একটি কোর ইউনিট হিসাবে একত্রিত করে এবং গ্রাহক সমাবেশগুলির জন্য এই মেটা-প্যাকেজটি ব্যবহার করে। কয়েক বছর পরে আমি একটি বৃহত টুলবক্স পেয়ে শেষ করেছি যা গ্রাহক সমাধান তৈরি করতে আমি খুব দ্রুত একত্রিত হতে পারি। আমি বর্তমানে স্প্রিং রুয়ের দিকে নজর দিচ্ছি এবং দেখুন যে আমি একদিন আশা করি আরও কিছুটা এগিয়ে যেতে না পারলে আমি আমাদের প্রথম সাক্ষাত্কারে গ্রাহকের সাথে সিস্টেমের প্রথম খসড়া তৈরি করতে পারি ... আমি মনে করি আপনি এটি ব্যবহারকারী চালিত বলতে পারেন বিকাশ ;-)।

আশা করি এটি সাহায্য করেছে

Answer 6

প্রতিটি ক্লায়েন্টের জন্য পৃথক (শারীরিক) মডিউলে বিভাজনকে ন্যায়সঙ্গত করার পক্ষে পরিবর্তনগুলি সম্ভবত খুব সামান্য, আমি বিল্ড, একটি সংযোগকারী বিশৃঙ্খলা নিয়ে সমস্যার আশঙ্কা করি।

আইএমও, তারা খুব ছোট হতে পারে না। যদি সম্ভব হয় তবে আমি কৌশলটির প্যাটার্নটি ব্যবহার করে ক্লায়েন্ট-নির্দিষ্ট কোডটি প্রায়শই ব্যবহার করতে পারি। এটি ব্রাঞ্চ হওয়া উচিত কোডের পরিমাণ হ্রাস করবে এবং সমস্ত ক্লায়েন্টের জন্য সাধারণ কোড সিঙ্কে রাখার জন্য প্রয়োজনীয় মার্জিং হ্রাস করবে। এটি পরীক্ষাও সহজতর করবে ... আপনি ডিফল্ট কৌশলগুলি ব্যবহার করে সাধারণ কোডটি পরীক্ষা করতে পারেন এবং ক্লায়েন্ট-নির্দিষ্ট ক্লাসগুলি পৃথকভাবে পরীক্ষা করতে পারেন test

যদি আপনার মডিউলগুলি কোড করে থাকে যে মডিউল এ পলিসি এক্স 1 ব্যবহার করে মডিউল বিতে পলিসি এক্স 2 ব্যবহার করা প্রয়োজন, রিফ্যাক্টরিংয়ের কথা চিন্তা করুন যাতে এক্স 1 এবং এক্স 2 একক নীতিনির্ভর শ্রেণিতে একত্রিত করা যায়।

Answer 7

আপনি শাখা বজায় রাখতে আপনার এসসিএম ব্যবহার করতে পারেন। ক্লায়েন্ট কাস্টম কোড থেকে মাস্টার শাখাটি আদি / পরিষ্কার রাখুন। এই শাখায় প্রধান উন্নয়ন করুন। অ্যাপ্লিকেশন প্রতিটি কাস্টমাইজড সংস্করণ জন্য পৃথক শাখা বজায় রাখা। যে কোনও ভাল এসসিএম সরঞ্জাম ব্রাঞ্চগুলি মার্জ করার সাথে সত্যিই ভাল করবে (গিট মনে আসে)। মাস্টার ব্রাঞ্চের যে কোনও আপডেটগুলি কাস্টমাইজড শাখায় মার্জ করা উচিত, তবে ক্লায়েন্ট নির্দিষ্ট কোডটি তার নিজস্ব শাখায় থাকতে পারে।

---

যদিও, যদি সম্ভব হয় তবে, মডিউল এবং কনফিগার করার পদ্ধতিতে সিস্টেমটি ডিজাইনের চেষ্টা করুন। এই কাস্টম শাখাগুলির খারাপ দিকটি এটি মূল / মাস্টার থেকে খুব দূরে সরে যেতে পারে।

Answer 8

আপনি যদি সরল সি-তে লিখছেন তবে এটি করার জন্য এটি একটি কুরুচিপূর্ণ উপায়।

• প্রচলিত কোড (যেমন ইউনিট "frangulator.c")

• ক্লায়েন্ট-নির্দিষ্ট কোড, টুকরা যা ছোট এবং কেবলমাত্র প্রতিটি ক্লায়েন্টের জন্য ব্যবহৃত।

• প্রধান ইউনিট কোডে, #ifdef এবং # অন্তর্ভুক্ত ব্যবহার করুন এর মতো কিছু করতে

#ifdef ক্লায়েন্ট = ক্লায়েন্টা
# অন্তর্ভুক্ত "ফ্রাংগুলেটর_ক্লিয়েন্ট_এ.c"
#যদি শেষ

ক্লায়েন্ট-নির্দিষ্ট কাস্টমাইজেশন প্রয়োজন এমন সমস্ত কোড ইউনিটে একে বারে বারে হিসাবে ব্যবহার করুন।

এটি অত্যন্ত কুৎসিত, এবং কিছু অন্যান্য সমস্যার দিকে পরিচালিত করে তবে এটি খুব সহজ এবং আপনি ক্লায়েন্ট-নির্দিষ্ট ফাইলগুলির একে অপরের সাথে খুব সহজেই তুলনা করতে পারেন।

এর অর্থ হ'ল ক্লায়েন্ট-নির্দিষ্ট টুকরোগুলি সমস্ত সময়ে স্পষ্টভাবে দৃশ্যমান হয় (প্রতিটি নিজস্ব ফাইলে) এবং মূল কোড ফাইল এবং ফাইলের ক্লায়েন্ট-নির্দিষ্ট অংশের মধ্যে একটি স্পষ্ট সম্পর্ক রয়েছে।

আপনি যদি সত্যই চালাক হন তবে সঠিক ক্লায়েন্টের সংজ্ঞা তৈরি করতে আপনি মেকফাইলগুলি সেট আপ করতে পারেন যাতে এরকম কিছু:

ক্লায়েন্ট তৈরি করুন

ক্লায়েন্ট_এর জন্য তৈরি করবে এবং ক্লায়েন্ট_বি ইত্যাদির জন্য "ক্লায়েন্ট বি তৈরি করুন" তৈরি করবে।

(এবং সরবরাহ না করা লক্ষ্যযুক্ত "মেক" একটি সতর্কতা বা ব্যবহারের বিবরণ জারি করতে পারে))

আমি এর আগেও অনুরূপ ধারণা ব্যবহার করেছি, সেট আপ করতে এটি কিছুটা সময় নেয় তবে এটি খুব কার্যকর হতে পারে। আমার ক্ষেত্রে একটি উত্স গাছ প্রায় 120 টি বিভিন্ন পণ্য তৈরি করেছে।

Answer 9

গিটে, আমি যেভাবে এটি করব তা হ'ল সমস্ত সাধারণ কোড সহ একটি মাস্টার শাখা এবং প্রতিটি ক্লায়েন্টের জন্য শাখা। যখনই মূল কোডে পরিবর্তন আনা হবে, কেবলমাত্র মাস্টারের শীর্ষে থাকা সমস্ত ক্লায়েন্ট-নির্দিষ্ট শাখাগুলি পুনরায় চালু করুন, যাতে আপনার ক্লায়েন্টদের জন্য চলমান প্যাচগুলির একটি সেট থাকে যা বর্তমান বেসলাইনের উপরে প্রয়োগ করা হয়।

আপনি যখনই কোনও ক্লায়েন্টের জন্য কোনও পরিবর্তন করছেন, এবং অন্য কোনও শাখায় অন্তর্ভুক্ত থাকা কোনও বাগটি লক্ষ্য করেন, তখন আপনি চেরিটি বেছে নিতে পারেন যে কোনও একটি মাস্টার বা অন্য শাখাগুলিতে যা ফিক্সের প্রয়োজন (যদিও বিভিন্ন ক্লায়েন্ট শাখাগুলির কোড ভাগ করে নেওয়া হচ্ছে , আপনার সম্ভবত তাদের উভয়কে মাস্টার থেকে একটি সাধারণ শাখা বন্ধ করা উচিত)।