উত্স নিয়ন্ত্রণে ফ্রেমওয়ার্ক রানটাইম সংরক্ষণ করা কি ভাল অনুশীলন?


9

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

এটি একটি ডেভ মেশিন সেটআপ সহজ করার জন্য বলা হয় (অনুমিতভাবে, সর্বশেষে আসুন এবং কোডিং শুরু করুন)। যাইহোক, এটি যথেষ্ট পরিমাণে সংগ্রহস্থলকে ফুলেছে এবং এটি অপ্রাসঙ্গিক ইতিহাসের সাথে বোঝা করে।

আমি এরকম ব্যবহারের ধরণটি কখনও দেখিনি। আপনি কি এটি একটি ভাল অনুশীলন হিসাবে বিবেচনা করেন?

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


1
আপনি একটি স্ক্রিপ্ট তৈরি করতে পারেন যা সর্বশেষ বা প্রাসঙ্গিক ফ্রেমওয়ার্ক রানটাইমগুলি ডাউনলোড করে এবং সেই স্ক্রিপ্টটি সংস্করণ নিয়ন্ত্রণে রাখে।
বেসিল স্টারিনকিভিচ

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

আমি ব্লোট সম্পর্কে সম্মত (বিশেষত যদি সেই রানটাইমগুলি একাধিক প্রকল্পের মধ্যে ভাগ করা হয়) তবে অপ্রাসঙ্গিক ইতিহাস সম্পর্কে অংশটি আমি বুঝতে পারি না। উদাহরণস্বরূপ একটি পরিবর্তন আপনি রানটাইমের যে সংস্করণটিতে ব্যবহার করছেন তা বেশ প্রাসঙ্গিক ...
6502

আপডেটগুলি প্রকাশের সাথে সাথে বিকাশকারী মেশিনের চিত্রগুলি তৈরি করা কি সহজ হবে না?
রামহাউন্ড

@ রামহাউন্ড: এটি ঠিক দিকটি আমি ধাক্কা দেওয়ার চেষ্টা করছি। আমি ভাবছিলাম যে ডাউনসাইডগুলি আমি নিখোঁজ রয়েছি কিনা?
ওফেক শিলন

উত্তর:


6

বাইনারিগুলি সাধারণত সংস্করণ নিয়ন্ত্রণ সিস্টেমের জন্য উপযুক্ত নয় কারণ:

  • সংস্করণ নিয়ন্ত্রণ বৈশিষ্ট্যগুলি থেকে তারা উপকৃত হয় না (মার্জ, ভিন্ন)
  • তারা রেপুর আকার বাড়ায় ...
  • ... যা গুরুত্বপূর্ণ কারণ আপনি একটি VCS (VCS তৈরি করা হয় থেকে একটি সংস্করণ সহজে অপসারণ না রাখা যেমন বিরোধিতা ইতিহাস) হস্তনির্মিত বস্তু ভান্ডার মত নেক্সাস , যা সহজ ভাগ ডিরেক্টরি হয় (সহজ পরিষ্কার করতে: cd+ + rm!)
  • তারা একটি হিসাবে একটি VCS উল্লেখ করা উচিত টেক্সট , একটি ঘোষণা পথ + + সংস্করণের: আপনি প্রাসঙ্গিক ইতিহাস যে ভাবে রাখতে পারবেন না , কোনো (ক pom.xml মতো টেক্সট ফাইল পরিবর্তন যেমন বাইনারি সংস্করণ পরিবর্তনের রেকর্ডিং আপনি নেক্সাস ব্যবহার করছেন কিনা তা এই ক্ষেত্রে)

1
শেষ পয়েন্টটি খুব মূল্যবান।
নওফাল ইব্রাহিম

ধন্যবাদ! আপনি কি সি ++ প্রকল্পের জন্য অনুরূপ আর্টিক্ট রেপোজিটরি সম্পর্কে জানেন? আরও ভাল - সম্ভবত এমনটি যা টিএফএসের সাথে সংহত হয়?
ওফেক শিলন

2
@ ওফেকশিলন: নেক্সাস তত্ত্ব অনুসারে যে কোনও ধরণের নিদর্শন সংরক্ষণ করতে পারে। কিন্তু। নেট / সি ++ এর জন্য সঞ্চয়স্থান এবং নির্ভরতা পরিচালনার জন্য আপনার কাছে নিউগেট : nuget.codeplex.com । । নেট: lostechies.com/derekgreer/2011/09/20/… জন্য উদাহরণ । এটির পাশাপাশি সি ++ প্রকল্পগুলি সমর্থন করা উচিত: nuget.codeplex.com/discussion/280649
ভনসি

@ ওফেকশিলন আপনি টিএফএসকে নুগেটের সাথে লিঙ্ক করতে পারেন (উদাহরণস্বরূপ: coolthingoftheday.blogspot.com/2011/08/… , haselselman.com/blog/… )। টিএফএসনুজেটারটিও দেখুন: nugetter.codeplex.com
ভোনসি

6

বাইনারি সম্পদগুলি নিয়ন্ত্রণ করে সংস্করণে আমি ঠিক আছি। আমি উত্পন্ন ফাইলগুলি নিয়ন্ত্রণ করা সংস্করণটির বিরুদ্ধে ।

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

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


3

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

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

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


2

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

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


আমি এটিকে সমাধান করার জন্য প্রশ্নটি পরিষ্কার করে দিয়েছি।
ওফেক শিলন

1

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


1

এটি করার পক্ষে যুক্তিসঙ্গত কারণ রয়েছে , কোনও বাহ্যিক নির্ভরতা ছাড়াই আপনার একক স্থানে আপনার যা প্রয়োজন তা রয়েছে ।

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

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

এটা অগ্রাধিকার বা নীতি বিষয়। যতক্ষণ সিদ্ধান্ত ইচ্ছাকৃত হয় ততক্ষণ আমি এই বিষয়ে ভাল থাকব।


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

@ ভনসি আপনার অবকাঠামো এবং কার্যকরী মিথের উপর নির্ভর করে। "একবারে কেবলমাত্র একটিমাত্র বাইনারি সঞ্চয় করুন" এর জন্য একটি ভিসিএস একটি সম্পূর্ণ আর্টিক্ট রিপোজিটরির মতো ঠিক সূক্ষ্ম হতে পারে। এটি অবকাঠামোকে সহজ রাখে। আমি উকিল করছি না - ওপি জিজ্ঞাসা করেছিল যে এই ধরণের ব্যবহারের ধরণটি কেউ দেখেছিল কিনা?

ঠিক আছে. আমি ব্যবহারের ধরণটি দেখেছি। অ্যান্ডি-কে এই জাতীয় রেপো পরিচালনা করতে হয়েছিল (এসভিএন বা ক্লিয়ার কেসের মতো ভিসি সেন্ট্রালাইজ করতে হবে, গিটের মতো ডিভিসিএসের জন্য সে ব্যবহার কখনও দেখেনি)। এবং এটি সাধারণত একটি জগাখিচুড়ি। বিক্রেতার লাইব্রেরি পুনরায় চালু করা, আপনি খুব কমই একবার কেবল একটি বাইনারি সঞ্চয় করেন store প্যাচগুলি আপনাকে মোকাবেলা করতে হবে। তাদের মধ্যে অনেক. প্লাস স্টোরেজই একমাত্র লক্ষ্য নয় (যদি তা হয়ে থাকে তবে ভিসিএস সম্ভবত যুক্তিযুক্ত সমাধান হতে পারে)। নির্ভরতা ব্যবস্থাপনা হয়। এবং এটি নেক্সাস বা নুগেট (পরিচালনা করা সহজ এবং পরিষ্কার-পরিচ্ছন্নতার পাশাপাশি) সঞ্চয়স্থান সরবরাহ করে।
ভনসি
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.