আমাদের উন্নয়ন দল গিটফ্লো শাখার কৌশলটি ব্যবহার করে আসছে এবং দুর্দান্ত হয়েছে!
আমাদের সফ্টওয়্যারটির মান উন্নত করতে সম্প্রতি আমরা কয়েকজন পরীক্ষক নিয়োগ করেছি। ধারণাটি হ'ল প্রতিটি বৈশিষ্ট্য পরীক্ষক দ্বারা পরীক্ষা / কিউএ করা উচিত।
অতীতে, বিকাশকারীরা পৃথক বৈশিষ্ট্যযুক্ত শাখাগুলিতে বৈশিষ্ট্যগুলিতে কাজ করে এবং হয়ে developগেলে সেগুলি আবার শাখায় মার্জ করে । বিকাশকারী সেই featureশাখায় নিজের কাজ নিজেই পরীক্ষা করবেন । পরীক্ষকগণের সাথে এখন, আমরা এই প্রশ্নটি জিজ্ঞাসা শুরু করি
কোন শাখায় পরীক্ষককে নতুন বৈশিষ্ট্যগুলি পরীক্ষা করা উচিত?
স্পষ্টতই, দুটি বিকল্প আছে:
- স্বতন্ত্র বৈশিষ্ট্য শাখায়
- উপর
developশাখা
বিকাশ শাখায় পরীক্ষা করা
প্রাথমিকভাবে, আমরা বিশ্বাস করি এটি যাওয়ার নিশ্চিত উপায় কারণ:
- এর বৈশিষ্ট্যটি
developশাখায় মিশ্রিত হওয়ার সাথে সাথে অন্যান্য সমস্ত বৈশিষ্ট্যগুলির পরীক্ষা করা হয় যা এটি শুরু হয়। - যেকোন দ্বন্দ্ব পরবর্তী সময়ের আগে সনাক্ত করা যায়
- এটি পরীক্ষকের কাজটিকে সহজ করে তোলে, তিনি সর্বদা কেবল একটি শাখা (
develop) নিয়ে কাজ করছেন। কোন শাখাটি কোন বৈশিষ্ট্যের জন্য তা সম্পর্কিত বিকাশকারীকে তাকে জিজ্ঞাসা করার দরকার নেই (বৈশিষ্ট্য শাখাগুলি ব্যক্তিগত শাখাগুলি প্রাসঙ্গিক বিকাশকারীদের দ্বারা একচেটিয়া এবং অবাধে পরিচালিত হয়)
এর সাথে সবচেয়ে বড় সমস্যা হ'ল:
developশাখা বাগ সঙ্গে দূষিত হয়।পরীক্ষক যখন বাগ বা দ্বন্দ্ব খুঁজে পান, তখন সেগুলি তাদের বিকাশকারীকে ফিরিয়ে দেয়, যিনি সমস্যাটি বিকাশকারী শাখায় স্থির করে (বৈশিষ্ট্য শাখাটি একবার মার্জ করার পরে ছেড়ে দেওয়া হয়েছিল), এবং এর পরে আরও কিছু সংশোধন প্রয়োজন হতে পারে। একাধিক সাবকোয়েন্স কমিট করে বা মার্জ করে (
developবাগগুলি ঠিক করার জন্য যদি একটি শাখাটি আবার শাখা থেকে পুনরায় তৈরি করা হয়)developযদি সম্ভব হয় তবে শাখা থেকে বৈশিষ্ট্যটি ফিরিয়ে নেওয়া খুব কঠিন করে তোলে ।developবিভিন্ন সময়ে শাখায় মার্জ করা এবং স্থির করা হচ্ছে এমন একাধিক বৈশিষ্ট্য রয়েছে । এটি যখনdevelopশাখার কয়েকটি বৈশিষ্ট্য সহ একটি রিলিজ তৈরি করতে চাই তখন এটি একটি বড় সমস্যা তৈরি করে
বৈশিষ্ট্য শাখায় পরীক্ষা করা
সুতরাং আমরা আবার চিন্তা করেছি এবং সিদ্ধান্ত নিয়েছি আমাদের বৈশিষ্ট্য শাখাগুলির বৈশিষ্ট্যগুলি পরীক্ষা করা উচিত। আমরা পরীক্ষার আগে, আমরা developশাখা থেকে বৈশিষ্ট্য শাখায় পরিবর্তনগুলি একত্রিত করি ( developশাখার সাথে ধরা যাক )। এটা ভাল:
- আপনি এখনও মূলধারার অন্যান্য বৈশিষ্ট্যগুলির সাথে বৈশিষ্ট্যটি পরীক্ষা করেন
- আরও বিকাশ (যেমন বাগ সংশোধন, বিরোধ নিষ্পত্তি)
developশাখাকে দূষিত করবে না ; - বৈশিষ্ট্যটি সম্পূর্ণরূপে পরীক্ষা ও অনুমোদন না হওয়া পর্যন্ত আপনি সহজেই প্রকাশ না করার সিদ্ধান্ত নিতে পারেন;
তবে কিছু ত্রুটি রয়েছে
- পরীক্ষককে কোডটি মার্জ করতে হবে এবং যদি কোনও বিরোধ (খুব সম্ভবত) থাকে তবে তাকে বিকাশকারীকে সাহায্যের জন্য জিজ্ঞাসা করতে হবে। আমাদের পরীক্ষকরা পরীক্ষায় বিশেষজ্ঞ এবং কোডিংয়ে সক্ষম নন।
- অন্য কোনও নতুন বৈশিষ্ট্যের অস্তিত্ব ছাড়াই কোনও বৈশিষ্ট্য পরীক্ষা করা যেতে পারে। উদাহরণস্বরূপ বৈশিষ্ট্য এ এবং বি উভয়ই একই সময়ে পরীক্ষার অধীনে রয়েছে, দুটি বৈশিষ্ট্য একে অপরের সম্পর্কে অবগত নয় কারণ সেগুলির দুটিই
developশাখায় একীভূত হয়নি । এর অর্থdevelopযখনই উভয় বৈশিষ্ট্য যেভাবেই বিকাশকারী শাখায় একত্রিত করা হয় তখন আপনাকে আবার শাখার বিরুদ্ধে পরীক্ষা করতে হবে । এবং আপনাকে ভবিষ্যতে এটি পরীক্ষা করতে হবে মনে রাখতে হবে। - যদি বৈশিষ্ট্য এ এবং বি উভয়ই পরীক্ষিত এবং অনুমোদিত হয় তবে মেশানো যখন কোনও বিরোধকে চিহ্নিত করা হয়, উভয় বৈশিষ্ট্যের জন্য বিকাশকারী উভয়ই বিশ্বাস করে যে এটি তার নিজের দোষ / কাজ নয় কারণ পরীক্ষার পরে তাঁর বৈশিষ্ট্যটি শাখাটি শাখা করেছে। যোগাযোগের ক্ষেত্রে একটি অতিরিক্ত ওভারহেড রয়েছে এবং কখনও কখনও যে কেউ বিরোধটি সমাধান করেন তিনি হতাশ হন।
উপরে আমাদের গল্প আছে। সীমিত সংস্থান সহ, আমি সর্বত্র সমস্ত কিছু পরীক্ষা করা এড়াতে চাই। আমরা এখনও এটি মোকাবেলার জন্য আরও ভাল উপায় খুঁজছি। অন্যান্য দলগুলি কীভাবে এই ধরণের পরিস্থিতি পরিচালনা করে তা আমি শুনতে চাই।
