এই Flutter রিলিজ রেডিনেস চেকলিস্ট ব্যবহার করে সাইনিং, ফ্লেভার, ক্র্যাশ রিপোর্টিং, পারমিশন কপি এবং স্টোর অ্যাসেটগুলো প্রস্তুত করুন যাতে প্রথম সাবমিশন শান্তিপূর্ণ এবং সম্পূর্ণ হয়।
“রিলিজ-রেডি” মানে শুধু “অ্যাপ আমার ফোনে চলে” নয়। এর অর্থ আপনি একটি প্রোডাকশন বিল্ড তৈরি করতে পারবেন, সেটি একটি পরিচ্ছন্ন ডিভাইসে ইনস্টল করবেন, এবং স্টোরে জমা দেওয়ার সময় শেষ মুহূর্তে কোনো সমস্যা হবে না।
প্রথম সাবমিশনের ঠিক আগেই যা ভেঙে যায় সেগুলো সাধারণত বিরক্তিকর কিন্তু ব্যথাজনক: হারানো সাইনিং কী, দুর্ঘটনাক্রমে আপলোড করা ডিবাগ বিল্ড, লজ না থাকা ক্র্যাশ, সন্দেহজনক মনে হওয়া পারমিশন প্রম্পট, বা অ্যাপের সঙ্গে মিল না থাকা স্টোর অ্যাসেট (ভুল আইকন, পুরাতন স্ক্রিনশট, অনুপস্থিত প্রাইভেসি টেক্সট)।
প্রথম Flutter সাবমিশনের জন্য “রিলিজ-রেডি” চারটি ফলাফলের উপর নীচে সংক্ষেপে নির্ভর করে:
এটি প্রথম সাবমিশনের অপরিহার্য বিষয়গুলোর উপর ফোকাস করে: সাইনিং, ফ্লেভার, ক্র্যাশ রিপোর্টিং, পারমিশন কপি ও টাইমিং, এবং স্টোর অ্যাসেট। এটি পুরো QA পরিকল্পনা, পারফরম্যান্স অডিট বা আইনি রিভিউ নয়।
কমপক্ষে কয়েকটি ফোকাসড সেশন পরিকল্পনা করুন। একজন একক ডেভেলপার সাধারণত ১–২ দিনে এটি কভার করতে পারেন। একটি টিমে, স্পষ্ট দায়িত্ব নির্ধারণ করুন (সাইনিং/বিল্ডস, ক্র্যাশ রিপোর্টিং, স্টোর লিস্টিং ও কপি) যাতে কিছুই শেষ মিনিটে পড়ে না যায়।
অধিকাংশ “শেষ মুহূর্তের” রিলিজ সমস্যা শুরুতেই না নেওয়া সিদ্ধান্ত থেকেই হয়। এখন কয়েকটি বেসিক সিদ্ধান্ত লক করে নিন, তাহলে পরের সব কাজ সহজ হবে।
আইডেন্টিটির সঙ্গে শুরু করুন: ব্যবহারকারীরা যে নামটি দেখবে সেটি এবং স্টোর যে অভ্যন্তরীণ ID গুলো ব্যবহার করে (Android-এর package name, iOS-এর bundle identifier) ঠিক করে নিন। এগুলো পরে বদলে গেলে আপডেট, ডিপ লিঙ্ক এবং অ্যানালিটিক্স ইত্যাদি ভেঙে যেতে পারে। রিলিজ ভার্সন কিভাবে নির্ধারণ করবেন তাও ঠিক করে নিন, যাতে প্রতিটি বিল্ডের একটি স্পষ্ট নাম্বার থাকে এবং কখনো আন্দাজ করতে না হয় কোন ভার্সন লাইভ।
তারপর প্ল্যাটফর্ম সীমা নির্ধারণ করুন: দিন একে Android, iOS, বা দুইটিই হবে কি না, এবং ন্যূনতম OS ভার্সনগুলো কি হবে যা আপনার ব্যবহারকারীদের সাথে মিলবে। পরে ন্যূনতম উন্নীত করলে ডিজাইন পরিবর্তন বা এমন ডিভাইস বাদ পড়তে পারে যা আপনি ধরে নিয়েছিলেন সাপোর্ট করছেন।
এই সিদ্ধান্তগুলো কোথাও দল সহজে খুঁজে পাবে এমনভাবে লিখে রাখুন:
সবশেষে, নিশ্চিত করুন আপনার স্টোর অ্যাকাউন্টগুলো আছে এবং আপনি পাবলিশ করতে পারবেন। অ্যাকাউন্ট অনুমোদনের জন্য অপেক্ষা, অনুপস্থিত ট্যাক্স ফর্ম বা আপলোড অনুমতি না থাকা লঞ্চ আটকে দেয়। আপনি যদি কোনো টুল যেমন Koder.ai দিয়ে অ্যাপ জেনারেট করেন বা হাতে কোড করেন, এই সিদ্ধান্তগুলো তখনও প্রযোজ্য।
অ্যাপ সাইনিং হলো প্রমাণ যে একটি অ্যাপ আপডেটে আসলেই আপনার পক্ষ থেকেই এসেছে। যদি সাইনিং ভুলভাবে কনফিগার করা থাকে, স্টোর আপলোড রিজেক্ট করতে পারে, বা ভবিষ্যতে আপডেট পাঠানোই অসম্ভব হতে পারে।
Android-এ, সাইনিং সাধারণত একটি keystore ফাইলে (পাসওয়ার্ডসহ) সংরক্ষিত আপলোড কী বোঝায়। iOS-এ, এটি certificates এবং provisioning profiles যা Apple Developer অ্যাকাউন্টের সাথে জড়িত। যদিও আপনি Koder.ai দিয়ে বিল্ড করে সোর্স এক্সপোর্ট করেন, প্রথম সাবমিশনের আগে স্টোর অ্যাকাউন্ট এবং সাইনিং অ্যাসেটের পরিষ্কার মালিকানা থাকা আবশ্যক।
প্রতিটি প্ল্যাটফর্মের জন্য একটি system-of-record মালিক নির্ধারণ করুন, সম্ভব হলে কোম্পানির অ্যাকাউন্টে। অ্যাক্সেস নিয়ম এমনভাবে সেট করুন যাতে আপনি একজন কম্পিউটার বা একজন ব্যক্তির উপর নির্ভর না করে থাকেন।
সংক্ষিপ্ত এক রেকর্ড রাখুন যা উত্তর দেয়:
একটি হারানো Android কী একই প্যাকেজে ভবিষ্যত আপডেট ব্লক করতে পারে। আলাদা স্থানে এনক্রিপ্টেড ব্যাকআপ রাখুন এবং রিস্টোর টেস্ট করুন। iOS-এ অ্যাক্সেস হারালে অ্যাকাউন্ট রিকভারি কষ্টসাধ্য হয়ে দাঁড়াতে পারে, তাই একাধিক বিশ্বস্ত অ্যাডমিন রাখুন এবং তাদের ডকুমেন্ট করুন।
পয়েন্টটি যাচাই করুন একটি পরিচ্ছন্ন মেশিনে (ফ্রেশ চেকআউট, নতুন CI রানার, বা টিমমেটের ল্যাপটপ)। যদি এটি শুধুমাত্র এক কম্পিউটারে কাজ করে, তবে সেটি রেডি নয়।
ফ্লেভারগুলো নিশ্চিত করে যে “আমার ফোনে চলে” থেকে “আমরা টেস্ট সার্ভার শিপ করে দিয়েছি” হওয়া রোধ পাওয়া যায়। সরল কথায়, একটি ফ্লেভার হলো একটি নামকরণ করা বিল্ড যা বিভিন্ন কনফিগ ব্যবহার করে যাতে আপনাকে প্রতিবার রিলিজের আগে ফাইলগুলো এডিট করতে না হয়।
অধিকাংশ দল দুইটি ফ্লেভার দিয়ে শুরু করা উচিত: dev (টেস্টিং-এর জন্য) এবং prod (যা আপনি সাবমিট করবেন)। যদি আপনার টিম “staging” বলে, সেটি ব্যবহার করুন। বিভ্রান্তিকর নামগুলো ভুল বিল্ড শেয়ার বা আপলোডের কারণ হয়।
ফ্লেভারের মধ্যে কি কি ভিন্ন হবে সেটা লক করুন। সবচেয়ে সাধারণ পার্থক্যগুলো হল অ্যাপ আইডেন্টিটি (নাম ও bundle ID), আইকন, API endpoints, ফিচার ফ্ল্যাগ, analytics/crash reporting সেটিং, এবং লগিং লেভেল।
সংবেদনশীল ভ্যালুগুলো রিপোতে না রাখাই ভালো। environment ফাইল, CI সিক্রেট, বা বিল্ড-টাইম ভ্যারিয়েবল ব্যবহার করুন যাতে কী কমিটে না পড়ে।
আপনি শেষ বলার আগেই প্রতিটি ফ্লেভার বিল্ড করুন, রিলিজ বিল্ডসহ। অনুপস্থিত কনফিগ এখানে ধরা পড়ে, লঞ্চ ডে-তে নয়।
আপনি একটি পরিষ্কার বিল্ড শিপ করলেও বাস্তব ডিভাইসের ডিভাইস, নেটওয়ার্ক সমস্যা, ও এজ-কেস ফ্লো থেকে সমস্যা পেতে পারেন। ক্র্যাশ রিপোর্টিং সেইসব অপ্রত্যাশিত বিষয়গুলোকে কার্যকর কাজের তালিকায় পরিণত করে।
একটি ক্র্যাশ রিপোর্টিং টুল বেছে নিন এবং আগে থেকেই সেটআপ করুন। ব্র্যান্ড ততটা গুরুত্বপূর্ণ নয় যতটা প্রতি রিলিজে দরকারী রিপোর্ট আসা।
অনেক “পুনরুৎপাদন করা যায় না” পরিস্থিতি মিসিং সিম্বল থেকেই হয়। রিলিজ স্টেপ হিসাবে আপলোড করুন:
যদি এটি ম্যানুয়াল হয়, ব্যস্ত সপ্তাহে এটি বাদ পড়ে যাবে।
দিন একে আপনি কি চান তা নির্ধারণ করুন: অ্যাপ ভার্শন/বিল্ড, ডিভাইস মডেল, OS ভার্শন, লোকেল, এবং শেষ স্ক্রিন বা অ্যাকশন। যদি আপনার অ্যাকাউন্ট থাকে, স্থায়ী অ্যানোনিমাস ইউজার ID এবং “logged in/logged out” ফ্ল্যাগ যোগ করুন। লগে ব্যক্তিগত ডেটা রাখা এড়ান।
নন-ফ্যাটাল এররগুলোও ক্যাপচার করুন। Flutter-এ অনেক সমস্যা exception হিসেবে দেখা যায় যা অ্যাপ ক্র্যাশ না করলেও সমস্যা সৃষ্টি করে (parse error, timeout, অনাকাঙ্ক্ষিত null)। এগুলোকে নন-ফ্যাটাল ইভেন্ট হিসেবে পাঠান একটি ছোট মেসেজ এবং কয়েকটি কী-ভ্যালু ফিল্ডসহ।
রিলিজের আগে এটি টেস্ট করুন: একটি স্টেজিং বিল্ড তৈরি করুন, একটি জোর করে ক্র্যাশ ট্রিগার করুন (ডিবাগ মেনু বা সিক্রেট জেসচারের পেছনে), এবং নিশ্চিত করুন আপনি একটি পড়ার মত স্ট্যাক ট্রেস দেখতে পাচ্ছেন সঠিক ভার্সন ও কনটেক্সট সহ।
পারমিশনগুলো প্রথম লঞ্চে বিশ্বাস হারানোর দ্রুত উপায়। রিলিজের আগে প্রতিটি পারমিশন তালিকাভুক্ত করুন—কোন ফিচার এটি চায় এবং ব্যবহারকারী কী সুবিধা পাবে। যদি এক বাক্যে বোঝাতে না পারেন, সম্ভবত আপনাকে এটি চাইতে না চিন্তা করা উচিত।
কপি সরল এবং নির্দিষ্ট রাখুন। “We need access to your photos” তুলনায় “Allow photos so you can attach a receipt to your expense” বেশি কার্যকর। “storage” এর মতো প্রযুক্তিগত শব্দ ব্যবহার করলে তা মুহূর্তেই ব্যাখ্যা করুন।
শুধুমাত্র সেই মুহূর্তে জিজ্ঞেস করুন যখন ব্যবহারকারী সংশ্লিষ্ট অ্যাকশনটি করে। স্টার্টে Photos পারমিশন চাওয়া যাবে না। ব্যবহারকারী যখন “Add photo” ট্যাপ করবে তখন একটি ছোট প্রি-পারমিশন স্ক্রিন দেখান যে কেন দরকার।
যদি ব্যবহারকারী না বলে, অ্যাপটি এখনও ব্যবহারযোগ্য হওয়া উচিত। আগেভাগেই ফ্যালব্যাক পরিকল্পনা করুন: ফিচার দৃশ্যমান রাখুন, কি ব্লক হচ্ছে তা ব্যাখ্যা করুন, সম্ভব হলে বিকল্প দিন, এবং প্রগ্রেস সেভ রাখুন যাতে তারা কাজ হারায় না। যদি তারা “Don’t ask again” নির্বাচন করে, সেটিংসে গাইড করুন কিন্তু জবরদস্তি করবেন না।
প্ল্যাটফর্ম-নির্দিষ্ট টেক্সট দ্বিগুণ পরীক্ষা করুন। iOS Info.plist-এ ক্লিয়ার ইউসেজ ডেসক্রিপশন দরকার। Android ম্যানিফেস্ট এ সঠিক এন্ট্রিজ দরকার এবং অনบาง ক্ষেত্রে ইন-অ্যাপ সংক্ষিপ্ত ব্যাখ্যা দরকার। অনুপস্থিত বা অস্পষ্ট টেক্সট রিভিউ দেরি বা ব্যবহারকারী পতন ঘটাতে পারে।
এটি একটি হালকা পাস যা কেবল রিয়েল রিলিজ বিল্ডে যে সমস্যা দেখা দেয় তা ধরতে সাহায্য করবে। এক ঘন্টারও কমে চালানো যায় এমনভাবে রাখুন।
একটি সহজ স্ক্রিপ্ট লিখুন যা যে কেউ অনুসরণ করতে পারে, এমনকি ডেভেলপার টুল ছাড়াই। নিয়ম: ব্যবহারকারীরা কী করে তা পরীক্ষা করুন, ডেভেলপার কী দেখে তা নয়।
কমপক্ষে একটি ছোট ফোন ও একটি বড় ডিভাইসে (এবং সম্ভব হলে একটি পুরনো OS ভার্সন):
রানের পরে, ফোর্স-ক্লোজ ও পুনরায় চালু করে নিশ্চিত করুন অ্যাপ পরিষ্কারভাবে শুরু হয় এবং ওয়ার্ম স্টেটের উপর নির্ভর করে না।
কিছু ব্যর্থ হলে, নির্দিষ্ট স্ক্রিন, শেষ অ্যাকশন, এবং এটি কি শুধুমাত্র একটি ডিভাইস সাইজে হচ্ছে তা নোট করুন—এটি প্রায়ই দ্রুত ফিক্সের জন্য যথেষ্ট তথ্য।
অনেক লঞ্চ স্ট্রেস কোড নয়, স্টোর পেইজ থেকে আসে। লিস্টিংকে রিলিজ কাজের অংশ হিসেবে বিবেচনা করুন এবং শেষ মুহূর্তের ডিজাইন অনুরোধ, অনুপস্থিত প্রাইভেসি উত্তর, এবং স্ক্রিনশট ঝামেলা এড়াতে পারবেন।
যা প্রায় নিশ্চিতভাবে লাগবে তা সংগ্রহ করুন: অ্যাপ আইকন, স্ক্রিনশট, একটি সংক্ষিপ্ত সাবটাইটেল, একটি দীর্ঘ বর্ণনা, এবং প্ল্যাটফর্ম-নির্দিষ্ট গ্রাফিক্স। প্রোমো ভিডিও ঐচ্ছিক—শুধুমাত্র তখনই উপকারী যখন আপনি তা আপডেট করে রাখতে পারবেন।
স্ক্রিনশটের জন্য ডিভাইস সাইজ আগে থেকেই ঠিক করে রাখুন এবং সেটাই বজায় রাখুন। একটি ধারাবাহিক অর্ডার রাখুন (onboarding, core screen, মূল ফিচার, settings, upgrade) যাতে আপডেটগুলো হঠাৎ করে ঝামেলার কারণ না হয়।
বর্ণনা মানুষের মতো করে লিখুন: একটি পরিষ্কার বাক্য বলুন অ্যাপটি কি করে, তারপর কয়েকটি ছোট সুবিধা লাইন, এবং যদি সাবস্ক্রিপশন বা অ্যাকাউন্ট থাকে তবে সরলভাবে তা উল্লেখ করুন। যা আপনি সাপোর্ট করতে পারবেন না তা প্রতিশ্রুতি দিবেন না।
এছাড়াও এখনই আপনার প্রাইভেসি ও ডেটা ব্যবহার সংক্রান্ত উত্তরগুলো জোগাড় করুন। আপনাকে ট্র্যাকিং, সংগ্রহকৃত ডেটা টাইপ, এবং পারমিশনের কারণে কি করা হচ্ছে তা জিজ্ঞাসা করা হবে। যদি আপনার অ্যাপ লোকেশন, কনট্যাক্টস বা ফটো চায়, সরল ভাষায় কেন তা লাগে তা ব্যাখ্যা করুন।
যদি অ্যাসেটগুলো সংগঠিত রাখেন, আপডেট রুটিন হয়ে ওঠে। একটি সহজ স্ট্রাকচার যথেষ্ট: আইকন, ডিভাইস টাইপ অনুযায়ী স্ক্রিনশট, কপি, প্রাইভেসি নোট, এবং রিলিজ নোট।
একটি ড্রাই-রান হচ্ছে স্টোর সাবমিশন ফ্লো সম্পূর্ণভাবে করা, কিন্তু Publish বোতাম চাপার আগে থেমে যাওয়া। এটি অনুমানগুলোকে বাস্তব প্রশ্নে পরিণত করে।
আপনি যে বিল্ডটি সাবমিট করতে ইচ্ছুক সেটি বেছে নিন (অবশ্য সবসময়.Publish করবেন না)। আপলোড করুন, ফর্মগুলো পূরণ করুন, এবং সবকিছু ড্রাফট হিসেবে সেভ করুন। আপনি চাইবেন মিসিং ইনফো সময় থাকার অবস্থায় পেয়ে যান।
যাচাই করুন:
“যদি প্রথম রিলিজ খারাপ থাকে” কী করবেন তাও পরিকল্পনা করুন। কিভাবে রোলব্যাক করবেন (পুরোনো সাইন করা আর্টিফ্যাক্ট রাখুন), কিভাবে হটফিক্স পাঠাবেন, এবং কোন ঘটনায় রোলআউট বন্ধ করবেন (ক্র্যাশ spike, লগইন ব্যর্থতা) তা নির্ধারণ করুন।
প্রারম্ভিক ফিডব্যাক সংগ্রহের পরিকল্পনাও করুন প্রথম ৪৮ ঘণ্টার জন্য: ছোট একটি গ্রুপ চ্যানেল, একটি মনিটর করা সাপোর্ট ইনবক্স, এবং ইন-অ্যাপ “Send feedback” অপশন সাধারণত স্পষ্ট সমস্যাগুলো একস্টার রিভিউ হওয়ার আগে ধরতে পারে।
বেশিরভাগ দেরি হয় কারণ আপনি যে বিল্ড টেস্ট করেছেন সেটিই শিপ করা হয় না। একটি ডিবাগ বা প্রোফাইল বিল্ড সুন্দর দেখাতে পারে, কিন্তু রিলিজ বিল্ড রিয়েল ডিভাইসে minification, ভিন্ন কনফিগ ভ্যালু, বা অনুপস্থিত runtime পারমিশনের কারণে ব্যর্থ হতে পারে।
আরেকটি সময় নষ্ট করা বিষয় হলো ডেভেলপমেন্ট ও প্রোডাকশন সেটিংস মিশে যাওয়া: স্টেজিং API URL শিপ হয়ে যাওয়া, ভুল analytics কী, বা টেস্ট পেমেন্ট সেটিংস পাঠিয়ে দেওয়া। প্রোডাকশনকে আলাদা এনভায়রনমেন্ট হিসেবে ট্রিট করুন এবং নির্দিষ্ট রিলিজ আর্টিফ্যাক্টে যাচাই করুন।
এই ফাঁদগুলো দলগুলোকে বারবার পুড়িয়ে দেয়:
একটি শুক্রবার আপলোড কল্পনা করুন: রিভিউয়ার অ্যাপ খুলে একটি ফিচার ট্যাপ করে যা অ্যাক্সেস চায়, এবং টেক্সট অস্পষ্ট। আপনি কপি ঠিক করেন, কিন্তু সাইনিং কী ওই সহকর্মীর মেশিনে আছে যিনি অফলাইনে আছেন। এটিই দুইটি টাকসেভ করা দিন।
প্রথম স্টোর বিল্ড কাটার একদিন আগে এটি ব্যবহার করুন। এটি উদ্দেশ্যগতভাবে সংক্ষিপ্ত। যদি কোনো আইটেম “হয়তো” হয়, তাহলে আগে থামুন এবং সেটি ঠিক করুন।
আপনি যদি এমন একটি প্ল্যাটফর্ম ব্যবহার করে বিল্ড করেন যা সোর্স কোড এক্সপোর্ট করতে পারে, যেমন Koder.ai (koder.ai), তাহলে একটি আরেকটি চেক যোগ করুন: নিশ্চিত করুন এক্সপোর্ট করা প্রোজেক্টটি সেই একই সাইন করা রিলিজ বিল্ড তৈরি করে যা আপনি আপলোড করতে চান।
একটি ছোট তিন সদস্যের টিম তাদের প্রথম Flutter অ্যাপ স্টোরে পাঠাচ্ছে: এক জন ডেভেলপার, এক জন ডিজাইনার, এবং অর্ধেক সময়ের একটি PM। তারা প্রথম সাবমিশনকে অনুশীলনের মত আচরণ করে।
সোমবার, ডেভেলপার রিলিজ বিল্ড জেনারেট করে এবং দেখতে পান সাইনিং কী একটি ল্যাপটপে আছে যা মুছে ফেলা হবে। তারা সেই দিনেই ঠিক করে: কীটি একটি শেয়ার্ড, অ্যাক্সেস-কন্ট্রোলড ভল্টে সরায়, মালিকানা ডকুমেন্ট করে, এবং CI মেশিন সাইন করতে পারে তা নিশ্চিত করে।
মঙ্গলবার, PM প্রতিটি পারমিশন প্রম্পট জোরে পড়ে। একটি উল্লেখযোগ্য: ফটো পারমিশন টেক্সটে “required” লেখা আছে, অথচ অ্যাপ শুধুমাত্র ঐচ্ছিক প্রোফাইল ছবি জন্য এটি চায়। তারা কপি পরিবর্তন করে যাতে সুবিধা ব্যাখ্যা করে এবং পারমিশনটি ব্যবহারকারী “Add photo” ট্যাপ করার মুহূর্তে করে।
বৃহস্পতিবার, তারা একটি পূর্ণ ড্রাই-রান সাবমিশন করে চূড়ান্ত স্ক্রিনশট, রিলিজ নোট, এবং প্রোডাকশন বিল্ড সহ। স্টোর বর্ণনা ও ইন-অ্যাপ সাবস্ক্রিপশন লেবেল মধ্যে একটি অসঙ্গতি ফ্ল্যাগ করে। ড্রাই-রান হওয়ায় তারা লঞ্চের আগে শব্দ পরিবর্তন করে পুনরায় সাবমিট করে।
পরবর্তী বার তাদের জন্য একটি সহজ টাইমলাইন রখে দেয়া হয়:
প্রথম লঞ্চ আপনাকে শেখায় “রেডি” আসলে কেমন লাগে। তা সতেজ থাকাকালীন ধারণ করে রাখুন।
স্পষ্ট মালিক নির্ধারণ করুন। ছোট টিমেও “প্রত্যেকে” সাধারণত মানে “কেউই নয়”, এবং মূল টাস্কগুলো ফসকে যায়:
আপনি যা করলেন তা একটি পুনরাবৃত্ত যোগ্য চেকলিস্ট ও রিলিজ নোট টেমপ্লেটে পরিণত করুন: আপনি কোন কমান্ড চালিয়েছিলেন, কোন অনুমোদন প্রয়োজন ছিল, এবং কোন ফাইল আপলোড করেছিলেন। গটচাসগুলোও যোগ করুন—কোন ফ্লেভার প্রোডাকশন, এবং কোন পারমিশন টেক্সট রিভিউআর্থে প্রশ্ন করা হয়েছিল।
এক সপ্তাহের মধ্যে একটি ২০ মিনিটের পোস্ট-রিলিজ রিভিউ নির্ধারণ করুন। ফোকাস রাখুন ফিক্সে, দোষারোপ নয়:
আপনি যদি Koder.ai দিয়ে তৈরি করেন, Planning Mode আপনাকে রিলিজ টাস্কগুলো এক জায়গায় ট্র্যাক করতে সাহায্য করতে পারে, এবং snapshots আপনাকে শেষ মুহূর্তের পরিবর্তনের আগে একটি জানাশোনা-ভাল স্টেট দেয়।
Release-ready বলতে বোঝায় আপনি একটি সাইন করা প্রোডাকশন (release) বিল্ড তৈরি করতে পারেন যা একটি পরিচ্ছন্ন ডিভাইসে ইনস্টল হয় এবং শেষমুহূর্তের সমস্যার ছাড়াই সাবমিট করা যায়।
একটি ব্যবহারিক বেসলাইন:
একটি release বিল্ড তৈরি করুন, তারপর যা কখনো আপনার অ্যাপ ইনস্টল করা নেই এমন একটি ডিভাইসে তা ইনস্টল করুন।
চেক করুন:
যদি আপনি শুধুমাত্র debug/profile টেস্ট করে থাকেন, ধরে নিন আপনি আসলেই যা শিপ করছেন তা পরীক্ষা করেননি।
সাইনিং অ্যাসেটকে প্রোডাকশন ক্রেডেনশিয়াল হিসেবে আচরণ করুন:
যদি কীটি শুধুমাত্র এক ল্যাপটপে থাকে, আপনি আপডেটে ব্লক হয়ে যাবেন।
Apple Developer অ্যাকাউন্টের সাথে সাইনিং জড়িত রাখুন এবং পরিষ্কার অ্যাডমিন অ্যাক্সেস নিশ্চিত করুন।
শুরুতেই করুন:
দুইটি ফ্লেভার দিয়ে শুরু করুন: dev এবং prod।
সাধারণত নিম্নলিখিত পার্থক্য থাকবে:
লক্ষ্য হলো রিলিজের আগে ম্যানুয়ালি ফাইল সম্পাদনা করা এড়ানো।
সিক্রেট ইনজেকশনের ব্যবহার করুন না যে কনফিগ রিপোতে রাখবেন।
ভালো অভ্যাস:
এটি স্টেজিং এন্ডপয়েন্ট বা টেস্ট পেমেন্ট সেটিংস ভুল করে শিপ হওয়া আটকায়।
একটি ক্র্যাশ রিপোর্টিং টুল বেছে নিন এবং শুরুতেই সেটি যুক্ত করুন।
ন্যূনতম সেটআপ:
তারপর একটি স্টেজিং/রিলিজ বিল্ডে জোর করে ক্র্যাশ ট্রিগার করে নিশ্চিত করুন রিপোর্ট ব্যবহারযোগ্য দেখায়।
শুধুমাত্র যখন ব্যবহারকারী সংশ্লিষ্ট অ্যাকশন করে তখনই পারমিশন চাইতে হবে।
ভাল প্যাটার্ন:
অস্পষ্ট প্রম্পট ও খুব আগেই পারমিশন চাওয়া ব্যবহারকারীর আস্থা নষ্ট করে এবং রিভিউ দেরি করতে পারে।
একটি দ্রুত “রিলিজ বিল্ড স্মোক টেস্ট” চালান যা যে কেউ অনুসরণ করতে পারে:
নোট রাখুন: শেষ অ্যাকশন, স্ক্রিন, ডিভাইস মডেল, এবং পুনরুৎপাদনযোগ্য কি না।
ড্রাই-রানটি স্টোর সাবমিশন ফ্লো সম্পূর্ণভাবে অনুসরণ করা, কিন্তু Publish চাপার আগে বন্ধ করা। এটি অনুমানকে বাস্তবে নিয়ে আসে।
আপনি যা যাচাই করবেন:
পাবলিশ চাপার আগে রোলব্যাক/হটফিক্স প্ল্যান নির্ধারণ করুন এবং প্রথম ৪৮ ঘণ্টায় কীভাবে প্রাথমিক ফিডব্যাক সংগ্রহ করবেন তাও ঠিক করুন।
