ক্লায়েন্ট ও এজেন্সির জন্য সোর্স কোড হ্যান্ডঅফ চেকলিস্ট

সোর্স কোড হ্যান্ডঅফ থেকে কি অর্জিত হওয়া উচিত

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

যে কোনো সোর্স কোড হ্যান্ডঅফ চেকলিস্টের লক্ষ্য সহজ: হস্তান্তরের পরে ক্লায়েন্ট অ্যাপটি তৈরি, চালানো এবং ডিপ্লয় করতে পারে এজেন্সিকে ফোন না করেই। এতে কোনো অর্থে "কখনও সহায়তা নেই" বোঝায় না—এর মানে হলো মৌলিক কাজগুলো পুনরাবৃত্তিযোগ্য এবং ডকুমেন্টেড, যাতে পরবর্তী ব্যক্তি আত্মবিশ্বাসের সাথে এটিকে চালাতে পারে।

ডেলিভারেবল হিসেবে কি ধরা হবে তা স্পষ্ট করা জরুরি। ন্যূনতমভাবে, একটি সম্পূর্ণ হ্যান্ডঅফ সাধারণত অন্তর্ভুক্ত করে:

• সম্পূর্ণ রিপোজিটরি (ডিপ্লয়মেন্ট ফাইল ও মাইগ্রেশন স্ক্রিপ্টসহ)
• একটি ক্লিন মেশিনে কাজ করা সেটআপ ডকস
• অ্যাক্সেস হস্তান্তর (অ্যাকাউন্ট, অনুমতি, এবং সিস্টেম কোথায় থাকে)
• রুটিন কাজের জন্য একটি রানবুক (ডিপ্লয়, রোলব্যাক, ব্যাকআপ, লগ)\n- ক্লায়েন্ট রেফারেন্সের জন্য একটি চূড়ান্ত "নির্দিষ্টভাবে ভালো" ভার্সন ট্যাগ বা স্ন্যাপশট

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

সফলতার একটি ব্যবহারিক পদ্ধতি হলো যাচাইপরীক্ষা: এমন একজন ব্যক্তি যিনি অ্যাপটি তৈরি করেননি, কোড এক্সপোর্ট করতে পারেন (উদাহরণস্বরূপ Koder.ai মত একটি প্ল্যাটফর্ম থেকে), ডক্স অনুসরণ করে পরিবেশ ভেরিয়েবল সেট করতে পারেন, মাইগ্রেশন চালাতে পারেন, বিল্ড করতে ও সম্মত পরিবেশে ডিপ্লয় করতে পারেন।

এই চেকলিস্টটি প্রযুক্তিগত প্রস্তুতিতে কেন্দ্র করা—পরিবেশ ভেরিয়েবল, সিক্রেট রোটেশন, ডাটাবেস মাইগ্রেশন, ডিপ্লয়মেন্ট স্ক্রিপ্ট, এবং বিল্ড যাচাইকরণ। এটি আইনগত শর্ত, চুক্তি, IP ক্লজ, বা অর্থগত বিবাদ কভার করে না। সেগুলোও গুরুত্বপূর্ণ, কিন্তু আলাদা চুক্তিতে থাকা উচিত।

এক্সপোর্টের আগে: মালিকানা ও সময় নির্ধারণে একমত হওয়া

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

হ্যান্ডঅফ তারিখ ও ছোট ফ্রিজ উইন্ডো নির্ধারণ করুন

একটি হ্যান্ডঅফ তারিখ নির্ধারণ করুন এবং একটি ফ্রিজ উইন্ডো (প্রায় ২৪–৭২ ঘন্টা) যেখানে শুধুমাত্র জরুরি ফিক্সগুলোই যাবে। এতে এক্সপোর্টকৃত কোড ও চলমান সিস্টেম সিংক থাকে। ফ্রিজে হটফিক্স লাগলে পরিবর্তনগুলো ঠিক কী ছিল তা লিখে রাখুন এবং তা চূড়ান্ত এক্সপোর্টে অন্তর্ভুক্ত আছে কি না নিশ্চিত করুন।

অ্যাকাউন্ট ও বিলিংয়ের মালিকানা স্পষ্ট করুন

নির্ধারণ করুন DNS, ক্লাউড হোস্টিং, এবং যেকোনো পেইড সার্ভিসের মালিক কে হবে হ্যান্ডঅফের পরে। এটি কেবল কাগজপত্র নয়। যদি বিলিং এজেন্সির কার্ডে থাকে, সার্ভিসগুলো হঠাৎ বন্ধ হতে পারে।

কিছুনা দ্রুত কনক্রিট করতে:

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

এটি সাবলীল ভাষায় লিখে রাখুন যাতে দুই পক্ষই অনুসরণ করতে পারে।

পরিবেশগুলো ও এগুলো কোথায় চলছে তালিকা করুন

কোন কোন ইনভায়রনমেন্ট আছে (local, staging, production) এবং প্রতিটি কোথায় চলে তা একমত হন। নোট করুন staging কি এক আলাদা সার্ভার, আলাদা ডাটাবেস, বা কেবল একটি ফিচার ফ্ল্যাগ। যদি আপনি Koder.ai মত প্ল্যাটফর্ম ব্যবহার করে থাকেন, সেখানে কি হোস্ট করা আছে এবং এক্সপোর্টের পরে কি ক্লায়েন্টের ইনফ্রাসট্রাকচারে চলা প্রত্যাশিত তা নিশ্চিত করুন।

অ্যাক্সেস আগে জমা করুন

শেষ দিনের জন্য অ্যাক্সেস চাওয়ার চেষ্টা করবেন না। নিশ্চিত করুন সঠিক লোকেরা যা প্রয়োজন তা অ্যাক্সেস পেতে পারে: রিপো, CI, হোস্টিং, ডাটাবেস, এবং ইমেইল প্রোভাইডার।

সাথে চূড়ান্ত গ্রহণযোগ্যতা টেস্ট ও সাইন-অফ প্রক্রিয়া নির্ধারণ করুন। উদাহরণস্বরূপ: “ক্লায়েন্ট একটি ক্লিন মেশিন থেকে বিল্ড করতে পারে, মাইগ্রেশন চালাতে পারে, staging এ ডিপ্লয় করতে পারে, এবং স্মোক টেস্ট পাস করে। তারপর উভয় পক্ষ লিখিতভাবে সাইন-অফ করবে।”

রিপো ও ডকুমেন্টেশনের মৌলিক বিষয়গুলো

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

স্ট্রাকচারটি সহজ ও পূর্বানুমেয় রাখুন। পরিষ্কার টপ-লেভেল ফোল্ডার লক্ষ্য করুন, যেমন frontend/, backend/, mobile/, infra/, scripts/, এবং docs/। প্রজেক্ট যদি একটি মনোরেপো হয়, কিভাবে অংশগুলো সম্পর্কিত এবং কিভাবে প্রতিটা চালাতে হয় তা ব্যাখ্যা করুন।

README এমন হওয়া উচিত যে যে কেউ যিনি প্রজেক্ট বানাননি তবুও ব্যবহার করতে পারে। এতে প্রাথমিক প্রয়োজনীয়তা ও দ্রুততম পথের বিবরণ থাকা উচিত যাতে কোন অনুমান বা ধাঁধা না থাকে।

কি ডকুমেন্ট করতে হবে (ন্যূনতম)

শর্ট, মানুষের ভাষায় README অংশে নিম্নলিখিতগুলো উত্তর দিন:

• এই রিপো কি বাঁধে এবং এটি কী করে (একটি অনুচ্ছেদ)
• নির্দিষ্ট সংস্করণসহ পূর্বপ্রত্যাশ্যতাসমূহ (runtime, package manager, Docker যদি প্রয়োজন)
• লোকাল ডেভের জন্য এক-কমান্ড শুরু ধাপ (এবং সফলতা কেমন দেখায়)
• টেস্ট রান এবং প্রোডাকশন আর্টিফ্যাক্ট কিভাবে বিল্ড করবেন
• মূল ডকস কোথায়: আর্কিটেকচার নোট, মাইগ্রেশন, ডিপ্লয়মেন্ট নোট

সরল ভাষায় আর্কিটেকচার নোট দিন: কী কি কীকে কল করে এবং কেন। ছোট্ট একটি ডায়াগ্রাম ঐচ্ছিক, কিন্তু কয়েকটি বাক্য সাধারণত যথেষ্ট। উদাহরণ: “React ফ্রণ্টএন্ড Go API কল করে। API PostgreSQL থেকে পড়ে এবং লেখে। ব্যাকগ্রাউন্ড জবগুলো আলাদা ওয়ার্কার প্রসেস হিসেবে চলে।”

অবশেষে, হ্যান্ডঅফ বিল্ডের জন্য একটি সংস্করণকৃত চেঞ্জলগ বা রিলিজ নোট যোগ করুন। এটা CHANGELOG.md হতে পারে বা একটি সংক্ষিপ্ত “handoff release notes” ফাইল যেখানে নির্দিষ্ট কমিট/ট্যাগ, কি পাঠানো হয়েছে, এবং পরিচিত ইস্যুগুলো লেখা থাকবে।

যদি কোড Koder.ai থেকে এক্সপোর্ট করা হয়ে থাকে, জেনারেটেড প্রজেক্ট টাইপ (web, server, mobile), প্রত্যাশিত টুলচেইন (যেমন React, Go, PostgreSQL, Flutter), এবং ক্লায়েন্টকে কোন OS/টুলিং সংস্করণ ব্যবহার করে বিল্ড পুনরুত্পাদন করতে হবে তা উল্লেখ করুন।

পরিবেশ ভেরিয়েবল: ইনভেন্টরি ও ডকুমেন্টেশন

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

শুরু করুন এমন একটি ইনভেন্টরি লিখে যেটা একটি নতুন টিম অনুমান না করে অনুসরণ করতে পারে। সাধারণ ভাষায় রাখুন, এবং উদাহরণ মানের ফরম্যাট দিন (বাস্তব সিক্রেট নয়)। যদি কোনো ভেরিয়েবল ঐচ্ছিক হয়, তা না থাকলে কি হবে এবং কি ডিফল্ট ব্যবহার হবে তা বলুন।

ইনভেন্টরিটি উপস্থাপনের সহজ উপায়:

• ভেরিয়েবল নাম, এটি কি নিয়ন্ত্রণ করে, এবং একটি উদাহরণ মান
• প্রয়োজনীয় বনাম ঐচ্ছিক, এবং কোনো ডিফল্ট আচরণ থাকলে তা
• কোথায় সেট করা হয় (CI, হোস্টিং ড্যাশবোর্ড, লোকাল .env ফাইল)
• কোন পরিবেশগুলোতে আলাদা মান লাগবে (dev, staging, production)
• পরিবর্তনের মালিক কে (ক্লায়েন্ট, এজেন্সি, বা শেয়ার্ড)

পরিবেশ-নির্দিষ্ট পার্থক্যগুলো স্পষ্টভাবে তুলে ধরুন। উদাহরণস্বরূপ, staging একটি টেস্ট ডাটাবেস এবং স্যান্ডবক্স পেমেন্ট প্রোভাইডার ব্যবহার করতে পারে, আর production লাইভ সার্ভিস ব্যবহার করবে। এমন মানগুলোও নোট করুন যেগুলো সিস্টেম জুড়ে মিলে থাকা লাগবে—যেমন callback URL, allowed origins, বা মোবাইল অ্যাপের bundle identifier।

প্রতিটি মান বর্তমানে কোথায় আছে তা ডকুমেন্ট করুন। অনেক টিম মানগুলো তিন জায়গায় ছড়িয়ে রাখে: ডেভেলপমেন্টের জন্য লোকাল .env ফাইল, বিল্ডের জন্য CI ভেরিয়েবল, এবং রানটাইমের জন্য হোস্টিং সেটিংস। যদি আপনি Koder.ai থেকে প্রজেক্ট এক্সপোর্ট করেন, একটি .env.example ফাইল যোগ করুন এবং কোন ভেরিয়েবলগুলো প্রথম বিল্ডের আগে পূরণ করতে হবে তা সংক্ষিপ্তভাবে উল্লেখ করুন।

অবশেষে, প্রমাণ করুন যে রেপোতে কোনো সিক্রেট লুকানো নেই। কেবল বর্তমান ফাইলগুলো দেখার মাধ্যমে থামবেন না—কমিট ইতিহাসও রিভিউ করুন accidental কী, পুরনো .env ফাইল, বা sample কনফিগে কপি করা ক্রেডেনশিয়ালগুলো খুঁজে পেতে।

কংক্রিট উদাহরণ: একটি React ফ্রণ্টএন্ড ও একটি Go API কনফিগার হলে ফ্রণ্টএন্ডের জন্য API_BASE_URL লাগতে পারে, আর ব্যাকএন্ডের জন্য DATABASE_URL এবং JWT_SIGNING_KEY দরকার। যদি staging আলাদা ডোমেইন ব্যবহার করে থাকে, দুইটি মানই লিখে রাখুন এবং কোথায় পরিবর্তন করতে হবে তা বলুন, যাতে নতুন টিম স্টেজিং সেটিংস প্রোডাকশনে পাঠিয়ে দেয় না।

সিক্রেট রোটেশন: নিরাপদভাবে ট্রান্সফার করুন, তারপর কাজ প্রমাণ করুন

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

শুরুতেই পূর্ণ ইনভেন্টরি তৈরী করুন। শুধু ডাটাবেস পাসওয়ার্ডে থামবেন না। তৃতীয় পক্ষ API কী, OAuth ক্লায়েন্ট সিক্রেট, webhook সাইনিং সিক্রেট, JWT সাইনিং কী, SMTP ক্রেডেনশিয়াল, স্টোরেজ অ্যাক্সেস কী, এবং CI তে থাকা কোনো "অস্থায়ী" টোকেনও অন্তর্ভুক্ত করুন।

রোটেশন দিবসের জন্য একটি সহজ চেকলিস্ট:

• প্রতিটি সিক্রেট তালিকাভুক্ত করুন, এটি কি আনলক করে, এবং বর্তমানে কোথায় সেট আছে (লোকাল env ফাইল, CI, হোস্টিং ড্যাশবোর্ড, ভল্ট)
• ক্লায়েন্টের অ্যাকাউন্টের অধীনে নতুন ক্রেডেনশিয়াল তৈরি করুন, এবং প্রতিটির জন্য একটি মালিক (ব্যক্তি এবং একটি টিম ইনবক্স) নির্ধারণ করুন
• অ্যাপ কনফিগ আপডেট করে নতুন মান ব্যবহার করুন, তারপর প্রথমে staging বা টেস্ট এনভায়রনমেন্টে ডিপ্লয় করুন
• নতুনগুলো কাজ করলে পুরনো ক্রেডেনশিয়ালগুলো অবিলম্বে রিভোক করুন
• পরবর্তী রোটেশন সহজ ও দ্রুত করার জন্য রোটেশন ধাপগুলো লিখে রাখুন

রোটেশনের পরে প্রমাণ করুন কিছু ভেঙে যায়নি। কেবল লগ দেখা নয়—দ্রুত "বাস্তব ব্যবহারকারী" টেস্ট চালান।

সে ফ্লোগুলোতে ফোকাস করুন যেগুলো সিক্রেটের উপর নির্ভর করে:

• লগইন, সাইনআপ, পাসওয়ার্ড রিসেট, টোকেন রিফ্রেশ
• পেমেন্ট, ইমেইল পাঠানো, এবং ফাইল আপলোড
• ওয়েবহুক (সিগনেচার ভেরিফিকেশন ও রিট্রাই হ্যান্ডলিং)
• ব্যাকগ্রাউন্ড জব বা শিডিউল টাস্ক যেগুলো এক্সটার্নাল API কল করে
• অ্যাডমিন অ্যাকশন যা প্রিভিলেজড এন্ডপয়েন্ট হারক

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

শেষে, ডকুমেন্ট করুন কবে ও কোথায় সিক্রেটগুলো থাকবে (ভল্ট, CI ভেরিয়েবল, বা হোস্টিং সেটিংস), কে এগুলো পরিবর্তন করতে পারে, এবং রোটেশন সমস্য হলে কিভাবে নিরাপদে ব্যাকআউট করবেন।

ডাটাবেস মাইগ্রেশন ও ডেটা হ্যান্ডলিং

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

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

কি ডকুমেন্ট করতে হবে (যাতে কেউ অন্য কেউ চালাতে পারে)

একটি সংক্ষিপ্ত রানবুক রাখুন যা এই প্রশ্নগুলোর উত্তর দেয়:

• কোন কমান্ড মাইগ্রেশন চালায়, এবং কি অর্ডারে কাজগুলো করতে হবে (ডাটাবেস তৈরি, মাইগ্রেশন প্রয়োগ, তারপর সিডস)
• এটা পরিবেশভেদে কিভাবে ভিন্ন (local, staging, production), এমন কি কোনো “safe mode” ফ্ল্যাগ আছে কি না
• মাইগ্রেশন কি ডিপ্লয়ের সময় অটোমেটিক চালবে না কি ম্যানুয়ালি চালাতে হবে, এবং কে তা চালানোর অনুমতি পাবে
• সিড ডাটা কৌশল: নেই, শুধু ডেমো বা ন্যূনতম প্রয়োজনীয় রেকর্ড (অ্যাডমিন ইউজার, ডিফল্ট সেটিংস)
• রোলব্যাক পরিকল্পনা: কি কি উল্টানো যায়, এবং কি উল্টানো যাবে না (যেমন ডেস্ট্রাকটিভ কলাম ড্রপ)

রোলব্যাক সম্পর্কে স্পষ্টতা দরকার। কিছু পরিবর্তন ব্যাকআপ রিস্টোর ছাড়া উল্টানো যায় না—সেটা স্পষ্টভাবে বলুন এবং ডিপ্লয়ের আগে ব্যাকআপ স্টেপ (স্ন্যাপশট নিন, রিস্টোর প্রসেস যাচাই করুন) নিশ্চিত করুন।

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

যদি অ্যাপটি Koder.ai তে তৈরি হয়ে এক্সপোর্ট করা হয়ে থাকে, মাইগ্রেশন ফাইল এবং কোনো সিড স্ক্রিপ্ট এক্সপোর্টে অন্তর্ভুক্ত আছে কি না এবং ব্যাকএন্ড স্টার্টআপ প্রসেসে সেগুলো ঠিকভাবে রেফারেন্স করা হচ্ছে কি না তা দ্বারাও যাচাই করুন।

বিল্ড ও CI: পুনরুত্পাদনযোগ্য করুন

একটি হ্যান্ডঅফ তখনই সম্পূর্ণ যখন অন্য কেউ ক্লিন মেশিনে স্ক্র্যাচ থেকে অ্যাপটি পুনর্নির্মাণ করতে পারে। আপনার সোর্স কোড হ্যান্ডঅফ চেকলিস্টে সঠিক বিল্ড কমান্ড, প্রয়োজনীয় সংস্করণ, এবং প্রত্যাশিত আউটপুট (উদাহরণ: “ওয়েব বান্ডল /dist-এ”, “API বাইনারি নাম”, “Flutter APK লোকেশন”) থাকতে হবে।

যে টুল ও প্যাকেজ ম্যানেজারগুলো আপনি বাস্তবে ব্যবহার করেন সেগুলো লিখে রাখুন। একটি সাধারণ স্ট্যাকের জন্য এটি হতে পারে Node.js (npm বা pnpm) একটি React ওয়েব অ্যাপের জন্য, Go টুলচেইন সার্ভারের জন্য, PostgreSQL ক্লায়েন্ট টুল লোকাল সেটআপের জন্য, এবং Flutter SDK মোবাইলের জন্য।

ডিপেনডেন্সি ইনস্টল predictable করুন। নিশ্চিত করুন লকফাইলগুলো (package-lock.json, pnpm-lock.yaml, go.sum, pubspec.lock) কমিট করা আছে এবং একটি নতুন কম্পিউটার বা ক্লিন কন্টেইনারে fresh install করে প্রমাণ করুন এটি কাজ করে।

CI কী করে তা ধাপে ধাপে ক্যাপচার করুন যাতে প্রয়োজনে অন্য CI প্রোভাইডারে কপি করা যায়:

• ডিপেনডেন্সি ইনস্টল (লকফাইলসহ)
• টেস্ট ও লিন্ট চালান
• বিল্ড আউটপুট (ওয়েব বান্ডল, সার্ভার বাইনারি, মোবাইল বিল্ড)
• আর্টিফ্যাক্ট তৈরি (zip, Docker ইমেজ, রিলিজ বান্ডেল)
• লগ ও বিল্ড মেটাডাটা স্টোর করা (ভার্সন, কমিট, তারিখ)

বিল্ড-টাইম কনফিগ এবং রানটাইম কনফিগ আলাদা রাখুন। বিল্ড-টাইম কনফিগ এমন জিনিস পরিবর্তন করে যা কম্পাইল হয় (যেমন API base URL ওয়েব বান্ডলে বেক করা), রানটাইম কনফিগ অ্যাপ শুরু হলে ইনজেক্ট করা হয় (যেমন ডাটাবেস URL, API কী, ফিচার ফ্ল্যাগ)। এগুলো মিশে গেলে প্রায়ই "CI তে চলে কিন্তু ডিপ্লয়ের পরে ব্যর্থ হয়" সমস্যা দেখা যায়।

সরল লোকাল যাচাই রেসিপি দিন। এমনকি কমান্ডগুলোর সংক্ষিপ্ত সেটই যথেষ্ট:

# Web
pnpm install
pnpm test
pnpm build

# API
go test ./...
go build ./cmd/server

# Mobile
flutter pub get
flutter test
flutter build apk

আপনি যদি Koder.ai থেকে এক্সপোর্ট করেন, জেনারেটেড CI ফাইল বা বিল্ড প্রিসেট যেগুলো ডিপ্লয়ের সময় ব্যবহার করা হয়েছে সেগুলো অন্তর্ভুক্ত করুন যাতে ক্লায়েন্ট প্ল্যাটফর্মের বাইরে একই বিল্ড পুনরুত্পাদন করতে পারে।

ডিপ্লয়মেন্ট স্ক্রিপ্ট ও রিলিজ প্রসেস

একটি ভাল সোর্স কোড হ্যান্ডঅফ চেকলিস্ট কেবল "এখানে রিপো আছে" এ থামে না। এটি বোঝায় কীভাবে সোর্স কোড থেকে একটি চলমান সার্ভিস তৈরি হয়, এবং কে বাটনটি দেবে।

শুরু করুন বর্তমান ডিপ্লয়মেন্ট কিভাবে হচ্ছে তা লিখে: সম্পূর্ণ ম্যানুয়াল (কোনো ব্যক্তি সার্ভারে কমান্ড চালায়), CI-চালিত (পাইপলাইন বিল্ড ও ডিপ্লয় করে), বা হোস্টেড প্ল্যাটফর্মের মাধ্যমে। কোথায় কনফিগ থাকে এবং কোন কোন এনভায়রনমেন্ট আছে (dev, staging, production) জুড়ে লিখুন।

রিলিজ ধাপগুলো পুনরাবৃত্তিযোগ্য করুন। যদি প্রক্রিয়াটি কারো মনে ১২টি কমান্ড মনে রেখে করে, সেগুলোকে স্ক্রিপ্টে নিয়ে আসুন এবং কোন অনুমতি লাগবে তা নোট করুন।

ডিপ্লয়মেন্ট প্যাকেজে কি থাকবে

ক্লায়েন্টকে প্রথম দিনে ডিপ্লয় করার জন্য পর্যাপ্ত জন্য দেন:

• বিল্ড ও রান কমান্ড (এবং Node, Go, Flutter ইত্যাদির সঠিক সংস্করণ)
• ডিপ্লয়মেন্ট স্ক্রিপ্ট (শেল স্ক্রিপ্ট, Makefile টার্গেট, বা পাইপলাইন কনফিগ)
• প্রয়োজনীয় অ্যাক্সেস: ক্লাউড অ্যাকাউন্ট রোল, কনটেইনার রেজিস্ট্রি, DNS, ডাটাবেস অ্যাডমিন
• পরিবেশ সেটআপ নোট: কোথায় env vars সেট করা হয় এবং পরিবেশভেদে কিভাবে ভিন্ন
• রিলিজ নামকরণ: ট্যাগ/রিলিজ কিভাবে এবং কীভাবে চলমান ভার্সন চিহ্নিত করবেন

ডাউনটাইম প্রত্যাশা সংক্রান্ত একমত হন। যদি "জিরো ডাউনটাইম" প্রয়োজন হয়, বাস্তবে তা কি মানে (blue-green, rolling deploy, মাইগ্রেশন সময় read-only উইন্ডো) তা বলুন। যদি ডাউনটাইম গ্রহণযোগ্য হয়, একটি স্পষ্ট উইন্ডো নির্ধারণ করুন।

স্ট্যাটিক অ্যাসেট ও ক্যাশ সাধারণ ব্যর্থতার উৎস। উল্লেখ করুন কীভাবে অ্যাসেট বানানো ও সার্ভ করা হয়, কিভাবে ক্যাশ বুস্ট করা হয়, এবং CDN আছে কি না।

বাস্তবে চালানো যোগ্য রোলব্যাক

রোলব্যাক একটি সংক্ষিপ্ত, টেস্ট করা রেসিপি হওয়া উচিত যা একটি ট্যাগ বা রিলিজ আইডির সাথে যুক্ত। উদাহরণ: পূর্বের ট্যাগ ডিপ্লয় করুন, প্রয়োজনলে পূর্বের ডাটাবেস স্ন্যাপশট রিস্টোর করুন, এবং ক্যাশ ইনভ্যালিডেট করুন।

যদি অ্যাপটি Koder.ai তে তৈরি হয়ে এক্সপোর্ট করা হয়ে থাকে, শেষ পরিচিত ভাল স্ন্যাপশট এবং নির্দিষ্ট এক্সপোর্ট সংস্করণ উল্লেখ করুন যাতে ক্লায়েন্ট দ্রুত কোডকে একটি কাজ করা রিলিজের সাথে মিলাতে পারে।

ধাপে ধাপে: এক্সপোর্টের পরে বিল্ড যাচাই করুন

যাচাই হলো সেই মুহূর্ত যখন আপনি জানতে পারবেন হ্যান্ডঅফ বাস্তবে কাজ করে কি না। লক্ষ্য সহজ: একটি নতুন ব্যক্তি এক্সপোর্ট করা কোড নিয়ে সেটআপ করে অনুমান ছাড়াই একই অ্যাপ চালাতে পারে।

শুরু করার আগে "সঠিক" কেমন দেখায় তা রেকর্ড করুন: চলমান অ্যাপের ভার্সন, বর্তমান কমিট/ট্যাগ (যদি থাকে), এবং তুলনা করার জন্য এক বা দুইটি মূল স্ক্রিন বা API রেসপন্স। যদি এক্সপোর্টটি Koder.ai থেকে এসেছে, নোট করুন স্ন্যাপশট বা এক্সপোর্ট টাইমস্ট্যাম্প যাতে প্রমাণ থাকে যে আপনি সর্বশেষ স্টেট পরীক্ষা করেছেন।

1. এক্সপোর্ট প্রোডাকশনের সাথে মেলে কি না নিশ্চিত করুন: কমিট ইতিহাস, রিলিজ নোট, বা বিল্ড মেটাডাটা চেক করুন। চলমান অ্যাপের একটি দৃশ্যমান ভার্সন স্ট্রিং বা ছোট আচরণ মিলিয়ে দেখুন।
2. পরিবেশ ভেরিয়েবল ও সিক্রেট সেট করুন: টার্গেট এনভায়রনমেন্ট কনফিগ তৈরি করুন (লোকাল ও staging)। প্রদানকৃত env var ইনভেন্টরি ব্যবহার করে নিশ্চিত করুন রেপোতে কড়ি-কোড করা কোনো মান নেই।
3. ডিপেনডেন্সি ইন্সটল ও টেস্ট রান করুন: ক্লিন ইন্সটল (না_cached node_modules/vendor ফোল্ডার)। ইউনিট টেস্ট ও লিন্ট সঠিকভাবে চালান যেমন ডকস বলে।
4. মাইগ্রেশন চালান ও লোকাল চালু করুন: ডাটাবেস স্পিন আপ করুন, মাইগ্রেশনগুলো অর্ডারে প্রয়োগ করুন, এবং অ্যাপ চালু করুন। নিশ্চিত করুন অ্যাপ মূল ডেটা লিখে/পড়তে পারে এবং কোনো পেন্ডিং মাইগ্রেশন নেই।
5. স্টেজিং-এ ডিপ্লয় করুন, স্মোক টেস্ট করুন, তারপর প্রমোট করুন: একই স্ক্রিপ্ট/পাইপলাইন ব্যবহার করে ডিপ্লয় করুন যেটা প্রোডাকশনে ব্যবহার করবেন। স্টেজিং আপেক্ষিত হলে প্রমোট করুন।

স্মোক টেস্টগুলো সংক্ষিপ্ত ও ঝুঁকির সাথে সংযুক্ত রাখুন:

• লোগইন/লগআউট (বা একটি টেস্ট ইউজার তৈরি)
• একটি কোর ওয়ার্কফ্লো end-to-end (create-edit-save)
• একটি ইমেইল/ওয়েবহুক/পেমেন্ট কলব্যাক যদি প্রযোজ্য
• বেসিক এরর হ্যান্ডলিং (খারাপ ইনপুট, মিসিং রেকর্ড)
• লগগুলোতে ক্রমাগত ক্র্যাশ বা সিক্রেট-সংক্রান্ত ত্রুটি নেই

কিছু ফেল করলে, সঠিক কমান্ড, এরর আউটপুট, এবং ব্যবহার করা env vars লিখে রাখুন। এই বিশদকরণ মালিকানা বদলালে ঘন্টার পরিবর্তে ঘণ্টা বাঁচায়।

সাধারণ হ্যান্ডঅফ ভুলগুলো এবং কিভাবে তা এড়াবেন

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

যেসব ভুলগুলো অধিকাংশ হেডেক তৈরি করে

অধিকাংশ সমস্যা কিছুই নয় কিছুলোকাল প্যাটার্নে পড়ে:

• সিক্রেটগুলো রোটেট করা হয়নি, তাই পুরনো এজেন্সি পাসওয়ার্ড, API কী, বা ক্লাউড টোকেন হ্যান্ডওভারের পরেও কাজ করে থাকে।
• পরিবেশ ভেরিয়েবল অসম্পূর্ণ, কারণ কিছু মান কেবল CI সেটিংস বা হোস্টিং ড্যাশবোর্ডে আছেএবং রিপোতে নেই।
• এক-অফ প্রোডাকশন পরিবর্তনগুলো ভুলে যায়, যেমন একটি হটফিক্স, ম্যানুয়াল DB এডিট, বা সার্ভারে সরাসরি সেট করা কনফিগ টগল।
• ডাটাবেস মাইগ্রেশন লোকালে কাজ করে কিন্তু প্রোডাকশনে ব্যর্থ হয় কারণ পারমিশন, এক্সটেনশন, বা স্কিমা মালিকানা মিসিং।
• কোন রোলব্যাক প্ল্যান নেই, এবং কোন ট্যাগ/রিলিজ নোট নেই যাতে প্রথম ডিপ্লয় বিকল হলে ফিরে যাওয়া যায়।

কিভাবে এগুলো প্রতিরোধ করবেন (সপ্তাহ যোগ না করে)

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

env vars জন্য একটি সহজ ইনভেন্টরি নিন তিন জায়গা থেকে: রিপো, CI সিস্টেম, এবং হোস্টিং UI। তারপর একটি ক্লিন মেশিন বা কন্টেইনারে একটি ক্লিন বিল্ড চালিয়ে এটি যাচাই করুন।

মাইগ্রেশনগুলো প্রোডাকশনের সাথে একই ডাটাবেস রোল দিয়ে টেস্ট করুন। যদি প্রোডাকশনে উন্নত ধাপ দরকার (যেমন একটি এক্সটেনশন সক্ষম করা), সেগুলো লিখে দিন এবং মালিকানা স্পষ্ট করুন।

বাস্তব উদাহরণ: Koder.ai থেকে প্রজেক্ট এক্সপোর্ট করার পরে ক্লায়েন্ট ডিপ্লয় সফল হলেও ব্যাকগ্রাউন্ড জব ব্যর্থ করে কারণ একটি কিউ URL কেবল হোস্টিং ড্যাশবোর্ডে সেট ছিল। একটি সহজ env var অডিট এটা ধরত। এটিকে একটি ট্যাগড রিলিজ ও ডকুমেন্টেড রোলব্যাক (উদাহরণ: "ট্যাগ v1.8.2 পুনরায় ডিপ্লয় করুন এবং শেষ স্ন্যাপশট রিস্টোর করুন") সহ রাখলে টিম ডাউনটাইম এড়াতে পারে।

চূড়ান্ত চেকলিস্ট, একটি সহজ উদাহরণ, এবং পরবর্তী ধাপ

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

দ্রুত চেকগুলো (একটি fresh clone থেকে করুন)

নিচেরগুলো এমন একটি ল্যাপটপে চালান যা কখনই প্রজেক্টটি দেখেনি (অথবা একটি ক্লিন কন্টেইনার/VM)। এটি দ্রুততম উপায় মিসিং ফাইল, গোপন অনুমান, ও পুরনো ক্রেডেনশিয়াল ধরার।

• স্ক্র্যাচ থেকে বিল্ড: ডিপেনডেন্সি ইন্সটল করুন, টেস্ট চালান (যদি থাকে), এবং কোনো ম্যানুয়াল এডিট ছাড়াই রিলিজ বিল্ড তৈরি করুন।
• কনফিগ কাজ করে: ডকুমেন্টেড env ভেরিয়েবলগুলো সেট করে নিশ্চিত করুন অ্যাপ একটি fresh কনফিগ বা env সেটআপে বুট করে।
• সিক্রেট রোটেট হয়েছে: অ্যাপ নতুন কী নিয়ে চলে কিনা যাচাই করুন, তারপর পুরনো কী রিভোক করে কিছু ভাঙে না তা নিশ্চিত করুন।
• মাইগ্রেশন ক্লিন চলে: একটি খালি ডাটাবেস দিয়ে শুরু করে, মাইগ্রেশন চালান, তারপর অ্যাপ স্টার্ট করে একটি বেসিক ফ্লো হিট করুন।
• ডিপ্লয়মেন্ট পথ বাস্তব: একবার ডিপ্লয়মেন্ট স্ক্রিপ্ট বা CI ওয়ার্কফ্লো চালিয়ে দেখুন এটি একই আউটপুট produce করে।

একটি সহজ হ্যান্ডঅফ উদাহরণ

একটি এজেন্সি একটি React ফ্রণ্টএন্ড, একটি Go API, এবং একটি PostgreSQL ডাটাবেস হ্যান্ডঅফ করে। ক্লায়েন্ট টিম রিপো ক্লোন করে, প্রদত্ত .env.example থেকে বাস্তব env মান কপি করে, এবং ডাটাবেস, ইমেইল প্রোভাইডার, ও তৃতীয় পক্ষের API এর জন্য নতুন ক্রেডেনশিয়াল তৈরী করে। তারা go test (অথবা সম্মত টেস্ট কমান্ড) চালায়, React অ্যাপ বিল্ড করে, একটি নতুন Postgres ইনস্ট্যান্সে মাইগ্রেশন প্রয়োগ করে, এবং উভয় সার্ভিস চালু করে। শেষে, তারা ডকুমেন্টেড স্ক্রিপ্ট ব্যবহার করে ডিপ্লয় করে এবং একই কমিট পরে পুনরায় তৈরি করা যাবে তা নিশ্চিত করে।

পরবর্তী ধাপ

হ্যান্ডঅফ সংক্ষিপ্ত ও পরিষ্কার রাখুন। ৩০–৬০ মিনিটের ওকথা সাধারণত লম্বা ডকুমেন্টের চেয়ে বেশি কার্যকর।

• একটি ওকথা সাজান এবং সিদ্ধান্তগুলো রেকর্ড করুন (কে ডিপ্লয়, সিক্রেট, এবং ডাটাবেস পরিবর্তনের মালিক)
• প্রোডাকশনের জন্য একজন মালিক এবং একজন ব্যাকআপ নির্ধারণ করুন
• একটি চূড়ান্ত "অ্যাকসেপ্টেন্স বিল্ড" কমিট হ্যাশ ট্যাগ করুন
• যদি আপনি Koder.ai এ তৈরি করে থাকেন, সোর্স কোড এক্সপোর্ট করুন, তারপর ক্লায়েন্ট-চালিত প্রথম ডিপ্লয়ে স্ন্যাপশট ও রোলব্যাক ব্যবহার করে ঝুঁকি কমান