দল বা অ্যাপের আকার কি রিলিজ প্রক্রিয়াকে প্রভাবিত করে? ভাল, এটা নির্ভর করে. আসুন একটি ছোট দল নিয়ে একটি স্টার্টআপ কল্পনা করি। এই ক্ষেত্রে, দল সাধারণত একটি বৈশিষ্ট্য তৈরি করে এবং তারপরে এটি প্রকাশ করে। এখন, একটি বড় প্রকল্প কল্পনা করা যাক, উদাহরণস্বরূপ, একটি ব্যাঙ্কিং অ্যাপ, এতে অনেক দল কাজ করছে।

এই ক্ষেত্রে, সম্ভবত একটি প্রক্রিয়া, মুক্তি চক্র, এবং হয়ত কিছু আমলাতন্ত্র থাকা উচিত। তা না হলে বিশৃঙ্খলা সৃষ্টি হবে।

সুতরাং, কখন এটি পরিষ্কার হয়ে যায় যে আপনার অ্যাপের জন্য এই ধরনের একটি প্রক্রিয়া সেট আপ করার সময় এসেছে?

এই নিবন্ধে, আমি ডোডো পিৎজা অ্যাপের (Android এবং iOS) জন্য রিলিজ ট্রেন বাস্তবায়নের আমার অভিজ্ঞতা এবং আমাদের টিমকে রিলিজ ট্রেন বাস্তবায়ন করতে যে সমস্যার মুখোমুখি হয়েছিল তা শেয়ার করব।

আপনি যদি একটি Android বা iOS প্রকল্পের টিম লিড/টেক লিড হন যা দ্রুত ক্রমবর্ধমান হচ্ছে এবং আপনি এখনও মুক্তির প্রক্রিয়াটি পরিচালনা না করে থাকেন, আমি আশা করি আমাদের অভিজ্ঞতা আপনাকে সাহায্য করবে।

কিভাবে এটি হতে ব্যবহৃত

2021 সালে, আমরা ইতিমধ্যে আমাদের দলগুলিতে একটি ট্রাঙ্ক-ভিত্তিক উন্নয়ন (TBD) পদ্ধতি ব্যবহার করছিলাম। আমরা বৈশিষ্ট্য টগল, পচনশীল কাজ এবং রান ইউনিট এবং UI পরীক্ষা দিয়ে কোডটি কভার করেছি। আমাদের বৈশিষ্ট্য শাখা বেশি দিন বাঁচেনি, এবং আমাদের CI কাজ করছিল।

রিলিজ প্রক্রিয়া খুব সহজ ছিল: যে কেউ তাদের বৈশিষ্ট্য রোল আউট করতে প্রস্তুত ছিল, এটি রোল.

আদর্শ দৃশ্যকল্প

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

উদাহরণস্বরূপ, ধূসর দল 4টি ধাপে তাদের বৈশিষ্ট্য তৈরি করেছে, নীল এবং কমলা দল 1টি ধাপে তাদের বৈশিষ্ট্য তৈরি করেছে এবং সবুজ দল 2টি ধাপে তাদের বৈশিষ্ট্য তৈরি করেছে৷

যখন একটি দল একটি বৈশিষ্ট্য শেষ করে, তখন তারা একটি রিলিজ বের করতে পারে। উদাহরণস্বরূপ, যদি নীল দল একটি বৈশিষ্ট্য শেষ করে, তারা একটি প্রকাশ করতে পারে। তারপরে, কমলা দল একটি বৈশিষ্ট্য শেষ করবে এবং আরেকটি প্রকাশ করবে।

আমাদের কাছে নিখুঁত প্রবাহ ছিল, যেমনটা তখন মনে হয়েছিল। এটি একটি বিন্দু পর্যন্ত দুর্দান্ত কাজ করেছে, তবে সমস্ত ভাল জিনিস শেষ হয়ে যায়।

কিছু ভুল হয়েছে: কঠিন, ভিড়, এবং অপ্রত্যাশিত

বিশাল

আমরা প্রথম যে সমস্যার সম্মুখীন হয়েছিলাম তা হল যে রিলিজগুলি প্রচুর বৈশিষ্ট্য জমা করতে শুরু করে এবং খুব বড় হয়ে ওঠে।

দলগুলি সর্বদা তাদের বৈশিষ্ট্যগুলি অবিলম্বে প্রকাশ করতে চায় না। রিলিজ এবং রিগ্রেশন প্রক্রিয়া সময়সাপেক্ষ এবং 3-4 দিন সময় নেয়। তাই যদি আপনার বৈশিষ্ট্যটি ছোট হয় এবং জরুরী না হয় তবে আপনি সর্বদা এটি নিজেই প্রকাশ করতে পারবেন না কারণ সম্ভবত, অন্য কোনো দল শীঘ্রই একটি রিলিজ করবে এবং এটি সেই রিলিজে অন্তর্ভুক্ত হবে। মোটামুটি এই মত লাগছিল:

এটি বেশ ভঙ্গুর ব্যবস্থা ছিল, বিশেষ করে যখন দলের সংখ্যা বাড়তে শুরু করে। অনেক দল অনেক ছোট বৈশিষ্ট্য তৈরি করেছে, এবং প্রতিটি নতুন রিলিজে নতুন কোডের মোট ভলিউম বিশাল হয়ে উঠেছে। যখন কেউ তাদের বড় বৈশিষ্ট্যটি প্রকাশ করতে পারে, তখন তাদের এটির সাথে একটি সম্পূর্ণ ম্যামথ প্রকাশ করতে হয়েছিল।

ম্যামথ-রিলিজের ফলে:

• বিলম্বিত রিগ্রেশন;

• রিগ্রেশন বাগ উচ্চ ঝুঁকি;

• উৎপাদনে বাগ পাওয়ার ঝুঁকি বেশি।

আমাদের এটি তৈরি করা দরকার ছিল যাতে উদাহরণ থেকে নীল এবং কমলা দলটি মুক্তি দিতে না চাইলেও মুক্তিটি কোনওভাবে সম্পন্ন হবে।

প্রতিবন্ধকতা

প্রতিটি দল অনন্য, এবং প্রতিটি বৈশিষ্ট্য ভিন্ন। কখনও কখনও, জিনিসগুলি এমনভাবে ঘটেছিল যে বেশ কয়েকটি দল একই সময়ে তাদের বৈশিষ্ট্যগুলি শেষ করবে। এই ক্ষেত্রে, "আমার জন্য অপেক্ষা করুন, আমি আগামীকাল সকালে এটি একত্রিত করব, আমি প্রতিশ্রুতি দিচ্ছি!" কাছাকাছি যাচ্ছে.

শেষ পর্যন্ত, এই ধরনের বাধাগুলির ফলে:

• রিলিজ ম্যামথে পরিণত হয়;

• বিলম্বিত রিলিজ রিলিজ টিমের পরিকল্পনাকে নেতিবাচকভাবে প্রভাবিত করে বিশেষ করে যদি অন্য সবার চাহিদা পূরণ হয়।

আমাদের 2টি গুরুত্বপূর্ণ পরিবর্তন করতে হবে:

1. রিলিজিং দলকে কারো জন্য অপেক্ষা করতে হবে না;

   
   

2. পরবর্তী রিলিজ কখন প্রত্যাশিত হবে তা প্রতিটি অন্য দলের জানা উচিত।

অনুমানযোগ্যতার অভাব

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

ফলস্বরূপ, নীল দলটি ব্যবসাকে বলেছিল যে বৈশিষ্ট্যটি শীঘ্রই উত্পাদন করা হবে, তবে এটি শীঘ্রই যথেষ্ট নয় বলে প্রমাণিত হয়েছে। ফলস্বরূপ, বৈশিষ্ট্যটি কখন উত্পাদনে আসবে তা পূর্বাভাস দেওয়া অসম্ভব।

এর মানে এই নয় যে নীল দল দায়িত্বজ্ঞানহীন। যদি তাদের একটি অতি গুরুত্বপূর্ণ বা জরুরী বৈশিষ্ট্য থাকে তবে অবশ্যই তারা নিজেরাই এটি প্রকাশ করবে। কিন্তু অন্যান্য ক্ষেত্রে, ব্যবহারকারীদের জন্য বৈশিষ্ট্যটি কখন উপলব্ধ হবে তা সঠিকভাবে বলার কোন উপায় নেই।

আপনি অনুমান করতে পারেন, আমরা প্রায়ই এই ধরনের সমস্যা সম্মুখীন হয়. আমাদের সঠিকভাবে বলতে সক্ষম হওয়া দরকার যে কখন গ্রাহকরা তার আকার বা জরুরিতা নির্বিশেষে উত্পাদনে একটি বৈশিষ্ট্য পাবেন। সমস্ত 3টি সমস্যা (ম্যামথ রিলিজ, বাধা এবং পূর্বাভাসের অভাব) ঘনিষ্ঠভাবে সম্পর্কিত এবং একে অপরের পরিপূরক।

যাইহোক, সম্ভবত তাদের মধ্যে সবচেয়ে মৌলিক এবং গুরুত্বপূর্ণ হল পূর্বাভাসের অভাব। এটি অন্যান্য সমস্যা তৈরি করে।

ট্রেন ছেড়ে দিন

আমরা যথেষ্ট ছিল করেছি; এটি একটি পরিবর্তন করার সময় ছিল. রিলিজ ট্রেন আমাদের এটি করতে সাহায্য করার কথা ছিল।

রিলিজ ট্রেন শব্দের অর্থ ভিন্ন জিনিস: একটি নির্ধারিত রিলিজ প্রক্রিয়া বা একটি ডেডিকেটেড দল যা রিলিজ প্রক্রিয়া পরিচালনা করে। এখানে, আমরা নির্ধারিত রিলিজ প্রক্রিয়া সম্পর্কে কথা বলতে যাচ্ছি।

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

এইভাবে আমরা নিজেদের জন্য রিলিজ ট্রেনকে সংজ্ঞায়িত করেছি:

রিলিজ ট্রেন হল দলগুলোর মধ্যে রিলিজের সমন্বয় করার প্রক্রিয়া। সমস্ত রিলিজ একটি নির্দিষ্ট সময়সূচীতে ঘটে, বৈশিষ্ট্যগুলি প্রস্তুত কিনা তা ছাড়া। ট্রেন কারো জন্য অপেক্ষা করে না। আপনি যদি দেরি করেন তবে আপনাকে পরেরটির জন্য অপেক্ষা করতে হবে।

আমাদের রঙ-কোডেড দলগুলি ব্যবহার করে কয়েকটি উদাহরণ দিয়ে এটিকে ভেঙে দেওয়া যাক।

ম্যামথ সমস্যার সমাধান

রিলিজ ট্রেন সময়সূচীতে ঘটে এবং কে কি মূল শাখায় একীভূত করেছে তার উপর নির্ভর করে না। নীচের উদাহরণে, নীল এবং কমলা দলগুলির বৈশিষ্ট্যগুলি প্রকাশ করা হবে৷ বাকিরা পরের ট্রেনের জন্য অপেক্ষা করবে। আমরা আরও কিছুক্ষণ অপেক্ষা করতে পারি, কিন্তু তারপরে আমরা একটি ম্যামথ পেতে পারি।

প্রতিবন্ধকতা সমাধান

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

অথবা, বিপরীতভাবে, তারা বুঝতে পারে যে তারা অবশ্যই পরবর্তী ট্রেনের জন্য সময়মতো আসবে না, এবং তাই, তারা সম্পূর্ণ সময়সূচী জানে বলে তারা নিরাপদে বৈশিষ্ট্যটি শেষ করতে পারে।

নীচের উদাহরণে, নীল দলটি মুক্তি পেতে এবং মুক্তির আগে তাদের সমস্ত পরিবর্তন একত্রিত করতে চেয়েছিল৷ অন্যথায়, একটি প্রতিবন্ধকতা হতে পারে.

সবচেয়ে গুরুত্বপূর্ণ, রিলিজ ট্রেন আমাদের ডিজাইনের দ্বারা অনুমানযোগ্যতা দিয়েছে ।

এই উদাহরণগুলি কারো কাছে সুস্পষ্ট বলে মনে হতে পারে, কিন্তু আমরা সমস্যার সমাধান করেছি কারণ সেগুলি দেখা দিয়েছে। যখন রিলিজ নিয়ে কোনো সমস্যা ছিল না, তখন আমরা রিলিজ ট্রেন ব্যবহার করে বিরক্ত হইনি। যখন সমস্যাগুলি জমেছিল, তখন আমরা বুঝতে পেরেছিলাম যে সময় এসেছে।

কীভাবে আপনার দলে রিলিজ ট্রেন বাস্তবায়ন করবেন

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

ডোডো ইঞ্জিনিয়ারিং-এ, আমরা RFC এবং ADR উভয়ই ব্যবহার করি।

আমাদের আরএফসি প্রক্রিয়াটি এইরকম ছিল:

1. আমরা একটি RFC নথির খসড়া তৈরি করেছি;

   
   

2. আমরা এটি একটি ছোট দলে আলোচনা করেছি, মন্তব্য সংগ্রহ করেছি এবং সমন্বয় করেছি;

   
   

3. তারপর RFC একটি বিস্তৃত গ্রুপে যোগাযোগ করা হয়েছিল;

   
   

4. তারপর আমরা এটি বাস্তবায়ন করেছি;

   
   

5. এর পরে, আমরা প্রতিক্রিয়া সংগ্রহ করেছি, মেট্রিক্স ট্র্যাক করেছি এবং ফলাফল মূল্যায়ন করেছি।

আমাদের রিলিজ ট্রেনের জন্য RFC নথির গঠন নিম্নরূপ ছিল:

• রিলিজ ট্রেন প্রক্রিয়ার বিবরণ;

• কোন দল জড়িত, তারা কি করছে;

• সময়সূচী কি হবে;

• মেট্রিক্স

RFC-এর খসড়া তৈরিতে, আমরা অন্যান্য কোম্পানির অভিজ্ঞতার উপর নির্ভর করেছি:

• স্কাই স্ক্যানার
• সাউন্ডক্লাউড
• মনজো
• ফেসবুক

প্রথম বাস্তবায়ন

প্রথমত, আমরা এই প্রক্রিয়াটি নিয়ে এসেছি:

• প্রতি সপ্তাহে মুক্তি;

• বুধবার সকালে একটি রিলিজ শাখা তৈরি করুন;

• সম্পূর্ণ প্রত্যাবর্তন, এবং শুক্রবার পর্যালোচনার জন্য অ্যাপটি পাঠান;

• সোমবার মুক্তি পাকানো শুরু.

• মুক্তি দল:

  • ফিচার টিমের একটি থেকে 1 জন iOS এবং 1 জন Android ডেভেলপার;

  • 2 QA প্রকৌশলী।

    
    

• বুধবার একটি নতুন রিলিজ শাখা তৈরি করুন;

• প্রতিটি দলের মুক্তির পালা কখন তা নির্দেশ করে এক চতুর্থাংশ এগিয়ে একটি সময়সূচী তৈরি করুন। এক চতুর্থাংশের পরে একসাথে এবং সময়সূচী বাড়িয়ে দিন।

পরিকল্পিতভাবে, আমাদের রিলিজ ট্রেনটি দেখতে এইরকম ছিল:

এটা সব মসৃণভাবে যাননি

এক মাস পরে, এটা স্পষ্ট হয়ে উঠল যে যদিও প্রথম অভিজ্ঞতাটি দুর্দান্ত মনে হয়েছিল,

• প্রতি সপ্তাহে একটি রিগ্রেস করা এবং শুক্রবারের মধ্যে করা সত্যিই কঠিন ছিল;

• হটফিক্সের জন্য কোন সময় ছিল না, এবং তারা কখনও কখনও ঘটেছে.

2021 সালে, আমাদের রিগ্রেশন পরীক্ষায় গড়ে 3-4 দিন সময় লাগত। আমরা 2022 সালে এটিকে 2-3 দিনে সংক্ষিপ্ত করতে পেরেছিলাম, কিন্তু কখনও কখনও, এটি সেই সময়সীমা অতিক্রম করে। আমরা e2e পরীক্ষার মাধ্যমে রিগ্রেশন কেস কভার করতে থাকি, কিন্তু আমাদের এখনও 100% কভারেজ নেই। আমাদের প্রতিটি প্ল্যাটফর্মে যথাক্রমে প্রায় 70% এবং 60% রিগ্রেশন কেসের কভারেজ ছিল।

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

চূড়ান্ত উত্তর

আমরা 2-সপ্তাহের রিলিজ চক্রে চলে গিয়েছি, এবং রিলিজ ট্রেন এখন এইরকম দেখাচ্ছে:

• প্রতি 2 সপ্তাহে মুক্তি;
• বুধবার সকালে একটি রিলিজ শাখা তৈরি করুন;
• রিগ্রেস করুন, এবং শুক্রবার পর্যালোচনার জন্য অ্যাপটি পাঠান;
• সোমবার মুক্তি পাকানো শুরু.

• মুক্তি দল:

  • ফিচার টিমের একটি থেকে 1 জন iOS এবং 1 জন Android ডেভেলপার;

  • 2 QA প্রকৌশলী।

    
    

• প্রতিটি দলের মুক্তির পালা কখন তা নির্দেশ করে এক চতুর্থাংশ এগিয়ে একটি সময়সূচী তৈরি করুন। এক চতুর্থাংশ পরে, একসাথে এবং সময়সূচী প্রসারিত.
• ধীরে ধীরে রিলিজ আউট রোল;
• প্রয়োজনে হটফিক্সগুলি করুন, এখন যখন আমাদের কাছে তাদের জন্য সময় আছে;
• এক সপ্তাহ পরে বুধবার, একটি নতুন প্রকাশ শাখা তৈরি করুন।

সবকিছু পরিকল্পনা অনুযায়ী চলে গেলে প্রক্রিয়াটি এইভাবে দেখায়:

সম্ভাব্য হটফিক্সের জন্য প্রচুর সময় বাকি না থাকলে এটি সব একটি সাপ্তাহিক চক্রের মতো দেখায়। বর্ধিত রিগ্রেশন পরীক্ষার ক্ষেত্রে এটি দেখতে কেমন হবে:

কোন বড় ব্যাপার না হয়; এমনকি হটফিক্সের জন্য এখনও সময় আছে।

কীভাবে নতুন প্রক্রিয়া পূর্বাভাসযোগ্যতাকে প্রভাবিত করেছে?

আমাদের জন্য মূল লক্ষ্য ছিল পূর্বাভাসযোগ্যতা বৃদ্ধি করা । এটি দুটি অংশে বিভক্ত করা যেতে পারে:

1. আবেদন কবে প্রকাশ করা হবে;
2. কোন রিলিজে আমার বৈশিষ্ট্য প্রবেশ করবে?

আমরা এই প্রশ্নের উত্তর দিয়েছিলাম "কবে মুক্তি পাবে?" রিলিজ ট্রেন প্রক্রিয়া বাস্তবায়নের মাধ্যমে। এখন, প্রতিটি দল এই প্রশ্নের উত্তর দিতে সক্ষম হবে "কোন রিলিজে আমার বৈশিষ্ট্য শেষ হবে?" স্বাধীনভাবে এই মুহুর্তে যখন তারা বৈশিষ্ট্যটির পরিকল্পনা করে এবং মূল্যায়ন করে।

এর আগে, এটি নিশ্চিতভাবে বলা অসম্ভব ছিল কারণ অন্য দল মুক্তি দিতে পারে বা নাও করতে পারে। এখন, সবকিছুই নির্ভর করছে সেই দলের নিজস্ব পরিকল্পনার ওপর।

এটি আরও নিশ্চিত করার জন্য, আমরা মোবাইল ডেভেলপার, QA এবং পণ্য পরিচালকদের মধ্যে সমীক্ষা পরিচালনা করেছি, যেখানে একসাথে, অন্যান্য প্রশ্নের সাথে, আমরা জিজ্ঞাসা করেছি:

• পরের রিলিজ কবে? (100% এই প্রশ্নের উত্তর দিয়েছেন)।

• রিলিজ ট্রেন কি আপনাকে আপনার টিমওয়ার্ক পরিকল্পনা করতে সাহায্য করেছে? (75% ইতিবাচকভাবে উত্তর দিয়েছে, তবে কেউ কেউ রিলিজ ট্রেন ছাড়াই তাদের কাজের পূর্বাভাস দিয়েছে)।

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

মেট্রিক্সের উপর প্রভাব

শুধু সমস্যা সমাধানের বাইরে, আমরা মেট্রিক্সও পরিমাপ করেছি। এর প্রধান বেশী কটাক্ষপাত করা যাক.

অগ্রজ সময়

আমরা যে প্রথম গুরুত্বপূর্ণ মেট্রিকটি পরিমাপ করেছি তা হল মুক্তির জন্য লিড টাইম প্রতিশ্রুতি ।

এই গ্রাফ মত দেখায় কি. যখন আমরা একটি তীর দিয়ে রিলিজ ট্রেন প্রক্রিয়া শুরু করি তখন আমি পয়েন্টটি চিহ্নিত করেছিলাম।

গ্রাফটি দেখায় যে লিড টাইম প্রায় ছয় দিনের কাছাকাছি কোথাও নেমে গেছে। ছয় দিন দীর্ঘ না অল্প সময়?

গুগল বেঞ্চমার্ক

সেখানে এই মেট্রিকের জন্য Google থেকে বেঞ্চমার্ক , কিন্তু এটি বেশিরভাগই ব্যাকএন্ডের জন্য। তাদের স্কেলে, তারা নিম্নলিখিত গ্রুপগুলিকে আলাদা করে:

• অভিজাত: এক ঘন্টারও কম
• উচ্চ: 1 ঘন্টা থেকে 1 সপ্তাহ
• মাঝারি: 1 সপ্তাহ থেকে 6 মাস
• কম: 6 মাস বা তার বেশি

আমি বিশ্বাস করি যে স্ট্যান্ডার্ড মোবাইল অ্যাপের জন্য, লিড টাইম আদর্শভাবে রিলিজ চক্রের অর্ধেক দৈর্ঘ্যের জন্য লক্ষ্য করা উচিত। এটি প্রতিদিন প্রধান শাখায় একটি টাস্ক মার্জ করার সমতুল্য। এতে বলা হয়েছে, যদি রিলিজ চক্র 14 দিন হয়, লিড টাইম 7 দিনের জন্য লক্ষ্য করা উচিত ।

রিগ্রেশন প্রতি বাগ

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

এক পর্যায়ে, এই মেট্রিকটি তিনটি বাগ পর্যন্ত নেমে গিয়েছিল। নির্দিষ্ট সংখ্যাগুলি এতটা গুরুত্বপূর্ণ নয়, তবে সামগ্রিকভাবে, আপনি দেখতে পাচ্ছেন যে প্রবণতা কমে গেছে।

আরও মেট্রিক্স

রিলিজ ট্রেনের অংশ হিসেবে কোন মেট্রিকগুলি পর্যবেক্ষণ করা হয়েছিল তা আমি সংক্ষেপে আলোচনা করব৷

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

• আমরা ভাবছিলাম যে ঘন ঘন (সাপ্তাহিক) রিলিজ গ্রাহক মন্থন এবং অ্যাপটি মুছে ফেলার উপর প্রভাব ফেলবে কিনা। ফলস্বরূপ, আমরা কোন প্রভাব সনাক্ত করিনি।

প্রয়োগ করুন, উন্নতি করুন

আমরা বর্তমান প্রক্রিয়াটিকে পছন্দ করি কারণ আমরা মনে করি এটি তার লক্ষ্য অর্জন করেছে। আমরা এটিকে আরও উন্নত করার উপায়ও জানি:

• আমরা রিগ্রেশনকে আরও সহজ এবং দ্রুততর করার জন্য স্বয়ংক্রিয়ভাবে কাজ চালিয়ে যাচ্ছি।

• এখনও অবধি, আমরা কাজের অটোমেশনের অংশটি ছেড়ে দিয়েছি (শাখার জন্য স্ক্রিপ্ট), তবে এটি ভবিষ্যতে বৃদ্ধির একটি দুর্দান্ত পয়েন্টও হবে।

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

সারসংক্ষেপ

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

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

আমি আশা করি এই নিবন্ধটি এবং আমাদের অভিজ্ঞতা আপনাকে সাহায্য করবে, বিশেষ করে যদি আপনি ইতিমধ্যে একই ধরনের সমস্যার সম্মুখীন হয়ে থাকেন এবং তারা আপনাকে মুক্তির প্রক্রিয়া সম্পর্কে ভাবতে বাধ্য করে।

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

এবং আমাকে টুইটার এ অনুসরন কর . সাধারণত, আমি সাধারণভাবে অ্যান্ড্রয়েড ডেভেলপমেন্ট এবং সফটওয়্যার ইঞ্জিনিয়ারিং সম্পর্কে পোস্ট করি।

এছাড়াও এখানে প্রকাশিত