লাইভ ওয়েবসাইটের ডিপোরিয়মেন্ট বাগের সংখ্যা হ্রাস করতে আপনি কী করতে পারেন?


11

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

আপনি নতুন সংস্করণ আপলোড করার সাথে সাথে সমস্ত কিছু ভেঙে যায়। এখন, সমস্যাটি ঠিক করতে কেবল 20 মিনিট সময় লাগতে পারে তবে আপনি যে সামগ্রিক চাপ সহ্য করেন এবং সংস্থার আর্থিক এবং শুভেচ্ছার ক্ষতি কখনও কখনও তা ভুলে যায় না।

নতুন সংস্করণ স্থাপনার প্রাথমিক কনফিগারেশন থেকে উদ্ভূত এই ধরণের বাগগুলি হ্রাস করার উপায়গুলি কী কী?

পিএস: দয়া করে চেক-তালিকা উল্লেখ করবেন না, কারণ ইতিমধ্যে আমাদের সেগুলি রয়েছে them চেক-লিস্টগুলির সমস্যাটি হ'ল, সেগুলি সর্বদা আপডেট হওয়া উচিত, তবে তারা তা করবে না।


6
আপনি যখন আপডেট করবেন তখন আপনার ওয়েবসাইটটি ভঙ্গ করবেন না। আপনি যদি ... তবে আপনার পদ্ধতিটি ভুল।
রামহাউন্ড

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

5
আপনি যদি সবকিছু আবিষ্কার না করে থাকেন তবে আপনার মোতায়েন করা উচিত নয়।
এইচএলজিইএম

যদি কোনও স্থাপনা ব্যর্থ হয় তবে আপনাকে এটিকে ফিরিয়ে দিতে হবে।
তুলিনস কর্ডোভা

উত্তর:


28

দুটি জিনিস:

  • মঞ্চ পরিবেশ, লাইভ পরিবেশের সমান যেখানে আপনি পরীক্ষা মোতায়েন করেন।
  • মোতায়েনের পরে এই পরিবেশের যথেষ্ট পরীক্ষণ। স্বয়ংক্রিয় এবং অ-স্বয়ংক্রিয়

আরও কিছু কাজ করা যেতে পারে।

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


আপনার মানে পৃথিবী জুড়ে সমস্ত ওয়েবসাইটের একটি মঞ্চ পরিবেশ আছে
সাইদ নেমতি

15
ঞ্চ. এজন্য তাদের মোতায়েন নিয়ে এ জাতীয় সমস্যা রয়েছে। আমি কাজ করেছি উল্লেখযোগ্য আকারের যে কোনও সাইটের একটি রয়েছে।
ওপডে

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

6
@ সাeedদ: আমি বিশ্বের পক্ষে কথা বলতে পারি না তবে আমার সমস্ত অভিব্যক্তি নিশ্চিতভাবেই তা করে।
ওয়াইয়াট বার্নেট

1
@ সাশ্রয়ী সমস্ত ভাল কাজ।
এইচএলজিইএম

13

আমি অবাক হই, কেন কেউ সংস্করণ নিয়ন্ত্রণের কথা উল্লেখ করেনি - যা আপডেট / আপগ্রেড করার সময় সমস্যা থেকে বাঁচানোর অন্যতম গুরুত্বপূর্ণ উপায়।

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

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

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

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

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

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


3
+1 তবে আমি এটি উল্লেখ করিনি কারণ আমি কেবল ধরে নিয়েছি সংস্করণ নিয়ন্ত্রণটি বোঝা গেছে ...
ম্যাপেল_শ্যাফ্ট

3
হ্যাঁ, আশ্চর্যজনক যে কতগুলি লোক কেবল তাদের যত্ন নেওয়া কোডটি নিয়ন্ত্রণ করে এবং কনফিগারেশন, এসকিউএল ইত্যাদির মতো জিনিসগুলি নয়
এইচএলজিইএম

1
@ এইচএলজিএম, আপনি ঠিকই দুঃখের সাথে বলছেন, আমি সবকিছু নিয়ন্ত্রণ করে থাকি, এমনকি আমার কাছে আমার জীবনবৃত্তান্ত এবং রান্নার রেসিপিগুলির মতো বাড়িতে নেই এমন বিকাশের নথিগুলির জন্য ঘরে বসে একটি সাবসার্শন সার্ভার রয়েছে। :)
ম্যাপেল_শ্যাফ্ট

2
@ ম্যাপল_শ্যাফ্ট, ওহ, আমি আমার জীবনবৃত্তান্ত নিয়ন্ত্রণ করার সংস্করণ কখনই ভাবিনি, কি দুর্দান্ত ধারণা।
এইচএলজিইএম

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

6

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

এটি আরেকটি বিষয় নিয়ে আসে: পরীক্ষকগণ থাকে । আমি নিজের লেখা জিনিসগুলি পরীক্ষা করে দেখতে পাচ্ছি যতটা বাগ যখন অন্য কেউ আমার অ্যাপ্লিকেশন পরীক্ষা করে।

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


6

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

বোনাস পয়েন্টগুলির জন্য, সি যুক্ত করুন এবং আপনার সিস্টেমগুলি ভৌগোলিকভাবে পৃথক করা হয়েছে তা নিশ্চিত করুন যাতে একটি ভূমিকম্প একসাথে দু'টি বেরিয়ে না যায়।

অনেক অ্যাপ্লিকেশনগুলির জন্য, আমি স্বীকার করি যে এটি ওভারকিল।

এটি আপনার যে কোনও লেনদেন পরিচালনা করতে হবে তাও জটিল করে তোলে তবে সমস্যাগুলি অনির্বচনীয় নয়।


1
এটি সঠিক উত্তর

2
ধন্যবাদ. তবে সংস্করণ, স্টেজিং সিস্টেম এবং একটি টাচ মোতায়েন সমস্ত প্রয়োজনীয়।
বিল মিশেল

5

হ্যাঁ, আপনি পরীক্ষা বা মঞ্চায়ন পরিবেশের প্রয়োজন যেখানে আপনি সমস্ত পদক্ষেপের মধ্য দিয়ে যান, তবে পৃথক পরিবেশের জন্য পৃথক কনফিগারেশন ফাইলগুলি রাখা আবশ্যক।

Environments
|_property_files
    |_ dev
        |_ com.bla.util
        |    |_ example.properties
        |_ com.bla.beans
        |    |_ someconfig.xml
    |_ test
        ....
    |_ production
        ....
|_database_updates
    |_ dev
        |_ insert_new_static_data.sql
        |_ ...

...

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

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

ব্যাচ বা শেল স্ক্রিপ্টগুলির জন্য আমারও অনুরূপ ডিরেক্টরি রয়েছে যা একটি নির্দিষ্ট পরিবেশের জন্য চালানো দরকার।

আপনার প্রশ্নের সকলের উত্তরটি হ'ল: সেগুলি সর্বদা আপডেট হওয়া উচিত, তবে তারা তা করবে না।

এই কনফিগারেশনগুলি আপনার স্বয়ংক্রিয় বিল্ডগুলি এবং মোতায়েনগুলি চালিত করে তাই আপনি যদি সেগুলি আপডেট না করেন তবে আপনার বিল্ডগুলি ব্যর্থ হয় এবং আপনার পরিচালক এটি সম্পর্কে ইমেল করে about দলটির জন্য নির্দিষ্ট রিলিজের জন্য বিল্ড এবং স্থাপনার কনফিগারেশনগুলি বজায় রাখা ঠিক ততটাই গুরুত্বপূর্ণ কারণ তাদের সংকলনকারী কোডটিতে চেক করা তাদের পক্ষে প্রয়োজনীয়। হয় লঙ্ঘন বিল্ড বিরতি।

সংক্ষেপে, ক্রমাগত সংহতকরণ (সিআই) নীতিগুলির বৃহত্তর গ্রহণ করা উত্পাদন রিলিজগুলির ব্যথা দূর করতে সহায়তা করবে।


4

1) প্রথমে পরীক্ষার সাইটে স্থাপন করুন এবং আপনার পরিবর্তনগুলি পরীক্ষা করুন

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


এবং প্রতিটি পৃথক পরিবেশের জন্য যে কনফিগারেশন কোডটি পর্যালোচনা করেছে তা নিশ্চিত করুন।
এইচএলজিইএম

4

প্রাক-উত্পাদন পরিবেশ এবং স্বয়ংক্রিয় পরীক্ষার ব্যবহারের জন্য উপরে দুর্দান্ত পরামর্শ ছাড়াও:

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

কোডবেজ সেগমেন্ট করুন । একটি সাধারণ পদ্ধতির মধ্যে এটি আলাদা করা হয়:

  • কয়েকটি মূল অংশ যা ধীরে ধীরে পরিবর্তিত হয় এবং সাইট জুড়ে ভাগ করা হয়
  • অনেকগুলি পাতার অংশ যা আরও দ্রুত পরিবর্তিত হতে পারে তবে প্রতিটি কেবলমাত্র সাইটের একটি ছোট অংশকে প্রভাবিত করে

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


3

একটি কার্যকরভাবে মুক্তিপ্রাপ্ত হ'ল পরিকল্পনা এবং যোগাযোগ সম্পর্কে planning রিলিজ করার আগে এই প্রশ্নগুলি বিবেচনা করুন:

  1. রিলিজটি কতক্ষণ সময় নিতে পারে এবং মুক্তির কাজ চলাকালীন লোকেরা আমার পণ্যটির সাথে ইন্টারফেস চালিয়ে যেতে দেয়ায় কি কোনও ঝুঁকি রয়েছে? যদি সিস্টেমে কোনও ঝুঁকি থাকে তবে সিস্টেমটিকে অফলাইনে নিয়ে যাওয়া এবং তার জায়গায় একটি "বর্তমানে রক্ষণাবেক্ষণের ব্যবস্থায় থাকা সিস্টেম" বার্তা স্থাপনের বিষয়টি বিবেচনা করুন।

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

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

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

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

একটি অপারেশন বা রিলিজ ম্যানেজমেন্ট টিম একটি রিলিজটি সুচারুভাবে চালাতে সহায়তা করতে পারে এমন জিনিসগুলি উপরে তালিকাবদ্ধ রয়েছে। কিন্তু প্রকৌশল কোনও রিলিজের মধ্যে ঝুঁকিগুলি হ্রাস করতে সহায়তা করতে পারে?

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

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

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


1

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

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

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

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