ধরা যাক আপনার কাছে একটি সাধারণ ওয়েব অ্যাপ রয়েছে এবং একটি ফাইল কনফিগারেশন রয়েছে w যাই হোক না কেন। প্রকল্পে কাজ করা প্রতিটি বিকাশকারীদের তাদের দেব বাক্সগুলির জন্য একটি সংস্করণ থাকবে, সেখানে একটি দেব, প্রোড এবং মঞ্চ সংস্করণ থাকবে। উত্স নিয়ন্ত্রণে আপনি কীভাবে এটি মোকাবেলা করবেন? এই ফাইলটি একেবারেই চেক করবেন না, বিভিন্ন নামের সাথে এটি পরীক্ষা করে দেখুন বা পুরোপুরি অভিনব কিছু করেন?
উত্তর:
আমি অতীতে যা করেছি তা হ'ল একটি ডিফল্ট কনফিগারেশন ফাইল যা উত্স নিয়ন্ত্রণে চেক ইন করা হয়। তারপরে, প্রতিটি বিকাশকারীর নিজস্ব ওভাররাইড কনফিগারেশন ফাইল থাকে যা উত্স নিয়ন্ত্রণ থেকে বাদ পড়ে। অ্যাপ্লিকেশনটি প্রথমে ডিফল্ট লোড করে এবং তারপরে যদি ওভাররাইড ফাইলটি উপস্থিত থাকে তবে ডিফল্ট ফাইলে অগ্রাধিকার হিসাবে ওভাররাইড থেকে যে কোনও সেটিংস লোড করে এবং ব্যবহার করে।
সাধারণভাবে, ওভাররাইড ফাইলটি যত ছোট তত ভাল, তবে এটি সর্বদা খুব অ-মানক পরিবেশ সহ বিকাশকারীর জন্য আরও সেটিংস ধারণ করতে পারে।
কনফিগারেশন হয় কোড, এবং আপনি এটা সংস্করণ উচিত। আমরা ব্যবহারকারীর নামগুলিতে আমাদের কনফিগারেশন ফাইলগুলি বেস করি; ইউনিক্স / ম্যাক এবং উইন্ডোজ উভয় ক্ষেত্রেই আপনি ব্যবহারকারীর লগইন নামটি অ্যাক্সেস করতে পারবেন এবং যতক্ষণ না এগুলি প্রকল্পের জন্য অনন্য, আপনি ভাল আছেন fine এমনকি আপনি এটি পরিবেশে এটিকে ওভাররাইড করতে পারেন, তবে আপনার সমস্ত কিছু সংস্করণে নিয়ন্ত্রণ করা উচিত ।
এটি আপনাকে অন্যের কনফিগারেশনগুলি পরীক্ষা করতেও সহায়তা করে যা বিল্ড এবং প্ল্যাটফর্ম সংক্রান্ত সমস্যাগুলি নির্ণয়ে সহায়তা করতে পারে।
ফাইলটি সংস্করণ করবেন না। একটি টেম্পলেট বা কিছু সংস্করণ করুন।
আমার দলটি প্রতিটি পরিবেশের জন্য কনফিগার ফাইলগুলির পৃথক সংস্করণ রাখে (ওয়েবকনফিগ.ডেভ, ওয়েবকনফিগ.স্টেস্ট, ওয়েবকনফিগ.প্রড)। আমাদের স্থাপনার স্ক্রিপ্টগুলি ওয়েব সংস্করণটির নাম পরিবর্তন করে সঠিক সংস্করণটি অনুলিপি করে। এইভাবে, প্রতিটি পরিবেশের জন্য কনফিগার ফাইলগুলিতে আমাদের সম্পূর্ণ সংস্করণ নিয়ন্ত্রণ রয়েছে, সহজেই একটি ভিন্নতা সম্পাদন করতে পারে ইত্যাদি etc.
টেমপ্লেট পদ্ধতির উপর +1।
তবে যেহেতু এই প্রশ্নটিতে গিট ট্যাগ রয়েছে, বিতরণ করা বিকল্প স্প্রিংসগুলি মনে রাখবেন, যাতে কাস্টমাইজেশনগুলি একটি ব্যক্তিগত পরীক্ষার শাখায় রাখা হয়:
A---B---C---D--- <- mainline (public)
\ \
B'------D'--- <- testing (private)
এই স্কিমটিতে, মূলরেখায় একটি জেনেরিক, "টেমপ্লেট" কনফিগার ফাইল রয়েছে যা কার্যকরী হওয়ার জন্য ন্যূনতম পরিমাণের সমন্বয় প্রয়োজন।
এখন, বিকাশকারী / পরীক্ষকরা তাদের হৃদয়ের সামগ্রীগুলিতে কনফিগার ফাইলটি ঝাঁকুনাতে পারেন এবং কেবলমাত্র একটি ব্যক্তিগত পরীক্ষামূলক শাখায় (যেমন বি '= বি + কাস্টমাইজেশন) এ স্থানীয়ভাবে এই প্রতিশ্রুতিবদ্ধ। প্রতিবার মাইনলাইন অগ্রসর হওয়ার সাথে সাথে তারা অনায়াসেই এটিকে পরীক্ষায় মার্জ করে, যার ফলস্বরূপ ডি '(= ডি + বি এর অনুকূলিতকরণের মার্জড সংস্করণ) এর মতো মার্জ্ট কমিট হয়।
"টেমপ্লেট" কনফিগারেশন ফাইল আপডেট হওয়ার সাথে সাথে এই স্কিমটি সত্যই জ্বলজ্বল করে: উভয় পক্ষের পরিবর্তনগুলি মার্জ হয়ে যায়, এবং যদি তারা বেমানান হয় তবে দ্বন্দ্ব (বা পরীক্ষায় ব্যর্থতা) হওয়ার সম্ভাবনা খুব বেশি!
আমরা যে সমাধানটি ব্যবহার করি তা হ'ল কেবলমাত্র একক কনফিগারেশন ফাইল (ওয়েবকনফিগ / অ্যাপকনফাইগ) থাকে তবে আমরা ফাইলটিতে একটি বিশেষ বিভাগ যুক্ত করি যা সমস্ত পরিবেশের জন্য সেটিংস ধারণ করে।
একটি স্থানীয়, ডিইভি, কিউএ, উত্পাদন রয়েছেআমাদের কনফিগার ফাইল (গুলি) এর পরিবেশের সাথে সম্পর্কিত কনফিগারেশন কীগুলির বিভাগ রয়েছে।
এই সমস্ত কাজ কী করে তা হল xxx.En পরিবেশ নামে একটি সমাবেশ assembly পরিবেশ n পরিবেশ যা আমাদের সমস্ত অ্যাপ্লিকেশনগুলিতে (উইনফর্ম এবং ওয়েবফর্মগুলি) রেফারেন্স করা হয় যা অ্যাপ্লিকেশনটিকে বলে যে এটি কোন পরিবেশে কাজ করছে।
Xxx.Environment সমাবেশ থেকে তথ্য একটি একক লাইন লেখা machine.config দেওয়া মেশিন যা বলে যে এটা দেবের QA তে, ইত্যাদি হয় এর এই এন্ট্রি আমাদের ওয়ার্কস্টেশনে এবং সার্ভার সব উপস্থিত।
আশাকরি এটা সাহায্য করবে.
আমি কনফিগার ফাইলের সমস্ত সংস্করণকে সর্বদা সোর্স নিয়ন্ত্রণে, ওয়েবকনফাইগ ফাইলের মতো একই ফোল্ডারে রেখেছি।
উদাহরণ স্বরূপ
web.config
web.qa.config
web.staging.config
web.production.config
আমি এই নামকরণ কনভেনশনটি পছন্দ করি (যেমন ওয়েবকনফিগ.প্রড্রাকশন বা প্রোডাকশন.বিউব কোডফিগের বিপরীতে) কারণ
ডিফল্ট কনফিগারেশন ফাইলটি এমনভাবে কনফিগার করা উচিত যাতে আপনি নিজের মেশিনে স্থানীয়ভাবে অ্যাপ্লিকেশনটি চালাতে পারেন।
সর্বাধিক গুরুত্বপূর্ণ, এই ফাইলগুলি প্রতিটি দিক এমনকি বিন্যাসকরণে প্রায় 100% অভিন্ন হওয়া উচিত। ইনডেন্টিংয়ের জন্য আপনার কোনও সংস্করণে ট্যাব এবং অন্যটিতে স্পেস ব্যবহার করা উচিত নয়। ফাইলগুলির মধ্যে আলাদা কি তা দেখতে আপনার বিপরীতে একটি সরঞ্জাম চালানো উচিত। আমি ফাইলগুলি পৃথক করার জন্য উইনমার্গ ব্যবহার করতে পছন্দ করি।
যখন আপনার বিল্ড প্রক্রিয়াটি বাইনারিগুলি তৈরি করে, সেখানে একটি টাস্ক থাকা উচিত যা সেই পরিবেশের জন্য উপযুক্ত কনফিগারেশন ফাইলের সাথে ওয়েবকনফিগকে ওভাররাইট করে। যদি ফাইলগুলি জিপ আপ করা হয় তবে প্রাসঙ্গিক ফাইলগুলি সেই বিল্ড থেকে মুছে ফেলা উচিত।
আমি আগে টেমপ্লেট ব্যবহার করেছি, যেমন ওয়েব.দেব.কনফিগ, ওয়েব.প্রড.কনফিগ, ইত্যাদি, তবে এখন 'ওভাররাইড ফাইল' কৌশলটি পছন্দ করি। ওয়েবকনফিগ ফাইলটিতে বেশিরভাগ সেটিংস থাকে তবে বাইরের ফাইলে পরিবেশ-নির্দিষ্ট মান যেমন ডিবি সংযোগ থাকে। পল উইলসনের ব্লগে ভাল ব্যাখ্যা ।
আমি মনে করি এটি কনফিগার ফাইলগুলির মধ্যে সদৃশ হওয়ার পরিমাণ হ্রাস করে যা নতুন মান / বৈশিষ্ট্য যুক্ত করার সময় ব্যথার কারণ হতে পারে।
আমি এটির ভার্সন নিয়ন্ত্রণ করি তবে এটি অন্য সার্ভারগুলিতে কখনই চাপ দেয় না। যদি প্রোডাকশন সার্ভারে কোনও পরিবর্তন প্রয়োজন হয় তবে আমি সেই পরিবর্তনটি সরাসরি কনফিগার ফাইলে করে দেই।
এটি সুন্দর নাও হতে পারে তবে এটি ঠিক কাজ করে।
অ্যাপ্লিকেশন / ওয়েবকনফাইগের চেক-ইন, প্লেইন-ভ্যানিলা সংস্করণটি সমস্ত বিকাশকারী মেশিনে কাজ করার জন্য যথেষ্ট জেনারেল হওয়া উচিত এবং কোনও নতুন সেটিংস পরিবর্তন ইত্যাদির সাথে আপ টু ডেট রাখতে হবে, যদি আপনার ডেভের জন্য নির্দিষ্ট সেটিংসের প্রয়োজন হয় / টেস্ট / প্রোডাকশন সেটিংস, গেটকিলার যেমনটি নামকরণ কনভেনশন দিয়ে বলেছিলেন, সেই ফাইলগুলির সাথে পৃথক ফাইলগুলি পরীক্ষা করুন, যদিও আমি সাধারণত ফাইলের এক্সটেনশানটি পরিবর্তন না করে "ওয়েব.প্রড.কনফিগ" দিয়ে যাই।
আমরা একটি টেম্পলেট কনফিগার ফাইল ব্যবহার করি যা সংস্করণ নিয়ন্ত্রণে চেক ইন করা হয় এবং তারপরে পরিবেশ-নির্দিষ্ট সেটিংস সহ টেম্পলেট ফাইলে নির্দিষ্ট এন্ট্রিগুলিকে প্রতিস্থাপন করতে আমাদের স্বয়ংক্রিয় বিল্ডের একটি পদক্ষেপ। পরিবেশ-নির্দিষ্ট সেটিংসটি পৃথক এক্সএমএল ফাইলে সংরক্ষণ করা হয় যা সংস্করণ নিয়ন্ত্রণেও রয়েছে।
আমরা আমাদের অটোমেটেড বিল্ডে এমএসবিল্ড ব্যবহার করছি, তাই মানগুলি আপডেট করার জন্য আমরা এমএসবিল্ড কমিউনিটি টাস্ক থেকে এক্সএমএলআপডেট টাস্কটি ব্যবহার করি ।
দীর্ঘদিন ধরে, বিসিউড যা করেছে ঠিক তা-ই করেছি। আমি ওয়েব.দেব.কনফিগ, ওয়েব.টেস্টকনফিগ, ওয়েব.প্রড.কনফিগ প্রভৃতি অনুলিপি উত্স নিয়ন্ত্রণে রাখি এবং তারপরে আমার বিল্ড / ডিপ্লোয় সিস্টেমটি স্বয়ংক্রিয়ভাবে তাদের নাম পরিবর্তন করে দেয় কারণ এটি বিভিন্ন পরিবেশে মোতায়েন করা হয়। আপনি ফাইলগুলির মধ্যে একটি নির্দিষ্ট পরিমাণের অতিরিক্ত কাজ করতে পারবেন (বিশেষত সেখানে থাকা সমস্ত এসপ নেটফর্মের সাথে) তবে সাধারণত এটি সত্যিই ভালভাবে কাজ করে। আপনাকে এটিও নিশ্চিত করতে হবে যে টিমের প্রত্যেকে সমস্ত আপডেট করার জন্য স্মরণ রাখে পরিবর্তন আনার সময় ফাইল রেখেছে।
যাইহোক, আমি ".config "টিকে এক্সটেনশান হিসাবে শেষে রাখতে চাই যাতে ফাইল সংযোগগুলি যাতে না ভাঙে।
কনফিগার ফাইলটির স্থানীয় বিকাশকারী সংস্করণগুলি হিসাবে, আমি সর্বদা যথাসাধ্য চেষ্টা করি যাতে লোকেরা যথাসম্ভব একই স্থানীয় সেটিংস ব্যবহার করতে উত্সাহিত করে যাতে আপনার নিজস্ব সংস্করণ থাকার দরকার নেই। এটি সর্বদা সবার জন্য কাজ করে না, এই ক্ষেত্রে লোকেরা সাধারণত প্রয়োজন অনুযায়ী স্থানীয়ভাবে এটি প্রতিস্থাপন করে এবং সেখান থেকে যান। এটি খুব বেদনাদায়ক বা কিছু নয়।
আমাদের প্রকল্পে আমরা একটি উপসর্গ সহ ফাইলগুলিতে কনফিগারেশন সঞ্চিত করি তারপরে আমাদের বিল্ড সিস্টেমটি বর্তমান সিস্টেমের হোস্টনামের ভিত্তিতে উপযুক্ত কনফিগারেশনটিতে টান দেয়। এটি তুলনামূলকভাবে ছোট দলটিতে আমাদের পক্ষে ভাল কাজ করে, যখন / যখন আমরা কোনও নতুন কনফিগারেশন আইটেম যুক্ত করি তবে আমাদের অন্য ব্যক্তির ফাইলগুলিতে কনফিগার পরিবর্তনগুলি প্রয়োগ করতে দেয়। স্পষ্টতই এটি সীমাহীন সংখ্যক বিকাশকারী সহ উত্স উত্স প্রকল্পগুলি স্কেল করতে পারে না।
আমাদের এখানে দুটি সমস্যা আছে।
প্রথমত আমাদের কনফিগারেশন ফাইলটি নিয়ন্ত্রণ করতে হবে যা সফ্টওয়্যার দিয়ে প্রেরণ করা হয়।
কোনও বিকাশকারী মাস্টার কনফিগারেশন ফাইলে পরিবর্তন করতে অযাচিত পরীক্ষা করতে পারেন, যদি তারা একই ফাইলটি বিবর্তন পরিবেশে ব্যবহার করে তবে এটি দুটিই সহজ।
অন্যদিকে, আপনার যদি ইনস্টলারের দ্বারা অন্তর্ভুক্ত করা একটি পৃথক কনফিগারেশন ফাইল থাকে তবে এটিতে একটি নতুন সেটিংস যুক্ত করতে ভুলে যাওয়া বা এতে থাকা মন্তব্যগুলিকে বিবর্তনের মন্তব্যের সাথে সিঙ্ক থেকে বেরিয়ে আসতে দেওয়া খুব সহজ is ফাইল কনফিগার করা হচ্ছে।
তারপরে আমাদের সমস্যাটি রয়েছে যে অন্যান্য বিকাশকারীরা নতুন কনফিগারেশন সেটিংস যুক্ত করার কারণে বিকাশকারীদের সেখানে কনফিগারেশন ফাইলটির অনুলিপি রাখতে হবে। তবে ডাটাবেস সংযোগের স্ট্রিংয়ের মতো কিছু সেটিংস প্রতিটি বিকাশকারীদের জন্য আলাদা।
প্রশ্ন / উত্তরগুলি কভার করে না এমন একটি তৃতীয় সমস্যা রয়েছে। আপনি যখন আপনার সফ্টওয়্যারটির একটি নতুন সংস্করণ ইনস্টল করেন তখন কোনও গ্রাহক আপনার কনফিগারেশন ফাইলটিতে পরিবর্তনগুলি কীভাবে মার্জ করবেন?
আমি এখনও একটি ভাল সমাধান দেখতে পেলাম যা সব ক্ষেত্রে ভালভাবে কাজ করে তবে আমি কিছু আংশিক সমাধান দেখেছি (যা প্রয়োজন অনুসারে বিভিন্ন সংমিশ্রণে একত্রিত করা যেতে পারে) যা সমস্যাটি অনেকটা হ্রাস করে।
প্রথমে আপনার মূল কনফিগারেশন ফাইলে আপনার থাকা কনফিগারেশন আইটেমগুলির সংখ্যা হ্রাস করুন।
আপনার গ্রাহকদের আপনার ম্যাপিং পরিবর্তন করতে দেওয়ার প্রয়োজন না থাকলে কনফিগারেশনটিকে কোডে সরিয়ে নিতে ফ্লুয়েট এনএইচবারনেট (বা অন্যথায়) ব্যবহার করুন।
অনুরূপভাবে ইনপেকশন ইনজেকশন সেটআপের জন্য।
সম্ভব হলে কনফিগারেশন ফাইলটি বিভক্ত করুন, যেমন লগ 4 নেট লগ করে তা কনফিগার করতে একটি পৃথক ফাইল ব্যবহার করুন।
প্রচুর কনফিগারেশন ফাইলের মধ্যে আইটেমগুলি পুনরাবৃত্তি করবেন না, উদাহরণস্বরূপ যদি আপনার কাছে 4 টি ওয়েব অ্যাপ্লিকেশন থাকে যা সমস্ত একই মেশিনে ইনস্টল করা থাকে তবে একটি সামগ্রিক কনফিগারেশন ফাইল রয়েছে যা প্রতিটি অ্যাপ্লিকেশনে ওয়েবকনফিগ ফাইলটি নির্দেশ করে।
(ডিফল্টরূপে আপেক্ষিক পথ ব্যবহার করুন, সুতরাং ওয়েবকনফিগ ফাইলটি পরিবর্তন করা বিরল)
শিপিং কনফিগারেশন ফাইলটি পেতে বিকাশ কনফিগারেশন ফাইলটি প্রক্রিয়া করুন।
এক্সএমএল মন্তব্যে ডিফল্ট মান থাকতে পারে যা একটি বিল্ডিং হয়ে গেলে কনফিগারেশন ফাইলে সেট হয়। অথবা ইনস্টলার তৈরি করার প্রক্রিয়ার অংশ হিসাবে মুছে ফেলা বিভাগগুলি থাকা।
কেবলমাত্র একটি ডাটাবেস সংযোগ স্ট্রিংয়ের পরিবর্তে, প্রতি বিকাশকারীদের জন্য একটি করুন।
উদাহরণস্বরূপ, রান টাইমে কনফিগারেশন ফাইলটিতে প্রথম "ডাটাবেস_আয়ানার" (যেখানে আইয়ানারটি আমার ব্যবহারকারী নাম বা মেশিনের নাম) সন্ধান করুন, যদি এটি পাওয়া না যায়, তবে "ডাটাবেস" সন্ধান করুন
ডেভেলপারদের উভয় ডাটাবেস সিস্টেমে যেতে তাত্পর্যপূর্ণ করার জন্য একটি ২ য় স্তরের "যেমন-ওরাকল বা -সক্লসার্ভার" রয়েছে।
এটি অবশ্যই অন্য কোনও কনফিগারেশন মানের জন্যও করা যেতে পারে।
তারপরে কনফিগারেশন ফাইলটি শিপিংয়ের আগে "_userName" এ থাকা সমস্ত মানগুলি ছড়িয়ে দেওয়া যেতে পারে।
তবে শেষ পর্যন্ত আপনি একটি "কনফিগারেশন ফাইলের মালিক" যা কনফিগারেশন ফাইল (গুলি) উপরের হিসাবে বা অন্যভাবে পরিচালনা করার জন্য দায়বদ্ধভাবে গ্রহণ করে। প্রতিটি চালানের আগে গ্রাহক ফেসিং কনফিগারেশন ফাইলের ক্ষেত্রেও তার আলাদা করা উচিত।
এই সমস্যাজনিত কিছু না হওয়াতে যত্নবান ব্যক্তির প্রয়োজনীয়তা আপনি সরাতে পারবেন না।
আমি মনে করি না যে একক সমাধান রয়েছে যা সমস্ত ক্ষেত্রেই কাজ করে কারণ এটি কনফিগার ফাইলগুলিতে ডেটা সংবেদনশীলতা বা আপনি যে প্রোগ্রামিং ল্যাঙ্গুয়েজ ব্যবহার করছেন তার উপর নির্ভর করে এবং অন্যান্য অনেকগুলি বিষয়। তবে আমি মনে করি যে সমস্ত পরিবেশের জন্য কনফিগার ফাইলগুলিকে উত্স নিয়ন্ত্রণে রাখা গুরুত্বপূর্ণ, তাই আপনি সর্বদা জানতে পারবেন কখন এটি পরিবর্তন করা হয়েছিল এবং কাদের দ্বারা এবং আরও গুরুত্বপূর্ণভাবে বিষয়গুলি ভুল হলে এটি পুনরুদ্ধার করতে সক্ষম হবেন। এবং তারা করবে।
সুতরাং আমি এখানে এটি কিভাবে। এটি সাধারণত নোডেজ প্রকল্পগুলির জন্য তবে আমি মনে করি এটি অন্যান্য ফ্রেমওয়ার্ক এবং ভাষার জন্যও কাজ করে।
আমি যা করি তা হ'ল configsপ্রকল্পের মূলে একটি ডিরেক্টরি তৈরি করা এবং সেই ডিরেক্টরিটির অধীনে সমস্ত পরিবেশের জন্য একাধিক ফাইল রাখা (এবং প্রতিটি বিকাশকারীর পরিবেশের জন্য কিছু সময় পৃথক পৃথক ফাইলও) যা সমস্ত উত্স নিয়ন্ত্রণে ট্র্যাক করা। এবং প্রকৃত ফাইল রয়েছে যা কোডটি configপ্রকল্পের মূলের নামে নাম ব্যবহার করে। এটিই কেবলমাত্র ফাইল যা ট্র্যাক হয় না। সুতরাং এটির মতো দেখাচ্ছে
root
|
|- config (not tracked)
|
|- configs/ (all tracked)
|- development
|- staging
|- live
|- James
যখন কেউ এই প্রকল্পটি পরীক্ষা করে দেখেন configতিনি অননুযুক্ত ফাইলটিতে ব্যবহার করতে চান এমন কনফিগারেশন ফাইলটি অনুলিপি করেন এবং তিনি নিজের ইচ্ছামত সম্পাদনা করতে পারেন তবে প্রয়োজনে অন্যান্য পরিবেশের ফাইলগুলিতে প্রতিশ্রুত হওয়ার আগে এই পরিবর্তনগুলি অনুলিপি করার জন্যও দায়বদ্ধ।
এবং সার্ভারগুলিতে, তালিকাভুক্ত ফাইলটি সেই পরিবেশের সাথে সম্পর্কিত ট্র্যাক ফাইলটির অনুলিপি (বা রেফারেন্স) হতে পারে। জেএসে আপনার কেবল সেই ফাইলটির জন্য 1 লাইন থাকতে পারে।
এই প্রবাহটি প্রথমে কিছুটা জটিল হতে পারে তবে এর দুর্দান্ত সুবিধাগুলি রয়েছে: ১. কোনও ব্যাকআপ না রেখে কোনও কনফিগার ফাইল সার্ভারে মুছে ফেলা বা সংশোধিত হওয়া নিয়ে আপনাকে কখনই চিন্তা করতে হবে না a মেশিন এবং তার মেশিনটি কোনও কারণে কাজ বন্ধ করে দেয় 3.. কোনও স্থাপনার আগে আপনি কনফিগার ফাইলগুলিতে developmentএবং stagingউদাহরণস্বরূপ পৃথক করতে পারেন এবং দেখুন কিছু অনুপস্থিত বা ভাঙ্গা আছে কিনা তা দেখুন।
আমি একই সমস্যার মুখোমুখি হয়েছি এবং এর সমাধানও পেয়েছি। আমি প্রথমে সমস্ত ফাইলগুলি কেন্দ্রীয় ভাণ্ডারে (বিকাশকারীদেরও) যুক্ত করেছিলাম।
সুতরাং যদি কোনও বিকাশকারী সংগ্রহস্থল থেকে ফাইলগুলি আনেন তবে বিকাশকারী কনফিগারেশনটিও সেখানে থাকে। এই ফাইলটিতে তৈরি করার সময়, গিটকে এই পরিবর্তনগুলি সম্পর্কে সচেতন করা উচিত নয়। এইভাবে পরিবর্তনগুলি সংগ্রহস্থলটিতে ধাক্কা / প্রতিশ্রুতিবদ্ধ করা যায় না তবে স্থানীয়ভাবে থাকে stay
আমি Git কমান্ড ব্যবহার করে এই মীমাংসিত: update-index --assume-unchanged। আমি এমন একটি ব্যাট ফাইল তৈরি করেছি যা প্রজেক্টগুলির প্রি-বিল্ডে কার্যকর করা হয় যেগুলিতে এমন একটি ফাইল রয়েছে যার পরিবর্তনগুলি গিট দ্বারা উপেক্ষা করা উচিত। আমি ব্যাট ফাইলে রেখেছি কোডটি এখানে:
IF NOT EXIST %2%\.git GOTO NOGIT
set fileName=%1
set fileName=%fileName:\=/%
for /f "useback tokens=*" %%a in ('%fileName%') do set fileName=%%~a
set "gitUpdate=git update-index --assume-unchanged"
set parameter= "%gitUpdate% %fileName%"
echo %parameter% as parameter for git
"C:\Program Files (x86)\Git\bin\sh.exe" --login -i -c %parameter%
echo Make FIleBehaveLikeUnchangedForGit Done.
GOTO END
:NOGIT
echo no git here.
echo %2%
:END
আমার প্রাক বিল্ডে আমি ব্যাট ফাইলে কল করব, উদাহরণস্বরূপ:
call "$(ProjectDir)\..\..\MakeFileBehaveLikeUnchangedForGit.bat" "$(ProjectDir)Web.config.developer" "$(SolutionDir)"
আমি SO তে একটি ব্যাট ফাইল পেয়েছি যা সঠিক কনফিগারেশন ফাইলটি ওয়েব.config / app.config এ অনুলিপি করে। আমি এই ব্যাট ফাইলটিকে প্রি-বিল্ডেও কল করি। এই ব্যাট ফাইলের কোডটি হ'ল:
@echo off
echo Comparing two files: %1 with %2
if not exist %1 goto File1NotFound
if not exist %2 goto File2NotFound
fc %1 %2
if %ERRORLEVEL%==0 GOTO NoCopy
echo Files are not the same. Copying %1 over %2
copy %1 %2 /y & goto END
:NoCopy
echo Files are the same. Did nothing
goto END
:File1NotFound
echo %1 not found.
goto END
:File2NotFound
copy %1 %2 /y
goto END
:END
echo Done.
আমার প্রাক বিল্ডে আমি ব্যাট ফাইলে কল করব, উদাহরণস্বরূপ:
call "$(ProjectDir)\..\..\copyifnewer.bat" "$(ProjectDir)web.config.$(ConfigurationName)" "$(ProjectDir)web.config