মঞ্চযুক্ত পরিবেশে একটি মডিউল সঠিকভাবে কীভাবে সরিয়ে নেওয়া যায়?


17

কিছু মডিউল ডিস্টোলেশন রুটিন আছে। যা সাধারণত সেই মডিউলটির জন্য ডাটাবেস টেবিলগুলি সরিয়ে দেয়, ভেরিয়েবল টেবিল থেকে ভেরিয়েবল এবং সেই মডিউলটির দ্বারা প্রবর্তিত লোকেলগুলি। এই রুটিনগুলি .installসেই মডিউলটির মধ্যে থাকে।

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

  1. আরসিএসে, একটি নতুন রিলিজ প্রস্তুত করুন, যেখানে:
    • Foo_bar- র উপরে বা ব্যবহার করে তৈরি করা সমস্ত CSS এবং থিম-ওভাররাইডগুলি সরানো হবে।
    • Foo_bar এর উপর নির্ভর করে মডিউলগুলির জন্য সমস্ত CSS এবং থিম-ওভাররাইডগুলি সরানো হবে।
  2. গ্রহণযোগ্যতা থেকে মুক্তি যে ধাক্কা। উত্পাদনের ডাটাবেসের একটি অতি সাম্প্রতিক অনুলিপি (ডিগ্রি ইনস্টলশন (অ্যাডমিন / মডিউলগুলি থেকে) পরীক্ষা করুন।
  3. যদি সবকিছু ঠিকঠাক হয় তবে নতুন কোডবেস উত্পাদনে মোতায়েন করুন এবং সেখানে foo_bar এবং এর নির্ভরতা ডিএনস্টল করুন। এটি বিভিন্ন মডিউলগুলিতে আনইনস্টল করে ডেটাবেস পরিষ্কার করবে।
  4. আরসিএসে (গিট) একটি নতুন রিলিজ প্রস্তুত করুন যেখানে কোডটি আসলে সরিয়ে ফেলা হয়েছে।
  5. এটিকে গ্রহণযোগ্যতার সাথে নিযুক্ত করুন যেখানে আমরা দুর্ঘটনাক্রমে কিছুই এর উপর নির্ভর না করে পরীক্ষা করি (কিছু কুৎসিত মডিউল বা থিম ফাংশনগুলিতে অন্যান্য মডিউল থেকে সরাসরি ফাইল অন্তর্ভুক্ত থাকে Most উল্লেখযোগ্যভাবে সিএসএস, জেএস বা চিত্র-ফাইল)।
  6. যদি গৃহীত হয় তবে উত্পাদনে নতুন প্রকাশ করুন। উত্পাদন এখন একটি পরিষ্কার ডাটাবেস এবং একটি পরিষ্কার কোডবেস আছে

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

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

এটার সাথে তুমি কিভাবে চুক্তি করলে?

[সম্পাদনা করুন: মোতায়েন করা একটি কঠিন পদ্ধতি হিসাবে প্রায়শই যোগ করা নোট]


2
আপনি যদি প্রথমে মঞ্চের সার্ভারে 1 - 6 পদক্ষেপটি করেন, তবে আপনি কি তবে লাইভ সাইটটি হেড to এ আপডেট করতে পারবেন না, আনইনস্টলগুলি করতে পারবেন, তারপরে হেডকে আপডেট করুন (সমস্ত একসাথে বসে আছেন)?
অ্যান্ডি

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

কেন সাইটটি নীচে নেওয়ার প্রয়োজন?
লেটারিয়ান

@ লেথারিয়ন: ১) সেই ডেটাবেস পরিবর্তন করার প্রক্রিয়া চলাকালীন আপনার ডাটাবেজে অযাচিত লেখাগুলি থেকে সাইটটি নামানো নিষিদ্ধ; দ্রুপাল লেনদেন ব্যবহার করে না। ২) নির্দিষ্ট ডেটাবেস স্টেটের উপর নির্ভর করে এমন নতুন কোড স্থাপন করা (একটি থিম যার জন্য একটি নির্দিষ্ট স্যাক ফিল্ড প্রয়োজন, উদাহরণস্বরূপ) কোডটি রোল আউট এবং ডাটাবেস আপডেট করার মধ্যে সময়ের মধ্যে আপনার সাইটটিকে ভেঙে ফেলবে।
বার্ক 3'12

উত্তর:


7

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

আমি আপনাকে সুপারিশ করব যে আপনার প্রক্রিয়াটি সামঞ্জস্য করার চেষ্টা করার পরিবর্তে আপনি আপনার আপডেটগুলি প্রক্রিয়া করার জন্য প্রয়োজনীয় ডাউনটাইম হ্রাস করার উপায় অনুসন্ধান করুন। আমি এই সমস্যাটি সমাধান করার জন্য একটি ইয়িং / ইয়াং মাল্টিসাইট স্টেজিং পরিবেশ স্থাপনের পরামর্শ দেব । nb আমি পূর্ববর্তী লিঙ্কে থাকা স্ক্রিপ্টগুলি ব্যবহার করি নি; আপনি স্থাপনার সময় আপনার লাইভ এবং স্টেজ সাইটগুলিকে অদলবদল করতে পারেন একই ধারণা অনুসরণ করে আপনি জিনিসগুলি আলাদাভাবে সেট আপ করতে চাইতে পারেন ।

নিম্নলিখিত প্রশ্নগুলির মধ্যে আপনার প্রশ্নটিতে বর্ণিত একই পদ্ধতি অনুসরণ করতে চালিয়ে যান:

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

খ। যখন পরীক্ষা সম্পূর্ণ এবং স্বীকৃত হয়, তখন স্টেজের (ইয়াং) কোডটি লাইভ (ইয়িং) অবস্থায় পুনরুদ্ধার করুন।

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

ঘ। আপডেট থেকে অনুমতি সারণী বাদ দিয়ে লাইভ (ইয়িং) ডাটাবেসটিকে স্টেজ (ইয়াং) ডাটাবেসে ফিরিয়ে দিন।

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

চ। আপনি এখন ইং এবং ইয়াং অদলবদলের জন্য প্রস্তুত। আপনার অ্যাপাচি কনফিগারেশন নির্দেশকে সামঞ্জস্য করে এটি করুন। মনে রাখবেন যে আপনি যদি এটি করেন তবে /etc/init.d/apache restartকিছু সংযোগ ফেলে দেওয়া যেতে পারে, তবে /etc/init.d/apache reloadএকটি পরিষ্কার অদলবদলের অনুমতি দেবে।

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

জ। লাইভ (ইয়াং) পর্যায় (ইয়ং), কোড এবং ডাটাবেস উভয়ই ফিরে - বা প্রয়োজন অনুসারে দেব থেকে চাপুন। আপনার এখন আপনার পরবর্তী পুনরাবৃত্তির জন্য একটি পরিষ্কার পরিবেশ প্রস্তুত।


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

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

আপনি মাইএসকিএল বাইনারি লগ ব্যবহার করে ট্রানজিশন সাইটে লেনদেনের উপর নজর রাখতে পারেন consider Dev.mysql.com/doc/refman/5.0/en/Point-in-time-recovery.html দেখুন । আমি কেবল জিনিসগুলিকে একসাথে একীভূত করতে নারাজ হব, তবে আপনি অতিরিক্ত কাউন্টার / ওয়াচডগ বার্তাগুলিকে বাইরে থেকে বের করে রাখতে পারেন। সেশন টেবিলটি মোকাবেলা করার সবচেয়ে সহজ উপায় হ'ল সংক্রমণের সময় লগইন অক্ষম করা।
গ্রেগ_এন্ডারসন

আপনার মন্তব্য আমাকে একটি সম্ভাব্য অন্য সমাধানে নিয়ে এসেছিল: একটি বিশেষ উদ্দেশ্যযুক্ত মডিউলের হুক_আপডেট_ন () এর মডিউলের জন্য সমস্ত হুক_উইনস্টলকে একত্রিত করুন: আনইনস্টল করুন mod এইভাবে আমি কোডটিটি প্রথম পুনরাবৃত্তিতে মুছে ফেলতে পারি / এবং / আসল রিলিজে আরও দ্রুত ডিজনস্টলেশন পেতে পারি। কোনও ড্রশ-স্ক্রিপ্ট হতে পারে যা এই তথ্যটিকে স্ক্র্যাপ করে।
বের্ক

1
আরও একটি জিনিস যা কিছুটা সাহায্য করবে। আপনার সমস্ত কাস্টম পিএইচপি কোড পরিবর্তন করুন যেমন মডিউল-থেকে-মুছে ফেলার কোনও রেফারেন্স মোড়ানো থাকে if (module_exists('removeme')) { ... }। এই কোডটি স্থাপন করুন। আপনি যদি পরীক্ষা করে নিশ্চিত করেন যে মডিউলটি সরিয়ে ফেললে আর আপনার কাস্টম কোডটি ভঙ্গ না হয়, এটি আপনার স্থাপনাকে সহজতর করবে। এটি এখনও লাইভ নয় এমন একটি সাইটে অক্ষম পদক্ষেপটি করার পরামর্শ দেওয়া হয় তবে সম্ভবত এটি আপনার উইন্ডোটি কিছুটা সংকীর্ণ করবে। আমি মনে করি না যে আপনার কাস্টম আপডেট হুক লাইভ মডিউলটিকে অক্ষম করাটিকে আরও নিরাপদ করে তুলবে।
গ্রেগ_এন্ডারসন
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.