গিটে, কীভাবে এক ডজন লাইব্রেরির সংস্করণ করা যায় তা সমস্ত সমান্তরালে কাজ করেছিল

Question

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

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

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

   <-------L1<--+
P1 <----+  ^    |
   <-+  |  |    |
     |  +--L2   |
     |     ^    |
     |     |    |
     +-----L3---+

এখন কল্পনা করুন যে এই প্রকল্পের জন্য কোনও বৈশিষ্ট্যটির পরিবর্তন প্রয়োজন P1এবং L3এর ইন্টারফেসটি পরিবর্তিত হয় L3। এখন প্রকল্পগুলি P2এবং P3মিক্সটিতে যুক্ত করুন, যা এই লাইব্রেরিগুলিকেও উল্লেখ করে। আমরা তাদের সকলকে নতুন ইন্টারফেসে স্যুইচ করতে, সমস্ত পরীক্ষা চালাতে এবং নতুন সফ্টওয়্যার মোতায়েনের সামর্থ রাখতে পারি না। তাহলে বিকল্প কি?

1. নতুন ইন্টারফেস বাস্তবায়ন L3
2. জন্য একটি টান অনুরোধ করুন L3এবং পর্যালোচনা জন্য অপেক্ষা করুন
3. পরিবর্তনটি মার্জ করুন
4. একটি নতুন রিলিজ তৈরি করুন L3
5. বৈশিষ্ট্যটিতে P1এটির L3নতুন প্রকাশের কথা উল্লেখ করে কাজ শুরু করুন , তারপরে P1বৈশিষ্ট্যটির শাখায় বৈশিষ্ট্যটি প্রয়োগ করুন
6. একটি টান অনুরোধ করুন, এটি পর্যালোচনা করুন, এবং মার্জ করুন

(আমি শুধু লক্ষ্য করেছি যে, আমি সুইচ করতে ভুলে গেছি L1এবং L2নতুন রিলিজ করা হয়। এবং আমি এমনকি কারণ এটি পাশাপাশি এটি করা প্রয়োজন হবে, যেখানে এই বিদ্ধ জানি না P1...)

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

তবে কীভাবে আমরা এমন একটি প্রক্রিয়া তৈরি করতে যাতে শাখা প্রশাখা এবং ট্যাগিং নিযুক্ত করি যা আমাদের অত্যধিক ওভারহেড ছাড়াই নতুন প্রকল্পগুলিতে নতুন বৈশিষ্ট্যগুলি প্রয়োগ করতে দেয়?

Comments

আপনার সরঞ্জাম পরিবর্তন করার ফলে আপনার জায়গায় থাকা প্রক্রিয়াগুলি প্রভাবিত হবে না। সুতরাং, গিটে স্যুইচ করার আগে আপনি কীভাবে এই সমস্যাটি মোকাবেলা করছেন?

— বার্ট ভ্যান ইনজেন শেেনা

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

— Ixrec

@ ইমরেক: আমাকে জানানো হয়েছিল যে কাজগুলি করার "এটি মজাদার উপায় নয়"। প্রত্যেকে পৃথক প্রকল্পের জন্য পৃথক ভাণ্ডারগুলি ব্যবহার করে, তাই সিদ্ধান্ত নেওয়া হয়েছিল যে আমরা এটিও করি।

— sbi

আমি যুক্তি দিয়ে বলব যে তারা প্রায়শই প্রায়শই পরিবর্তন করতে হবে তবে সেগুলি পৃথক প্রকল্প নয়। "প্রকল্পগুলি" এর মধ্যে সীমানার সর্বদা এক ধরণের দীর্ঘমেয়াদী পিছনের দিকে সামঞ্জস্যের গ্যারান্টি ইমো থাকা উচিত।

— Ixrec

@ ইক্সেরেক: আরও হার্ডওয়ারকে সংহত করা আরও প্ল্যাটফর্মের পোর্টিং কোডের অনুরূপ: আপনি যত বেশি এটি করেছেন, অন্য কোনও হার্ডওয়ার / প্ল্যাটফর্মের জন্য আপনার যত কম পরিবর্তন দরকার। সুতরাং দীর্ঘমেয়াদে, কোডটি স্থিতিশীল হবে। যাইহোক, এখনই আমাদের একটি প্রক্রিয়া সন্ধান করতে হবে যা আমাদের সেখানে পৌঁছানোর জন্য দীর্ঘ সময় বাজারে থাকতে দেয়।

— এসবিআই

Answer 1

এখানে সুস্পষ্ট কথা রাখার মতো, তবে এটি উল্লেখ করা ভাল।

সাধারণত, গিট রেপগুলি প্রতি লিবি / প্রকল্প অনুসারে তৈরি হয় কারণ তারা স্বতন্ত্র থাকে। আপনি আপনার প্রকল্প আপডেট করুন, এবং বাকিগুলি সম্পর্কে চিন্তা করবেন না। এটির উপর নির্ভর করে অন্যান্য প্রকল্পগুলি যখনই উপযুক্ত হবে সেগুলি কেবল তাদের lib আপডেট করবে।

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

এর শক্তিশালী সুবিধা / ত্রুটি রয়েছে।

সুবিধাদি:

• সন্ধানযোগ্যতা: শাখাটি এই বৈশিষ্ট্য / বাগের সাথে সম্পর্কিত প্রতিটি প্রকল্পে / লিবিতে পরিবর্তিত সমস্ত কিছু দেখায়।
• বান্ডিলিং: কেবল একটি ট্যাগ বাছাই করুন, এবং আপনি সমস্ত উত্স ঠিক পাবেন get

অপূর্ণতা:

• মার্জ করা: ... এটি কখনও কখনও একক প্রকল্পের সাথে ইতিমধ্যে শক্ত। ভাগ করা শাখায় বিভিন্ন দল কাজ করার সাথে, প্রভাবের জন্য কঙ্কিত করতে প্রস্তুত ready
• বিপজ্জনক "ওফস" ফ্যাক্টর: কোনও কর্মচারী যদি কিছু ভুল করে ভান্ডারটিকে গুছিয়ে ফেলেন তবে এটি সমস্ত প্রকল্প এবং দলগুলিকে প্রভাবিত করতে পারে ।

দামটি লাভের পক্ষে মূল্যযুক্ত কিনা তা আপনার জানা বিষয়।

সম্পাদনা করুন:

এটি এর মতো কাজ করবে:

• ফিচার এক্স অবশ্যই প্রয়োগ করা উচিত
• শাখা তৈরি করুন feature_x
• সমস্ত বিকাশকারী এই শাখায় কাজ করে এবং এটিতে প্যারালাইলিভাবে কাজ করে, সম্ভবত তাদের প্রকল্প / lib সম্পর্কিত ডেডিকেটেড ডিরেক্টরিতে
• এটি শেষ হয়ে গেলে, এটি পর্যালোচনা করুন, এটি পরীক্ষা করুন, এটি যা প্যাকেজ করুন, যাই হোক না কেন
• এটিকে মাস্টারের সাথে আবার মার্জ করুন ... এবং এরই মধ্যে এটি এখন হতে পারে feature_yএবং feature_zএটিও যুক্ত হয়ে থাকতে পারে। এটি "ক্রস-টিম" সংহত হয়ে যায়। এ কারণেই এটি মারাত্মক অসুবিধা।

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

Comments

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

— এসবিআই

@ এসবিআই: আপনি পুরো রেপো শাখা করবেন। আপনি বিভিন্ন শাখায় সাবট্রির সাথে কাজ করতে পারবেন না, যা আপনার ক্ষেত্রে বিন্দুটিকে পরাস্ত করবে। গিট যদিও কিছু "অনুলিপি" করবে না, এটি কেবল যে শাখায় আপনি কাজ করছেন তার পরিবর্তনগুলি কেবল তা সন্ধান করবে।

— ডাগলিনিজ

সুতরাং এর জন্য মার্জ করার সময় বা রিবেস করার সময় অন্য একজনকেও একত্র করার জন্য একটি লাইব্রেরির জন্য একটি বৈশিষ্ট্য শাখা তৈরি করা দরকার requires এটি একটি বাস্তব অপূর্ণতা। (বিটিডাব্লু, এসভিএন এছাড়াও কেবল অলস অনুলিপিগুলি করে does)

— এসবিআই

@ এসবিআই: সম্পাদনা দেখুন

— ডাগলিনিগুলি

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

— এসবিআই

Answer 2

আপনি যে সমাধানটির সন্ধান করছেন তা হ'ল গিট সাবমডিউলগুলির সাথে সমন্বয় করে নির্ভরতা পরিচালনার সরঞ্জাম

সরঞ্জামগুলি যেমন:

• ম্যাভেন
• পিপীলিকা
• সুরকার

আপনি কোনও প্রকল্পের নির্ভরতা নির্ধারণ করতে এই সরঞ্জামগুলি ব্যবহার করতে পারেন।

আপনার একটি উপ-মডেলটি কমপক্ষে সংস্করণ > ২.২.এক্স হতে হবে বা এমন সংস্করণগুলির সীমাবদ্ধতা বর্ণনা করুন যা সামঞ্জস্যপূর্ণ = ২.২। * বা কোনও নির্দিষ্ট সংস্করণের চেয়ে কম < = ২.৩

আপনি যখনই কোনও প্যাকেজটির একটি নতুন সংস্করণ প্রকাশ করেন তখনই আপনি এটি সংস্করণ নম্বর দিয়ে ট্যাগ করতে পারেন, আপনি কোডের সেই নির্দিষ্ট সংস্করণটিকে অন্য সমস্ত প্রকল্পের মধ্যে টানতে পারেন way

Comments

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

— এসবিআই

@ এসবিআই এটি নতুন সংস্করণ তৈরি এবং স্থিতিশীল প্রকল্পের রিলিজ বজায় রাখার ওভারহেড পরিচালনা করবে। যেহেতু আপনি প্রজেক্ট এক্সটি প্রকল্পের y সংস্করণ ২.১.১ এর উপর নির্ভর করতে পারেন, তাই আপনি প্রকল্পের y এর নতুন সংস্করণ তৈরি করতে পারেন যা প্রকল্পের এক্সকে প্রভাবিত করবে না।

— প্যাট্রিক

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

— এসবিআই

@ এসবিআই: তাহলে আপনার সমস্যাটি আসলে কী? আপনি আপনার পরিবর্তনগুলি করেন, সংস্করণটি টুকরো টুকরো করে নিন, নির্ভরতাগুলি যেখানে প্রয়োজন আপডেট করুন, এবং ভয়েলা। আপনি আপনার প্রাথমিক পোস্টে যা বর্ণনা করেছেন তা হ'ল সাধারন maven & co। জিনিসপত্র. প্রতিটি বিতরণ স্পষ্টভাবে সংজ্ঞায়িত সংস্করণযুক্ত libs উপর ভিত্তি করে। কিভাবে এটি আরও পরিষ্কার হতে পারে?

— ডাগলিনিজ

@ আরনাউড: তিন বা ততোধিক স্তরকে কাটানোর পরিবর্তনের জন্য (বর্তমানে বরং সাধারণ) পরিবর্তনের সময়টি আমাদের হত্যা করতে পারে। আমি ভেবেছিলাম আমার প্রশ্ন এটি বর্ণনা করেছে।

— এসবিআই

Answer 3

Submodules

একটি মন্তব্যে যেমন পরামর্শ দেওয়া হয়েছে, আপনার সাবমডিউল গিট করার চেষ্টা করা উচিত ।

প্রকল্পের যখন P1তিন submodules বোঝায় L1, L2এবং L3, এটা আসলে সব তিনটি সংগ্রহস্থলগুলিতে বিশেষ করে একটি রেফারেন্স সমূহঃ যারা কাজ প্রতিটি লাইব্রেরি সংস্করণ এই প্রকল্পের ।

তাই একাধিক প্রকল্পগুলি একাধিক সাবমোডিয়ুল সহ কাজ করতে P1পারে : L1প্রকল্পটি P2নতুন সংস্করণটি ব্যবহার করার সময় লাইব্রেরির পুরানো সংস্করণটি উল্লেখ করতে পারে ।

আপনি যখন একটি নতুন সংস্করণ সরবরাহ করবেন তখন কী হবে L3?

• নতুন ইন্টারফেস বাস্তবায়ন L3
• প্রতিশ্রুতিবদ্ধ করুন, পরীক্ষা করুন , টানুন অনুরোধ করুন, পর্যালোচনা করুন, মার্জ করুন, ... (আপনি এটি এড়াতে পারবেন না)
• L2সাথে কাজ L3, প্রতিশ্রুতিবদ্ধ, নিশ্চিত করুন ...
• L1নতুন সঙ্গে কাজ নিশ্চিত করুন L2, ...
• P1সমস্ত লাইব্রেরির নতুন সংস্করণ নিয়ে কাজ নিশ্চিত করুন :
  • ভিতরে P1'র স্থানীয় পরিশ্রমী কপি L1, L2এবং L3পরিবর্তন আপনি আগ্রহী fetche।
  • পরিবর্তনগুলি প্রতিশ্রুতিবদ্ধ করুন, git add L1 L2 L3মডিউলগুলিতে নতুন রেফারেন্স প্রতিশ্রুতিবদ্ধ
  • জন্য অনুরোধ টান P1, পরীক্ষা, পর্যালোচনা, অনুরোধ টান, একীভূত ...

প্রণালী বিজ্ঞান

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

হ্যাঁ, এর জন্য স্বতন্ত্র পর্যালোচনা প্রয়োজন , কারণ আপনি পরিবর্তন করেছেন:

• লাইব্রেরি
• এটি নির্ভর করে গ্রন্থাগারগুলি
• প্রকল্পগুলি যা একাধিক গ্রন্থাগারের উপর নির্ভর করে

আপনি বাজেয়াপ্ত বিতরণ করায় কি আপনাকে ব্যবসার বাইরে রাখা হবে? (সম্ভবত না, আসলে)। যদি হ্যাঁ হয়, তবে আপনাকে পরীক্ষা করতে হবে এবং পরিবর্তনগুলি পর্যালোচনা করতে হবে।

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

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

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

Comments

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

— এসবিআই

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

— coredump

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

— এসবিআই

Answer 4

সুতরাং আমি যা বুঝতে পেরেছি তা হ'ল আপনি এল 3 ইন্টারফেস পরিবর্তন করতে চান তবে আপনি অন্যান্য P2 এবং P3 চান যা L3 ইন্টারফেসের উপর নির্ভর করে এখনই পরিবর্তিত হতে পারে। এটি পশ্চাদপদ সামঞ্জস্যের একটি সাধারণ ক্ষেত্রে। পশ্চাদগম্য সামঞ্জস্যতা সংরক্ষণে একটি দুর্দান্ত নিবন্ধ রয়েছে

এটি সমাধান করার বিভিন্ন উপায় রয়েছে:

• আপনাকে প্রতিবার নতুন ইন্টারফেস তৈরি করতে হবে যা পুরানো ইন্টারফেসগুলি প্রসারিত করতে পারে।

অথবা

• আপনি যদি কিছু সময়ের পরে পুরানো ইন্টারফেসটি অবসর নিতে চান তবে আপনার বেশ কয়েকটি সংস্করণ ইন্টারফেস থাকতে পারে এবং একবারে সমস্ত নির্ভরশীল প্রকল্পগুলি আপনাকে পুরানো ইন্টারফেসগুলি সরিয়ে দেয়।

Comments

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

— এসবিআই

Answer 5

আমি যদি আপনার সমস্যাটি ঠিকঠাক হয়ে উঠছি:

• আপনার 4 টি আন্তঃ সম্পর্কিত মডিউল রয়েছে, পি 1 এবং এল 1 থেকে এল 3
• আপনাকে পি 1 এ পরিবর্তন করতে হবে যা শেষ পর্যন্ত এল 1 থেকে এল 3 কে প্রভাবিত করবে
• যদি আপনাকে সমস্ত 4 একসাথে পরিবর্তন করতে হয় তবে এটি প্রক্রিয়া ব্যর্থতা হিসাবে গণ্য
• যদি আপনার সমস্ত 1 টি 1 করে পরিবর্তন করতে হয় তবে এটি প্রক্রিয়া ব্যর্থতা হিসাবে গণ্য।
• এটি প্রক্রিয়া ব্যর্থতা হিসাবে গণ্য হয় যদি আপনাকে আগে থেকেই খণ্ডগুলি পরিবর্তন করতে হয় যেখানে শনাক্ত করতে হয়।

সুতরাং লক্ষ্যটি হ'ল আপনি একবারে P1 এবং L1 করতে পারেন এবং তারপরে এক মাস পরে L2 এবং L3 অন্য দিকে করতে পারেন।

জাভা বিশ্বে, এটি তুচ্ছ এবং সম্ভবত কাজ করার ডিফল্ট উপায়:

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

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

আমি সি / সি ++ বিশ্বের জন্য এই সমস্যার পূর্ব-বিদ্যমান ব্যাপকভাবে ব্যবহৃত সমাধান সম্পর্কে অবগত নই এবং আমি ভাবতে পারি যে আপনি খুব সহজেই ভাষা পরিবর্তন করতে চান। তবে সমতুল্য কাজটি করে এমন ফাইল তৈরি করে সহজেই কিছু হ্যাক করা যায়:

• এম্বেড করা সংস্করণ নম্বর সহ লাইব্রেরি + শিরোনামগুলি পরিচিত ডিরেক্টরিতে ইনস্টল করা হয়
• উপযুক্ত সংস্করণ সংখ্যার জন্য ডিরেক্টরিতে মডিউল প্রতি সংকলক পাথ পরিবর্তন

এমনকি আপনি ম্যাভেন- এ সি / সি ++ সমর্থনও ব্যবহার করতে পারেন , যদিও বেশিরভাগ সি বিকাশকারীরা আপনাকে অবাক করে দেখলে আপনি যদি তা করেন ...

Comments

"যদি আপনাকে সমস্ত 4 টি একসাথে পরিবর্তন করতে হয় তবে এটি প্রক্রিয়া ব্যর্থতা হিসাবে গণ্য" । আসলে এটা হবে না। আসলে, আমরা ঠিক এসভিএন ব্যবহার করে এটি করেছি।

— এসবিআই

এরপরে আমি অনুমান করি যে সমস্ত প্রকল্পগুলি কেবলমাত্র সংগ্রহস্থলটিতে রাখার ক্ষেত্রে কোনও সমস্যা নেই।

— soru

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

— এসবিআই

পিএস: "আমি কল্পনা করতাম আপনি খুব সহজেই ভাষা পরিবর্তন করতে চান" এটি এম্বেড করা স্টাফ। :)

— এসবিআই

Answer 6

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

সমস্ত বিকল্প সময়ের সাথে এবং প্রকল্পের বৃদ্ধির সাথে একটি ভয়াবহ জঞ্জাল তৈরি করবে।

Comments

আপনি দয়া করে বিস্তারিত বলতে পারেন? আপনি কী পরামর্শ দিচ্ছেন তা আমি নিশ্চিত নই।

— এসবিআই

স্পষ্ট-ক্ষেত্রে আপনি একটি শাখা-পয়েন্টকে বেস শাখা এবং টাইমস্ট্যাম্প হিসাবে সংজ্ঞায়িত করেন। আপনার নীচের শ্রেণিবদ্ধতা রয়েছে: বেস শাখা -> প্রকাশ-উন্নয়ন-শাখা -> বেসরকারী-উন্নয়ন শাখা। সমস্ত বিকাশ বেসরকারী শাখাগুলিতে করা হয় এবং তারপরে শ্রেণিবদ্ধের নিচে মিশে যায়। গ্রাহক রিলিজ শাখাগুলি মুক্তি-উন্নয়ন-শাখা বন্ধ হয়ে গেছে। আমি গিটের সাথে তেমন পরিচিত নই তবে ফ্রি সোর্স কন্ট্রোল সিস্টেমগুলির মধ্যে কেস সাফ করার জন্য এটি সবচেয়ে কাছের জিনিস বলে মনে হচ্ছে।

— zzz777

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

— এসবিআই

@ এসবিআই আমি দুঃখিত আমি আপনার প্রশ্নটি ভুল বুঝেছি। এবং আমি আশঙ্কা করছি যে আপনি খুব শীঘ্রই বা পরে একটি ভয়াবহ জগাখিলে পড়বেন।

— zzz777