একই প্রকল্পের একাধিক ক্লায়েন্টের জন্য ব্রাঞ্চিং মডেল পরামর্শ


11

আমাদের একটি খুব বড় প্রকল্প রয়েছে যার মধ্যে বেশ কয়েকটি অ্যাপ্লিকেশন রয়েছে যা বিভিন্ন ক্লায়েন্টের বেস হিসাবে কাজ করে।

প্রতিটি ক্লায়েন্টের নিজস্ব ব্যক্তিগতকরণ রয়েছে পণ্য, বিভিন্ন মাইলফলক, বিভিন্ন প্রয়োজনীয়তা এবং এই জাতীয়, এবং এইভাবে প্রতিটি প্রকল্প তার নিজস্ব প্রয়োজনের ভিত্তিতে স্বাধীনভাবে বিকশিত হবে।

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

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

  • প্রতিটি ক্লায়েন্টের জন্য বিভিন্ন মাইলফলক: যার অর্থ প্রতিটি দলকে স্থিতিশীলতা বা তাদের পণ্যকে প্রভাবিত করে না রেখে বাকী কমিটগুলি বাদ দিয়ে বিভিন্ন সময় হিসাবে সংস্করণ তৈরি করতে হয়।
  • বিভিন্ন প্রয়োজনীয়তা, যা কিছু ক্ষেত্রে সিস্টেমের মূলকে প্রভাবিত করতে পারে বা নাও পারে।
  • বড় দল (20+ টিমের সদস্য)
  • সিস্টেমে বাগ পরিচালনা করা: কোনও দল যদি তার প্রকল্পে কোনও বাগ খুঁজে পায় যা অন্য ক্লায়েন্টকে প্রভাবিত করতে পারে তবে আপনি কী করবেন?

দ্রষ্টব্য: আমরা এমন একটি প্রকল্পের বিষয়ে কথা বলছি যা 10 + এম এলওসি রয়েছে।

দ্রষ্টব্য: আমরা টিম ফাউন্ডেশন সিস্টেম, ভিজ্যুয়াল স্টুডিও ২০০৮ এবং সি # (প্রধানত) ব্যবহার করছি।

পরিস্থিতি মোকাবেলা করার বিষয়ে কোনও পরামর্শ, উত্স বা ধারণা? বাজারে এমন কোনও মডেল রয়েছে যা একই ধরণের সমস্যা রয়েছে?

উত্তর:


9

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

এই পদ্ধতির নামটি হল সফ্টওয়্যার প্রোডাক্ট লাইন বা কখনও কখনও প্রোডাক্ট লাইন ইঞ্জিনিয়ারিং । থেকে CMU SEI এর সফটওয়্যার পণ্যসমূহের পৃষ্ঠা :

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

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

এই সমস্ত শাখা রক্ষণাবেক্ষণের পরিবর্তে, আপনি গ্রাহক-নির্দিষ্ট কনফিগারেশনের সেট সহ একটি সিস্টেম বজায় রাখবেন।

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

কিছু অতিরিক্ত দরকারী লিঙ্ক:


11

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

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

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


2

আমি বেসের পথে যেতে পারি তবে আমি মনে করি যে আপনি আপনার সিস্টেমের মূলটি নিয়ে যা মুখোমুখি হচ্ছেন একই সমস্যাটি প্রত্যেকের মুখোমুখি হচ্ছে যারা উপাদান ব্যবহার করেন এবং তাদের সফ্টওয়্যারটির বিভিন্ন প্রকাশনা বজায় রাখতে এবং সমর্থন করা প্রয়োজন এবং এই সমস্ত প্রকাশের জন্য আলাদা আলাদা সেট প্রয়োজন require উপাদান সংস্করণ।

উদাহরণ স্বরূপ

  • রিলিজ ০.০ এর জন্য লাইব্রেরি এ 1.0 প্রয়োজন, লাইব্রেরি বি 2.0, লাইব্রেরি সি 5.6 প্রয়োজন
  • রিলিজ 2.0 এর জন্য লাইব্রেরি এ 1.0 প্রয়োজন, লাইব্রেরি বি 3.7, লাইব্রেরি সি 5.7 প্রয়োজন
  • রিলিজ 3.0 এর জন্য লাইব্রেরি এ 1.2 প্রয়োজন, গ্রন্থাগার বি 3.7, লাইব্রেরি সি 5.8 প্রয়োজন

উপাদানটির সমাধান করার উপায়টি হ'ল আমাদের সংস্করণ নিয়ন্ত্রণ সিস্টেমে লাইব্রেরির সমস্ত সংস্করণ রয়েছে (আমরা তাদের উত্সে তৈরি করি) এবং প্রতিটি প্রকল্পের তাদের অনুসন্ধানের পথটি (রেফারেন্স পাথ) পরিবর্তন করে যথাযথ গ্রন্থাগার সংস্করণ ব্যবহার করতে পারি?

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

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

যেখানে আপনার মূল সিস্টেমের জন্য নির্ভরতাগুলি উপরের উদাহরণের সাথে সাদৃশ্যযুক্ত হবে, আপনার ক্লায়েন্ট অ্যাপ্লিকেশনগুলির উপর নির্ভরতা তারপরে "" কেবলমাত্র "অতিরিক্ত রেফারেন্স রয়েছে: আপনার মূল সিস্টেমের সংস্করণ।

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

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.