এমন পণ্যগুলির জন্য একটি শালীন গিট ব্রাঞ্চিং মডেল যা অন্য, তৃতীয় পক্ষের পণ্যগুলির সংস্করণ (এবং একটি প্রস্তাবের পক্ষে এবং কুফল) এর সাথে থাকতে হবে


13

দ্রষ্টব্য: আমার প্রশ্নটি আমার নির্দিষ্ট সমস্যাটিতে জড়িত (যার মধ্যে লাইফ্রে জড়িত) তবে আমি আশা করি যে এটির জন্য একই প্রকল্পের বিভিন্ন সংস্করণ বজায় রাখতে হবে এমন ব্যক্তির পক্ষে এটি কার্যকর হতে পারে।

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

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

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

এখন, আমরা গিটারিয়াসে মাইগ্রেশন করছি । আমরা এই জাতীয় দৃশ্যের জন্য একটি ব্রাঞ্চিং মডেল কল্পনা করার চেষ্টা করছি।

আমার মডেল

আমি প্রস্তাবিতটি হ'ল:

  1. প্রতিটি প্লাগইনের একটি প্রকল্পের অভ্যন্তরে গিটারিয়াসে নিজস্ব সংগ্রহস্থল থাকবে। উদাহরণস্বরূপ, বিড়ালছানাগুলি প্রদর্শনের জন্য একটি পোর্টলেটটির প্রকল্পের kittens-portletভিতরে একটি সংগ্রহস্থল থাকবে liferay-portlets
  2. একটি নতুন প্লাগইন তৈরি করার সময়, লাইফ্রে সংস্করণ অনুসারে এটি একটি শাখায় তৈরি করুন (উদাহরণস্বরূপ lf5.2)।
  3. প্রতিবার প্লাগইনে একটি আপডেট করা হলে আপডেটটি অনুমোদিত হয় এবং উত্পাদনে মোতায়েন হয়, প্লাগইনটিকে একটি সংস্করণ (উদাহরণস্বরূপ lf5.2v1, lf5.2v2ইত্যাদি) দিয়ে ট্যাগ করুন *
  4. প্রতিবার যখন প্লাগইনটি লাইফ্রেয়ের একটি নতুন সংস্করণে পোর্ট করা উচিত তখন আমরা অতি সাম্প্রতিক সংস্করণটি শাখা করি (উদাহরণস্বরূপ, শাখা তৈরি করে lf6.0)।
  5. উত্পাদনের পরে, নতুন শাখার প্রধান যেমন একটি ট্যাগ পাবেন lf6.0v1
  6. প্রতিবার যখনই আমাদের ক্লায়েন্ট-নির্দিষ্ট উপায়ে প্লাগইনটি কাস্টমাইজ করতে হয় তখন আমরা ক্লায়েন্টের নাম সহ একটি শাখা তৈরি করি (উদাহরণস্বরূপ, আমরা lf5.2clientcorpআমাদের ক্লায়েন্ট "ক্লায়েন্টকর্প ইনক।" এর জন্য একটি শাখা তৈরি করব )

এটি একটি অস্বাভাবিক মডেল: এটির কোনও masterএবং মার্জ না হওয়া প্রচুর শাখা থাকবে। আমি মনে করি যে এই জাতীয় মডেল সহ একটি সংগ্রহস্থলটি দেখতে পাবেন:

আমি মনে করি আমার শাখাগুলি কীভাবে কাজ করবে।

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

আমার বন্ধুর মডেল

তারপরে তিনি আরেকটি মডেল প্রস্তাব করলেন: আমাদের লাইফ্রে সংস্করণে প্রতিটি প্লাগইনের জন্য একটি সংগ্রহস্থল থাকবে (যাতে আমরা একটি kittens-lf5.2-portletএবং তারপরে একটি তৈরি করতে শুরু করব kittens-lf6.0-portlet), যার প্রতিটি masterশাখা এবং একটি developশাখা থাকবে। masterসবসময় স্থাপনার জন্য প্রস্তুত হতে হবে। (বা এটি অন্য উপায়ে হতে পারে, masterএবং stableযেমন স্টিভ লশ প্রস্তাব করেছিলেন )।

এটি খুব সহজ, তবে আমি এই সিস্টেমটি পছন্দ করি নি:

  1. এটি কোনও প্রকল্পে ভয়াবহ প্রচুর পরিমাণে সংগ্রহের ফলস্বরূপ হতে পারে, যা ব্রাউজ করা শক্ত করে তোলে।
  2. প্রকল্পের ডিরেক্টরিটির নাম প্রাসঙ্গিক। যদি কেউ একটি kittens-lf6.0-portletডিয়ারের কাছে ভান্ডারটি ক্লোন করে এবং পিপড়া দিয়ে (ওয়ার্ম হিসাবে) দিয়ে ওয়ার তৈরি করে তবে ওয়ার নামটিও হবে kittens-lf6.0-portlet। এই kittens-portletপোর্টলেটটির পুরানো সংস্করণগুলি ( উদাহরণস্বরূপ নাম দেওয়া হয়েছে) একটি আপগ্রেড পোর্টালে আলাদা (এবং সম্ভবত অনুপস্থিত) পোর্টলেট হিসাবে বিবেচিত হবে। কিছুটা যত্ন এড়াতে পারে তবে আমি এড়াতে পছন্দ করব।
  3. একই প্লাগইনের বিভিন্ন সংস্করণ পৃথক রক্ষণাবেক্ষণ করা হবে। আমি আমার হৃদয় ভেঙ্গে :(
  4. kittens-lf6.0-portlet ভাণ্ডারগুলির জন্য এটি একটি কুৎসিত নাম, আমি মনে করি।

আমি শেষ দুটি পয়েন্টগুলি সন্দেহ করি - যা দুটি আরও বিষয়গত বিষয়ও - আমার অনাগ্রহের মূল কারণ। যাইহোক, চারটি আপত্তি দাঁড়িয়ে।

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

সুতরাং, আমি জিজ্ঞাসা:

  1. সেরা মডেলটি কী হবে? আমার প্রস্তাব? আমার বন্ধুর মডেল? এখনকার traditionalতিহ্যবাহী ভিনসেন্ট ড্রাইসেন সিস্টেম?
  2. আপনি অন্য ব্রাঞ্চিং মডেল কি পরামর্শ করবেন?
  3. আপনি যদি আমার মডেলটিকে খারাপ বলে মনে করেন তবে আপনি কেন এমন ভাবেন? আমি বুঝতে পারি যে ত্রুটিগুলি এবং অন্ধ দাগগুলি কী।

* প্রকৃতপক্ষে, আমি একটি সংস্করণ যেমন কমিট ট্যাগ করতে পছন্দ করি v1তবে স্পষ্টতই গিটে একটি ট্যাগ শাখায় বাদ দেওয়া হয় না - অর্থাৎ, আমার একটিতে 1 টি v1ট্যাগ lf5.2এবং অন্য একটিতে lf6.0থাকতে পারে না - সুতরাং আমার নামটির নাম রাখতে হবে শাখা। এটি কি সঠিক বিটিডাব্লু?


আপনার মডেলটিতে, আপনাকে একাধিক শাখায় একই বৈশিষ্ট্য বা বাগ ফিক্স যুক্ত করতে কতবার প্রয়োজন?
কার্ল বিলেফেল্ট 14

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

উত্তর:


2

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

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

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

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


3

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

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

তবে এটি আমার আমার 0.02 ডলার।

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