যদি কোনও বৈশিষ্ট্য বিকাশে মিশে যায় তবে ব্যবস্থাপনার দ্বারা স্থগিত করা হয়?


53

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

সমস্যাটি হ'ল এই কার্যকারিতাটি অন্য সমস্ত বৈশিষ্ট্যগুলির সাথে শেষ হয়ে গেলে বিকাশের সাথে একত্রীকরণ করা হয়েছিল যা আমরা পরের রিলিজটিতে লাইভ ধাক্কা দেওয়ার প্রত্যাশা করি যাতে আমরা সাধারণত আমাদের মতো দেব -> পরীক্ষা -> মাস্টারকে মার্জ করতে পারি না could

কীভাবে আমরা এই বিষয়টি এড়াতে পারতাম?


আপনি কীভাবে এটি সমাধান করতে চান আপনার দৃষ্টিভঙ্গির উপর নির্ভর করে, আপনি যদি কোনও প্রযুক্তিগত সমাধানের সন্ধান না করেন তবে এই প্রশ্নটি কর্মক্ষেত্রের জন্য আরও উপযুক্ত।
মালাভোজ

উত্তর:


74

একটি পদ্ধতির বৈশিষ্ট্য এটি ফ্ল্যাগিং। এটি কোড বেসে থাকতে পারে তবে কনফিগারেশন দ্বারা অক্ষম করা হবে।

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


9
কনফিগারেশন পতাকাঙ্কণ কি সেই কোডটির জন্য পরীক্ষার প্রচেষ্টা দ্বিগুণ করার ইঙ্গিত দেয় না? আপনি উভয় পাথ পরীক্ষা করতে হবে ।

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

4
সাধারণ শব্দটি হল ফিচার টগল । যদি কোনও ছোট "ফিচার এন্ট্রি পয়েন্ট" থাকে তবে এটি সম্ভবত পরিচালনার সিদ্ধান্তের পরে করা যেতে পারে। যদি তা না হয় তবে এই পদ্ধতিটির পাশাপাশি যে কোনও পদ্ধতিতেও সমস্যা হবে।
ডক ব্রাউন 14

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

25

কীভাবে আমরা এই বিষয়টি এড়াতে পারতাম?

একটি প্রক্রিয়া দৃষ্টিকোণ থেকে, খুঁজে বের করুন:

  • কে এই কাজ শুরু করার সিদ্ধান্ত গ্রহণকারী ছিলেন?
  • এই বৈশিষ্ট্যটি প্রকাশের সিদ্ধান্ত কেন বদলে গেল?
    • প্রত্যাশা মিস করেছেন?
    • Miscommunication?
    • অপ্রতুল ব্যবসায়ের সহায়তা?
    • কোনও গ্রাহকের জড়িততা নেই?

পথে পথে যোগাযোগের ড্রপগুলি সম্ভবত কম ছিল। এটি থাকা জরুরী কারণ এটি যখন কাজ করে না তখন আপনার বিকাশ প্রক্রিয়া ব্যবসায়ের প্রয়োজনীয়তাগুলি ভুল এবং ভুল বোঝার উপর ভিত্তি করে তৈরি হবে।


9
+10। ম্যানেজমেন্টটি বৈশিষ্ট্যটি প্রকাশের বিষয়ে সন্দেহ শুরু করার সাথে সাথে তাদের বিকাশকারীদের জানিয়ে দেওয়া উচিত ছিল, যাতে বৈশিষ্ট্যটি বিকাশে রূপান্তর করার সিদ্ধান্ত নেওয়ার সময় সম্ভাব্য অপসারণটিকে বিবেচনায় নেওয়া যেতে পারে।
বার্ট ভ্যান ইনজেন শেহেনো

14
এটি খুব গঠনমূলক উত্তর নয় - কখনও কখনও জিনিস সমস্ত কারণের জন্য পাশে যায়। অবশ্যই, এটির চেয়ে শীঘ্রই মার্জ করা উচিত নয় এটি সন্ধান করা গুরুত্বপূর্ণ, তবে এর অর্থ এই নয় যে শেষ পর্যন্ত কোনও বৈশিষ্ট্য টানা হবে। হতে পারে চুক্তির পরিবর্তন হতে পারে, আপনার গ্রাহক অর্থ প্রদান না করে, আইনি সমস্যাগুলি উপস্থিত হতে পারে .. আপনাকে এখনও দোষের আঙ্গুলের দিকে ইঙ্গিত করার পরিবর্তে সমস্যাটি পরিচালনা করতে হবে
gbjbaanb

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

2
আমি সম্পূর্ণরূপে একমত, এটি ম্যানেজমেন্ট স্ক্রুআপ, কোনও বিকাশকারী নয়।
durron597

3
@ জেনারল্যান্ড আমার বক্তব্যটি হ'ল আপনি কিছু সমস্যা এড়াতে পারবেন না, সুতরাং পরিস্থিতিটি কীভাবে পুনরুদ্ধার করবেন তা আপনাকে বিবেচনা করতে হবে। আশা করি আপনি এটি খুব ঘন ঘন পাবেন না, তবে তাড়াতাড়ি বা পরে ঘটতে বাধ্য হবে সুতরাং সেই অনুযায়ী পরিকল্পনা করুন।
gbjbaanb

19

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

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

এবং এটি আসলে আপনার বর্তমান পরিস্থিতিতে এটি পরিচালনা করতে পারে। গিট ওয়ার্কফ্লোর দৃষ্টিকোণ থেকে, পরিবর্তনটির অনুরোধটি প্রকাশের ১.০ এর জন্য পরিচালনার পক্ষ থেকে আসে বা পরিবর্তন অনুরোধটি যদি কোনও নতুন গ্রাহক 2.0 প্রকাশের জন্য চান তবে তা বিবেচনা করা উচিত নয়।


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

@ গুড্ডর: আমার সম্পাদনা দেখুন।
ডক ব্রাউন

1

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

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

  • এটি মাস্টারকে সর্বদা উত্পাদন-প্রস্তুত অবস্থায় প্রতিফলিত করে রাখে (হুক দিয়ে স্বয়ংক্রিয়ভাবে চলতে পারে)
  • বিকাশ সর্বদা সর্বশেষতম বিতরণ করা (এবং পরীক্ষিত) পরবর্তী প্রকাশের প্রার্থীকে প্রতিফলিত করে

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

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

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