সংস্করণ নিয়ন্ত্রণ এবং ব্যক্তিগত কনফিগারেশন ফাইল


36

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

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

তবে এটি এখনও একটি অ্যাড-হক সমাধানের মতো বলে মনে হচ্ছে।

আপনি কি আরও ভাল সমাধান প্রস্তাব করতে পারেন?

পেশাদাররা কি করবেন?



4
বগল করুন ... কেন আপনি পৃথিবীতে কেন এমনকি বিকাশকারীদের মডিউলগুলির নাম পরিবর্তন করতে এবং বৃহত্তর আপগ্রেড ব্যতীত অন্য কোনও সময়ে গ্রাহক কনফিগারেশন ভেঙে দেওয়ার অনুমতি দিচ্ছেন ?
মার্ক বুথ

: @jk হ্যাঁ, এমনকি একটি অপেক্ষাকৃত ভাল মিল stackoverflow.com/questions/1974886/...
Erel সিগাল-Halevi

আমি হতবাক আপনি যখন আপগ্রেড ইনস্টল করবেন এটি কীভাবে সমস্যা নয়।
জোশুয়া

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

উত্তর:


22

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

আমি এখানে দুটি সম্ভাব্য সমাধান সম্পর্কে ভাবতে পারি:

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

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

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


11

এটি একটি যুক্তিসঙ্গত সমাধান।

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

তারপরে যখন প্রতিটি ব্যবহারকারী তাদের ব্যক্তিগত কনফিগারেশন পরিবর্তন করে আপনি তাদের স্থানীয় অনুলিপিতে এই পরিবর্তনগুলি লিখবেন।

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

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


3

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

$db_user = "${test.db_user}";

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


2

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

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


+1 উল্লেখ করার জন্য যে এটি কেবল বিকাশকারীদের সমস্যা নয়, তবে একটি সাধারণ স্থাপনার সমস্যা।
সলেসকে

2

ব্যক্তিগত কনফিগারেশন ফাইলে একটি সংস্করণ নম্বর রাখুন (কনফিগার ফাইলের ফর্ম্যাটের সংস্করণ নম্বর)।

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

আপনি সম্ভবত শেষ ব্যবহারকারীদের জন্য এর মতো কিছু প্রক্রিয়া চাইবেন, তাই আপনার বিকাশকারীদের জীবন আরও সহজ করতে আপনি এটি ব্যবহার করতে পারেন।


1

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

মার্জটি সঠিকভাবে সম্পন্ন হয়েছে তা নিশ্চিত করার জন্য এটি যত্ন নেয় তবে এটি আমার কাছে বেশ নিরাপদ বলে মনে হয়।


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

@ সেলসেকে এর জন্য নির্দিষ্ট পরিমাণ শৃঙ্খলার দরকার পড়ে না। তবে সত্যি বলতে, আমি বেশিরভাগ বিকাশকারীদের কাছ থেকে এটি ঠিক জরিমানা করার ক্ষমতাটি আশা করব।
টমাসের মালিক

1

আমরা এখানে যা করি সেটি সেটিংসের ব্লক তৈরি করা। এটি জেন্ডে এভাবে করা যেতে পারে:

[production]
key1: parameter1
key2: parameter2

[testing: production]
key1: parameter2
key3: parameter4

এর অর্থ হল পরীক্ষার উত্পাদন উত্তরাধিকার সূত্রে প্রাপ্ত এবং কী 3 দিয়ে এটি প্রসারিত। তারপরে প্রতিটি বিকাশকারীকে তার পরিবেশ নির্ধারণ করতে হবে (এই ক্ষেত্রে পরীক্ষা বা উত্পাদন)


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

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

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

এখানে কেবল একটি চিন্তাভাবনা তবে এটি একটি ডাটাবেসে সংরক্ষণ করা ভাল না? কমপক্ষে পছন্দগুলি। এবং তারপরে আপনি তাদের ব্যবহারকারীর দম্পতি করতে পারেন। যদি তা না হয় তবে এটি কেবল একটি চিন্তা ছিল;)
আগিলিক্স

0

এটি পোস্টের উপর ভিত্তি করে একটি দরকারী সমাধান: উত্স নিয়ন্ত্রণে পাসওয়ার্ডগুলি রাখা

সংক্ষেপে কৌশলটি হ'ল "সোর্স নিয়ন্ত্রণে কনফিগারেশন ফাইলের একটি এনক্রিপ্ট করা সংস্করণ রাখা এবং তারপরে এমন একটি উপায় সরবরাহ করা যার মাধ্যমে ব্যবহারকারী সেই ডেটা এনক্রিপ্ট এবং ডিক্রিপ্ট করতে পারে।"

  1. একটি ডামি কমফিগ ফাইল তৈরি করুন এবং .gitignore।
  2. একটি মেকফাইল তৈরি করুন যা কনফিগার ফাইলটি এনক্রিপ্ট এবং ডিক্রিপ্ট করতে পারে
  3. মেকফিল এবং এনক্রিপ্ট করা কনফিগারেশন ফাইলটি সংগ্রহস্থলের মধ্যে সংরক্ষণ করুন
  4. মেকফাইলটি একটি পাসওয়ার্ড জিজ্ঞাসা করে এবং কীভাবে পাসওয়ার্ডের জন্য লেখকের সাথে যোগাযোগ করতে পারে।
  5. প্রকল্পটি তৈরি করার সময়, যদি মেকফিলটি চালিত না হয় তবে কনসোল.অররারের সাথে ব্যবহারকারীকে পরামর্শ দিন ("কনফিগার ফাইল [কনফারেন্স / সেটিংস.জসন] অনুপস্থিত! আপনি কি চালাতে ভুলে গেছেন make decrypt_conf?");
  6. কনফিগার ফাইলটি আপ টু ডেট রয়েছে তা নিশ্চিত করার জন্য একটি চেক বর্ণিত হয়েছে।

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

1
এটি যদিও একটি আকর্ষণীয় পোস্ট।
এরেল সেগাল-হালেভি

0

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

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


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

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