সংস্করণ নিয়ন্ত্রণের জন্য কমপোজারলককে প্রতিশ্রুতিবদ্ধ করা উচিত?


528

composer.lockএকটি সংগ্রহস্থল সহ একটি অ্যাপ্লিকেশন ব্যবহৃত সম্পর্কে আমি কিছুটা বিভ্রান্ত

আমি অনেক লোককে দেখেছি যে আমাদের .gitignore composer.lockভান্ডার থেকে নেওয়া উচিত নয় ।

আমি যদি আমার দেব পরিবেশে আমার লাইব্রেরিগুলি আপডেট করি composer.lockতবে আমার কাছে একটি নতুন আছে তবে আমি সেগুলি প্রযোজনায় আপডেট করতে সক্ষম হব না, আমি কি করব?

এটি কি এই ফাইলটিতে বিরোধ সৃষ্টি করবে না?


1
সেই লিঙ্কটি এখন মারা গেছে @মার্কাস
কাইরে

উত্তর:


671

আপনি যদি আপনার লিবস আপডেট করেন তবে আপনি লকফিলটিও কমিট করতে চান। এটি মূলত উল্লেখ করে যে আপনার প্রকল্পটি আপনি যে ল্যাবগুলি ব্যবহার করছেন তার নির্দিষ্ট সংস্করণগুলিতে লক হয়ে আছে।

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

এটি সংগ্রহস্থলে থাকা আপনাকে আশ্বাস দেয় যে প্রতিটি বিকাশকারী একই সংস্করণ ব্যবহার করছে।


5
ঠিক আছে তবে ভাবুন যদি আমি উত্পাদন পরিবেশ থেকে লাইব্রেরিগুলি আপডেট করি তবে
কমপোজার.লকটি

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

360
উত্পাদনে আপনার নির্ভরতা আপডেট করা উচিত নয়, আপনার চালানো উচিত composer installযা লক ফাইল থেকে পড়বে এবং কোনও কিছুই পরিবর্তন করবে না।
সেলদায়েক

112
"উত্পাদনে আপনার নিজের নির্ভরতাগুলি আপডেট করা উচিত নয়" সমস্ত ক্যাপগুলিতে লেখা উচিত
জোয়াকান এল রোবেস

75
@ জোয়াকনএল.আপনি উত্পাদনে রোবলস আপনি নিজের লেনদেনগুলি আপডেট করবেন না! :)
Елин Й.

200

অ্যাপ্লিকেশন / প্রকল্পগুলির জন্য : অবশ্যই হ্যাঁ।

সুরকার ডকুমেন্টেশন এই (জোর সঙ্গে) উপর বলে:

আপনার অ্যাপ্লিকেশনটির কমপোজারলক (কম্পোজার.জসন সহ) সংস্করণ নিয়ন্ত্রণে প্রতিশ্রুতিবদ্ধ করুন।

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

গ্রন্থাগারগুলির জন্য : সম্ভবত না।

এই বিষয়ে সুরকার ডকুমেন্টেশন নোটগুলি:

দ্রষ্টব্য: গ্রন্থাগারগুলির জন্য লক ফাইলটি প্রতিশ্রুতি দেওয়ার জন্য প্রয়োজনীয়ভাবে সুপারিশ করা হয় না (...)

এবং এখানে উল্লেখ করেছে :

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

লাইব্রেরিগুলির জন্য আমি @ জোশ জনসনের উত্তরের সাথে একমত।


প্রকল্পগুলিতে কাজের কেন প্রকল্পগুলি "গ্রন্থাগারগুলি" থেকে আলাদা হয়?
জোশ জনসন

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

2
একটি লাইব্রেরির সাথে লক-ফাইল করা সম্ভবত একটি ভাল জিনিস - লক-ফাইল নথি যা পরীক্ষার স্যুটটি চালিত হওয়ার সময় নির্ভরতার সংস্করণগুলি ইনস্টল করা হয়েছিল। এটি একটি দলে এবং বিশেষত ক্রমাগত সংহত পরিবেশে গুরুত্বপূর্ণ en
mindplay.dk

ট্রাঙ্ক 2 শাখায় পুনরায় সংযুক্ত করার সময় অ-তুচ্ছ দ্বন্দ্ব দেখা দিতে পারে যে উভয়ই সুরকারের মাধ্যমে নতুন প্যাকেজ ইনস্টল করা আছে। এখনই ঘটেছে :)
g4b0

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

86

কয়েকটি প্রকল্পের জন্য উভয় উপায়ে এটি করার পরে আমার অবস্থান হল composer.lockপ্রকল্পের অংশ হিসাবে প্রতিশ্রুতিবদ্ধ হওয়া উচিত নয়।

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

আপনি যদি সুরকার আপডেটের মধ্যে আপনার নির্ভরতা পরিবর্তনের বিষয়ে উদ্বিগ্ন হন তবে আপনার সংস্করণ প্রকল্পে আপনার আত্মবিশ্বাসের ঘাটতি রয়েছে। সংস্করণ (1.0, 1.1, 1.2, ইত্যাদি) অপরিবর্তনীয় হওয়া উচিত এবং আপনার প্রাথমিক বৈশিষ্ট্য বিকাশের বাইরে "ডেভ" এবং "এক্স। *" ওয়াইল্ডকার্ডগুলি এড়ানো উচিত।

লক ফাইলটি করা আপনার নির্ভরতা পরিচালন ব্যবস্থার জন্য একটি প্রতিরোধ কারণ নির্ভরতা সংস্করণটি এখন স্পষ্টভাবে সংজ্ঞায়িত হয়ে ফিরে গেছে।

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


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

10
অনেক আত্মা অনুসন্ধানের পরে আমি সিদ্ধান্ত নিয়েছি, এই মুহুর্তে, সুরকার ডক্সগুলি ভুল :) :) আমার একটি নিয়ম আছে যে আমি ভিসিএসে উত্পন্ন উপাদান যুক্ত করব না; আমি বিল্ড প্রক্রিয়াটি পরিচালনা করার অনুমতি দিই।
জোশ জনসন

10
কোডটি কি আপনার বায়োমেকানিকাল কী-প্রেসারগুলিকে "উত্পন্ন উপাদান" ব্যবহার করে তৈরি করা হয়নি? আমি নিশ্চিত নই যে এটি কোনও নীতিকে ভিত্তি করার একটি শক্ত মানদণ্ড। =)
কুইন কমেন্ডেন্ট

5
@ খালি আমি জানি আমি কথোপকথনে কিছুটা দেরি করেছি তাই আপনি এটি এই মুহূর্তে দেখে থাকতে পারেন তবে, আপনি একটিতে একটি হ্যাশ নির্দিষ্ট করতে পারেন composer.json। ইন requireঅধ্যায়, আপনি লাগাতে পারেন: "repo": "dev-master#2633721877cae79ad461f3ca06f3f77fb4fce02e"। এটি ১) শাখায় যাবে, ২) যে হ্যাশটি চেকআউট করবে, ৩) যদি শাখায় হ্যাশ পাওয়া না যায় তবে এটি নির্দিষ্ট শাখার প্রধানকে (এই ক্ষেত্রে মাস্টার) চেকআউট করবে।
সিইপিএ

5
@ এসিপিএ - এটি অদ্ভুত। হ্যাশটি পাওয়া না গেলে আমি এটি ব্যর্থ হয়ে থাকতে আশা করতাম। বিপজ্জনক বলে মনে হচ্ছে।
নাথান জেবি

31
  1. আপনার নির্ভরতা সরাসরি উত্পাদনের উপর আপডেট করা উচিত নয়।
  2. আপনার সংস্করণটি আপনার রচয়িতাআরলক ফাইলটি নিয়ন্ত্রণ করা উচিত ।
  3. আপনার প্রকৃত নির্ভরতাগুলি ভার্সনটি নিয়ন্ত্রণ করা উচিত নয়।

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

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

যুক্তি হল যে আপনি প্রয়োজন না সম্পর্কে দেখতে হবে এক composer.lock আপনি সঠিক সংস্করণ যে আপনি আপনার প্রয়োজন সেট করতে পারেন যে composer.json ফাইল, এবং এই ভাবে, প্রত্যেক সময় কেউ রান যে composer install, এটা একই ইনস্টল করবে কোড। এটি সত্য নয়, কারণ, আপনার নির্ভরতাগুলির নিজস্ব নির্ভরতা রয়েছে এবং তাদের কনফিগারেশনটি এমন ফর্ম্যাটে নির্দিষ্ট করা যেতে পারে যা এটি সাবভারশনগুলিতে বা এমনকি পুরো সংস্করণগুলিতে আপডেটের অনুমতি দেয়।

এই উপায়ে এমনকি যখন আপনি উল্লেখ আপনি আপনার Laravel 4.1.31 চান যে composer.json , Laravel তার মধ্যে composer.json ফাইলটি তার নিজের Symfony ঘটনা-ডেস্প্যাচার প্রয়োজনীয় নির্ভরতা থাকতে পারে: 2. *। এই জাতীয় কনফিগারেশনের সাহায্যে আপনি লারভেল ৪.১.৩১ এর সাথে সিম্ফনি ইভেন্ট-প্রেরণকারী ২.৪.১ এর সাথে শেষ করতে পারেন এবং আপনার দলের অন্য কারও সাথে ইভেন্ট-প্রেরণকারী ২.6.৫ সহ লারাভেল ৪.১.৩১ থাকতে পারে, এটি সব কখন নির্ভর করে আপনি সর্বশেষে যখন সুরকার ইনস্টল চালিয়েছিলেন।

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

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

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


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

8

তারপরে composer.jsonআপনি আপনার প্রকল্পটিতে প্রতিশ্রুতিবদ্ধ এবং আপনার টিমের প্রত্যেকে আপনার প্রকল্প নির্ভরতা ইনস্টল করতে সুরকার ইনস্টল চালাতে পারেন।

লক ফাইলের পয়েন্টটি হ'ল সঠিক সংস্করণগুলি রেকর্ড করা যা ইনস্টল করা আছে যাতে সেগুলি পুনরায় ইনস্টল করা যায়। এর অর্থ হ'ল যদি আপনার সংস্করণ ১. * থাকে এবং আপনার সহকর্মী সুরকার আপডেট আপডেট করেন যা 1.2.4 ইনস্টল করে এবং তারপরে সুরকার ইনস্টল করার সময়, সুরকার ইনস্টল করার সময়, আপনিও 1.2.4 পাবেন, এমনকি যদি 1.3.0 প্রকাশ করা হয়েছে। এটি নিশ্চিত করে যে প্রকল্পে কাজ করা প্রত্যেকেরই একই সংস্করণ রয়েছে।

এর অর্থ হ'ল যদি কোনও রচয়িতা শেষবারের মতো কোনও রচয়িতা ইনস্টল করার পরে থেকে প্রতিশ্রুতিবদ্ধ হয় তবে কোনও লক ফাইল ছাড়াই আপনি নতুন তৃতীয় পক্ষের কোডটি নীচে টানতে পাবেন

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

উত্স: সুরকার: লক ফাইল সম্পর্কে এটি সমস্ত


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

সূত্র: সুরকার - বেসিক ব্যবহার


1

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

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

উত্স: সুরকার: লক ফাইল সম্পর্কে এটি সমস্ত

আরও দেখুন: সুরকার আপডেট এবং সুরকার ইনস্টল মধ্যে পার্থক্য কি?


1

এর সঠিক কোনও উত্তর নেই।

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

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

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

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

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

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

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

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

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

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

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

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

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

আপনি যৌগিক হওয়ার আশা করতে পারেন না এমন গোপন সংমিশ্রণ কমান্ড থাকার সময় এগুলি খুব স্পষ্ট হয়। ডিফল্টরূপে সুরকার অপসারণ কমান্ডটি উদাহরণস্বরূপ সুরকার আপডেট এবং সুরকারকে অপসারণ করতে মানচিত্রে উপস্থিত হয়।

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

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


0

হ্যাঁ অবশ্যই।

এটি কারণ একটি স্থানীয়ভাবে ইনস্টল করা সুরকার কমপোজার.জসন-এর চেয়ে কমপোজারলক ফাইলটিকে প্রথম পছন্দ দেবে।

লক ফাইলটি যদি ভিসিএসে না পাওয়া যায় তবে সুরকার সর্বশেষ নির্ভরতা বা সংস্করণ ইনস্টল করতে কমপোজার জেএসন ফাইলটিতে নির্দেশ করবেন।

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

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