বড় প্রকল্পের বিন্যাস: একাধিক উপ-প্রকল্পে নতুন বৈশিষ্ট্য যুক্ত করা


13

সংস্করণ নিয়ন্ত্রণ ব্যবস্থাপনার অনেকগুলি উপাদান সহ একটি বড় প্রকল্প কীভাবে পরিচালনা করতে হবে তা জানতে চাই।

আমার বর্তমান প্রকল্পে 4 টি বড় অংশ রয়েছে।

  1. ওয়েব
  2. সার্ভার
  3. অ্যাডমিন কনসোল
  4. প্ল্যাটফর্ম।

ওয়েব এবং সার্ভার অংশটি আমার লেখা 2 টি লাইব্রেরি ব্যবহার করে। মোট 5 টি গিট সংগ্রহস্থল এবং 1 টি পার্শ্বযুক্ত সংগ্রহস্থল রয়েছে। প্রকল্প বিল্ড স্ক্রিপ্ট প্ল্যাটফর্ম সংগ্রহস্থলে রয়েছে। এটি পুরো বিল্ডিং প্রক্রিয়াটি স্বয়ংক্রিয় করে তোলে।

সমস্যাটি হ'ল যখন আমি একটি নতুন বৈশিষ্ট্য যুক্ত করি যা একাধিক উপাদানকে প্রভাবিত করে আমাকে প্রভাবিত প্রতিটি রেপোর জন্য শাখা তৈরি করতে হবে। বৈশিষ্ট্যটি কার্যকর করুন। এটি আবার মার্জ করুন। আমার অন্ত্র অনুভূতি "কিছু ভুল"।

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


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

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

1
এটি "ব্রিজ" প্যাটার্নের সাথে সাদৃশ্যপূর্ণ বলে মনে হচ্ছে; আপনি এটি থেকে অনুপ্রেরণা নিতে পারেন।
নারফানিয়েটর

তাদের সকলকে শাসন করার জন্য একটি ভান্ডার
স্টিভেন এ লো লো

উত্তর:


8

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

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


2

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

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

যদি সমস্ত সংগ্রহস্থলগুলি একই প্রকল্পের অংশ হয় (তারা একা দাঁড়াতে পারে না) তবে সম্ভবত আপনার কেবল 1 টি সংগ্রহস্থল থাকা উচিত। (বা হতে পারে 2: মূল প্রকল্প এবং জেনেরিক / মানকৃত কার্যকারিতার জন্য একটি))

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