vibe-coding প্ল্যাটফর্ম থেকে সোর্স কোড কিভাবে পরিষ্কারভাবে রপ্তানি করবেন এবং সম্পূর্ণ মালিকানা নেবেন: লোকালি চালানো, CI সেটআপ, সিক্রেট ম্যানেজমেন্ট, এবং হ্যান্ডঅফ-রেডি রেপো প্রস্তুত করা।

কোডের মালিক হওয়া মানে শুধু প্ল্যাটফর্ম থেকে একটি zip ফাইল পাওয়া নয়। এর মানে আপনি এমনভাবে বিল্ড, চালানো, পরিবর্তন ও ডিপ্লয় করতে পারবেন যাতে আপনার আর মূল ওয়ার্কস্পেস, বিশেষ বোতাম বা লুকানো সেটিংসের ওপর নির্ভর করার দরকার নেই। একটি প্রকল্প যা আপনি সত্যিই মালিকানাধীন, সেটি যেকোনো সাধারণ রেপোর মতো আচরণ করে: একজন নতুন সহকর্মী সেটি ক্লোন করে ল্যাপটপে চালাতে পারে এবং একটি স্ট্যান্ডার্ড পাইপলাইনের মাধ্যমে ডিপ্লয় করতে পারে।
বেশিরভাগ লক-ইন উদ্বেগ একই কয়েকটি ফাঁক থেকে আসে:
আরেকটি সাধারণ অবাক করা বিষয় হল হোস্টেড ভার্সনে অ্যাপ ঠিকভাবে চলে কিন্তু লোকালভাবে কাজ করে না, কারণ পরিবেশ ভ্যারিয়েবল, ডাটাবেস সেটআপ বা সিক্রেটগুলো স্পষ্ট করা হয়নি।
একটি পরিষ্কার এক্সপোর্ট থেকে আপনি চারটি ফলাফল আশা করতে পারেন:
এটি এমনকি তখনও গুরুত্বপূর্ণ যদি আপনি কখনো প্ল্যাটফর্ম ছেড়ে যাওয়ার পরিকল্পনা না করে থাকেন। একটি শক্তিশালী মালিকানা মনোভাব ঝুঁকি কমায়, অডিট সহজ করে এবং যদি আপনি কোনো এজেন্সি নিয়োগ করেন, ফান্ড সংগ্রহ করেন বা টিম পরিবর্তন করেন তো আলোচনা সহজ রাখে।
আপনি যদি Koder.ai ব্যবহার করে থাকেন, আপনার এক্সপোর্টে সাধারণ স্ট্যাক থাকতে পারে—যেমন React ওয়েব অ্যাপ, একটি Go ব্যাকএন্ড, PostgreSQL, বা একটি Flutter মোবাইল অ্যাপ। স্ট্যাক যতই হোক না কেন মূল নীতি একই: চালানোর জন্য যা যা দরকার সবই রিপোজিটরিতে দৃশ্যমান থাকা উচিত, হোস্টেড পরিবেশে আটকে থাকা উচিত নয়।
কল্পনা করুন একজন প্রতিষ্ঠাতাকে যখন একজন কন্ট্রাকটরকে অ্যাপ হস্তান্তর করছেন। “এখানে রেপো” বলে দেওয়াই যথেষ্ট হওয়া উচিত। কন্ট্রাকটরকে মূল প্ল্যাটফর্ম প্রজেক্টে অ্যাক্সেস নিয়ে API বেস URL খুঁজতে, ডাটাবেস স্কিমা তৈরি করতে বা ফ্রন্টএন্ড কিভাবে বিল্ড করতে হয় সেটি জানতে হওয়া উচিত নয়।
এক্সপোর্টের পরে আপনার কাছে একটি সাধারণ রেপোজিটরি থাকা উচিত যা আপনি এডিটরে খুলতে, ল্যাপটপে চালাতে এবং মূল প্ল্যাটফর্ম ছাড়া অন্য টিমকে হস্তান্তর করতে পারবেন।
Koder.ai প্রজেক্টের ক্ষেত্রে, এক্সপোর্টগুলো প্রায়ই পরিচিত স্ট্রাকচারের সঙ্গে মেলে: একটি React ওয়েব অ্যাপ, একটি Go ব্যাকএন্ড, এবং (যদি তৈরি করা হয়ে থাকে) একটি Flutter মোবাইল অ্যাপ। ফোল্ডার নাম ভিন্ন হতে পারে, কিন্তু রেপোটি সহজেই বোঝাতে হবে প্রতিটি অংশ কোথায় আছে এবং তারা কীভাবে সংযুক্ত।
প্রতিটি অংশের এন্ট্রি পয়েন্ট এবং ইচ্ছাকৃত ওয়ার্কফ্লোটি খুঁজে বের করা দিয়ে শুরু করুন। আপনি প্রতিটি অ্যাপ চালু করার প্রথম ফাইলটি চাইবেন, প্লাস সেই স্ক্রিপ্টগুলো যা দেখায় কিভাবে ডেভেলপ ও চালাতে হবে।
সাধারণ লক্ষণগুলো:
package.json প্লাস src/ ফোল্ডার (প্রায়ই main.tsx বা সমতুল্য)go.mod এবং একটি cmd/ ফোল্ডার বা main.gopubspec.yaml এবং lib/main.dartREADME বা Makefile যা সবকিছু চালানোর পদ্ধতি বর্ণনা করেdocker-compose.ymlডিপেন্ডেন্সিগুলো পিন করা থাকা উচিত। JavaScript-এর ক্ষেত্রে এর মানে হলো একটি লকফাইল (package-lock.json, yarn.lock, বা pnpm-lock.yaml)। Go-র ক্ষেত্রে go.mod এবং go.sum থাকা উচিত। পিন না থাকলে প্রজেক্ট চালানো অসম্ভব হবে না, কিন্তু রিপিটেবল বিল্ড কঠিন হয়ে যায়।
কনফিগারেশন কোড থেকে আলাদা থাকা উচিত। .env.example বা config.example.yaml মত উদাহরণ খুঁজুন। এক্সপোর্টে আসল সিক্রেট (API কী, প্রোডাকশন পাসওয়ার্ড) না থাকা উচিত। যদি থাকে, সেটিকে লিক হিসেবে গণ্য করুন এবং তা রোটেট করুন।
ডাটাবেসের জন্য, একটি মাইগ্রেশন ফোল্ডার (migrations/, db/migrations/) অথবা টাইমস্ট্যাম্প সহ SQL ফাইল খুঁজুন। Go + PostgreSQL অ্যাপে আপনি হয়তো একটি ছোট মাইগ্রেশন রাননার বা মাইগ্রেশন চালানোর স্ক্রিপ্টও দেখতে পাবেন।
একটি দ্রুত স্যানিটি চেক: প্রথমে বিল্ড এবং রান কমান্ডগুলো খুঁজে বের করুন (npm run dev, go run, make, ইত্যাদি)। যদি কোনো স্ক্রিপ্ট প্ল্যাটফর্ম-নির্দিষ্ট কমান্ডের ওপর নির্ভর করে, রিপোকে স্বাধীন ঘোষণা করার আগে সেটিকে স্ট্যান্ডার্ড টুলিং দিয়ে প্রতিস্থাপিত করুন।
এক্সপোর্টকে একটি রিলিজ আর্টিফ্যাক্ট হিসেবে আচরণ করুন। কিছু চালানোর আগে দ্রুত একটি “সব কিছু আছে?” পাস করুন। অনুপস্থিতি ধরা পড়া শুরুতেই সহজ; পরে চেঞ্জ করার পরে তল্লাশ করা কঠিন।
একটি ব্যবহারিক পূর্ণতার চেক হলো প্রতিটি অংশের “রুট” খুঁজে বের করা: React ওয়েবের জন্য package.json, Go ব্যাকএন্ডের জন্য go.mod, এবং PostgreSQL-এর জন্য মাইগ্রেশন/সিড ফাইল।
এক্সপোর্ট করা ফোল্ডার থেকে একটি নতুন Git রেপো তৈরি করুন, তারপর ঠিক যা পেয়েছেন ঠিক তা কমিট করুন আগে কোনো পরিবর্তন না করেই। এতে একটি পরিষ্কার বেসলাইন হয় এবং পরে পরিবর্তন রিভিউ করা সহজ হয়।
git init
# Optional: set default branch name
# git branch -M main
git add -A
git commit -m "Initial export"
এবার ছোট, যাচাইযোগ্য ধাপে লোকালি চালান। ডিপেন্ডেন্সি ইনস্টল করুন, লোকাল কনফিগ তৈরি করুন, প্রথমে ডাটাবেস চালু করুন, তারপর ব্যাকএন্ড, তারপর ফ্রন্টএন্ড। আপনি যতটুকু কমান্ড বাস্তবে ব্যবহার করছেন তা লিখে রাখুন। সেই নোটগুলো আপনার README হয়ে যাবে।
নীচে একটি সহজ কমান্ড সিকোয়েন্স যা আপনি আপনার এক্সপোর্টকৃত স্ট্রাকচারের সাথে মানিয়ে নিতে পারবেন:
# Frontend
cd web
npm install
npm run dev
# Backend
cd ../server
go mod download
go run ./cmd/server
একটি সার্ভার বুট করে গেলেও অ্যাপ এখনও ভাঙা থাকতে পারে। নিশ্চিত করুন এটি ডাটা পড়তে এবং লেখতে পারে।
পণ্য অনুযায়ী দ্রুত চেকগুলো বেছে নিন:
একবার আপনার কাছে একটি কাজ করা লোকাল রান থাকলে, আপনার খসড়া নোটটি একটি বাস্তব README.md এ পরিণত করুন: কোথা থেকে কোন কমান্ড চালাতে হবে, সার্ভিসগুলো কোন ক্রমে চালু করতে হবে, এবং কোন পরিবেশ ভ্যারিয়েবল প্রয়োজন।
একটি এক্সপোর্ট চালু হতে পারে, কিন্তু তবু “জেনারেটেড” মনে হতে পারে পরিবর্তে মালিকানাধীন। একটি হ্যান্ডঅফ-রেডি রেপো স্পষ্ট করে দেয় কোথায় জায়গাগুলো আছে, কিভাবে চালাতে হবে, এবং কিভাবে কনসিস্টেন্সি বজায় রাখা যায়।
একটি পরিষ্কার টপ-লেভেল লেআউট দিয়ে শুরু করুন। নামগুলো কনসিস্টেন্সির চেয়ে বেশি গুরুত্বপূর্ণ নয়।
apps/ ব্যবহারকারীর সামনের অংশের জন্য (web, mobile)services/ ব্যাকএন্ড API, ওয়ার্কার এবং কাজের জন্যshared/ শেয়ার্ড টাইপস এবং ইউটিলিটি জন্যinfra/ ডিপ্লয়মেন্ট টেমপ্লেট, স্ক্রিপ্ট এবং এনভায়রনমেন্ট উদাহরণের জন্যdocs/ আর্কিটেকচার নোট এবং রানবুকের জন্যতারপর কিছু ছোট ফাইল যুক্ত করুন যা অনুমান কমায়:
README.md প্রয়োজনীয়তা এবং সঠিক কমান্ডসহCONTRIBUTING.md কয়েকটি নিয়ম (ব্রাঞ্চ, PR, কোন সিক্রেট জমা করবেন না).gitignore লোকাল env ফাইল এবং বিল্ড আউটপুট Git-এ যেতে না দেওয়ার জন্যREADME-কে ব্যবহারিক রাখুন। যদি রেপোতে একাধিক অংশ থাকে (React ফ্রন্টএন্ড, Go API, PostgreSQL), তাহলে চালু করার ক্রম এবং কনফিগ কোথায় থাকে তা স্পষ্টভাবে লিখুন (উদাহরণ: “.env.example কপি করে .env তৈরি করুন”)।
একটি নতুন মেশিন চেক করুন: একটি নতুন ফোল্ডারে ক্লোন করে আপনার README অনুসরণ করুন। আপনি যদি Koder.ai থেকে এক্সপোর্ট করে থাকেন, এক্সপোর্টটিকে একটি নতুন স্বাধীন প্রজেক্টের প্রথম কমিট হিসেবে বিবেচনা করুন, এবং তবেই অন্যদের আমন্ত্রণ জানান।
একটি ভালো লোকাল সেটআপ এক প্রশ্ন দ্রুত করে উত্তর দেয়: কি একটি নতুন মানুষ ১৫ মিনিটের মধ্যে অ্যাপ চালাতে পারে কি না, অনুমান ছাড়াই।
একটি ডিফল্ট লোকাল পন্থা বেছে নিন এবং স্পষ্ট হন। কাঁঠামাটির ইনস্টল দ্রুত তাদের জন্য যারা সঠিক টুল আছে। কন্টেইনারগুলি মেশিন জুড়ে বেশি কনসিস্টেন্ট কিন্তু ওভারহেড যোগ করে। আপনি দুইটিই সাপোর্ট করলে একটিকে ডিফল্ট এবং অন্যটিকে অপশনাল হিসেবে লেবেল করুন।
একটি সাধারণ প্যাটার্ন: একটি README পৃষ্ঠা, একটি স্যাম্পল env ফাইল, এবং একটি বুটস্ট্র্যাপ কমান্ড।
নকল মান সহ একটি উদাহরণ ফাইল কমিট করুন যাতে লোকেরা কী সেট করতে হবে জানে কিন্তু সিক্রেট ফাঁস না হয়।
# .env.example (example values only)
APP_ENV=local
PORT=8080
DATABASE_URL=postgres://app_user:app_pass@localhost:5432/app_db?sslmode=disable
JWT_SECRET=change-me
API_BASE_URL=http://localhost:8080
README-এ ব্যাখ্যা করুন আসল ফাইল কোথায় থাকবে (উদাহরণ: “.env.example কপি করে .env তৈরি করুন”) এবং কোন ভ্যারিয়েবলগুলি বাধ্যতামূলক বনাম ঐচ্ছিক।
একটি ছোট স্ক্রিপ্ট যোগ করুন যা সঠিক ক্রমে বিরক্তিকর ধাপগুলো চালায়। এটির পাঠযোগ্যতা রাখুন।
#!/usr/bin/env bash
set -euo pipefail
cp -n .env.example .env || true
# Backend deps
cd backend
go mod download
# Database: create, migrate, seed
./scripts/db_create.sh
./scripts/db_migrate.sh
./scripts/db_seed.sh
# Frontend deps
cd ../web
npm install
ডাটাবেস পরিকল্পনার জন্য তিনটি জিনিস ডকুমেন্ট করুন: কিভাবে DB তৈরি করবেন, কিভাবে মাইগ্রেশন চলবে, এবং কিভাবে রিয়ালিস্টিক প্রথম রানের জন্য সিড ডাটা পাবেন।
অবশেষে, একটি দ্রুত হেলথ চেক যোগ করুন যাতে লোকেরা ক্লিক করার আগে অ্যাপ কাজ করছে কি না নিশ্চিত করতে পারে। একটি ছোট endpoint যেমন GET /health যা "ok" ফেরত দেয় (এবং ডাটাবেস সংযোগ যাচাই করে) প্রায়ই যথেষ্ট।
আপনি যখন একটি প্রজেক্ট এক্সপোর্ট করেন, কোড হয়তো আপনার, কিন্তু সিক্রেটগুলো ব্যক্তিগত থাকা উচিত। ধরে নিন রেপোটি নতুন সহকর্মীদের সাথে শেয়ার করা হবে।
প্রথমে তালিকা করুন অ্যাপটি চালাতে কী কী দরকার। অনুমান করবেন না। কোড স্কিমিং করে কনফিগ পড়ার জায়গাগুলো (environment variables, config files) দেখুন এবং আপনি যে ইন্টিগ্রেশনগুলো এনাবল করেছেন সেগুলো চেক করুন।
একটি প্রাথমিক সিক্রেট ইনভেন্টরি সাধারণত অন্তর্ভুক্ত করে: ডাটাবেস ক্রেডেনশিয়াল, তৃতীয়-পক্ষ API কী, অথ সেটিংস (OAuth বা JWT), স্টোরেজ ক্রেডেনশিয়াল, এবং অ্যাপ-নির্দিষ্ট সিক্রেট যেমন এনক্রিপশন কী বা webhook সাইনিং সিক্রেট।
প্রতিটি পরিবেশে প্রতিটি সিক্রেট কোথায় থাকবে তা নির্ধারণ করুন। একটি ভালো ডিফল্ট নিয়ম:
.env (কমিট করবেন না)আপনি যদি Koder.ai মত একটি vibe-coding প্ল্যাটফর্ম থেকে এক্সপোর্ট করে থাকেন, মনে করুন চ্যাট, লগ বা সেটিং প্যানেলে দেখানো যেকোনো কিছু কপি হতে পারে। সিক্রেটগুলো রিপো থেকে তৎক্ষণাত সরান।
একটি ব্যবহারিক পন্থা হলো একটি নিরাপদ টেমপ্লেট কমিট করা (যেমন .env.example), সত্যিকারের মান Git-এ না রাখা (.env-কে .gitignore-এ যোগ করুন), এবং প্রোডাকশনে ডিপ্লয় সময় সিক্রেট ইনজেক্ট করা।
যদি এক্সপোর্টের সময় কোনো সিক্রেট ফাঁস হওয়ার সম্ভাবনা থাকে, সেগুলো রোটেট করুন। ডাটাবেস পাসওয়ার্ড, OAuth ক্লায়েন্ট সিক্রেট এবং webhook সাইনিং কী এগুলোকে অগ্রাধিকার দিন।
কয়েকটি গার্ডরেল যোগ করুন যাতে এটি আবার না ঘটে: স্পষ্ট সিক্রেট প্যাটার্নের জন্য pre-commit চেক, CI-তে সিক্রেট স্ক্যান, বাধ্যতামূলক ভেরিয়েবল না থাকলে দ্রুত ব্যর্থ করে দেওয়া কনফিগ লোডিং, এবং প্রতিটি পরিবেশের জন্য আলাদা ক্রেডেনশিয়াল।
একটি ছোট SECRETS.md হ্যান্ডঅফে সহায়ক। সহজ রাখুন: প্রয়োজনীয় ভ্যারিয়েবল, কোন পরিবেশে কোথায় রাখা হয়, এবং কে এগুলো রোটেট করতে পারে।
মালিকানা নেওয়ার পরে, CI আপনার সেফটি নেট। প্রথম ভার্সনটি ছোট রাখুন। প্রতিটি পুশে প্রজেক্টটি এখনো বিল্ড হয় কিনা, বেসিক চেক পার হয় কি না, এবং টেস্ট (যদি থাকে) চলতে পারে কি না—এগুলো প্রমাণ করা উচিত।
CI-কে এক প্রশ্ন দ্রুত উত্তর দিতে বলুন: "এই পরিবর্তনটি মার্জ করা নিরাপদ কি?" বেশিরভাগ রেপোর জন্য এর মানে হলো ডিপেন্ডেন্সি ইনস্টল করা, বিল্ড করা, লিন্ট করা, এবং ইউনিট টেস্ট চালানো।
জবগুলো অ্যাপ অংশ অনুযায়ী ভাগ করুন যাতে ব্যর্থতা স্পষ্ট হয়:
ক্যাশিং ব্যবহার করুন, কিন্তু ক্যাশ সমস্যাগুলো লুকিয়ে রাখুক না। ক্যাশ মিস হ’লেও CI কাজ করা উচিত, কেবল ধীর হবে।
প্রতি ধাপের জন্য একটি একক কমান্ড পছন্দ করুন (make test, npm run test, ইত্যাদি) যাতে একই কমান্ড লোকালি ও CI-তে কাজ করে। এটি বিভ্রান্তি কমায় এবং লগ ছোট রাখে।
উদাহরণ আকার (আপনার রেপো অনুযায়ী নাম সামঞ্জস্য করুন):
jobs:
web:
steps:
- run: npm ci
- run: npm run lint
- run: npm run build
api:
steps:
- run: go test ./...
- run: go build ./...
বেসিকগুলো স্থির হলে, একটি সাধারণ রিলিজ ফ্লো যোগ করুন: রিলিজ ট্যাগ করুন, আর্টিফ্যাক্ট বিল্ড করুন, এবং CI আর্টিফ্যাক্ট হিসেবে সংরক্ষণ করুন। এমনকি যদি আপনি এখনও প্ল্যাটফর্ম থেকে ডিপ্লয় করেন, রিপিটেবল আর্টিফ্যাক্ট ভবিষ্যতে হোস্ট পরিবর্তন সহজ করে।
কোড এক্সপোর্ট করা কাজের অর্ধেক। অন্য অর্ধেক হলো নিশ্চিত করা যে প্রজেক্টটি প্ল্যাটফর্মের বাইরে একইভাবে আচরণ করে।
এক্সপোর্টগুলো প্রায়ই environment variables, migrations, seed data, এবং বিল্ড স্টেপসের ওপর নির্ভর করে যা আপনার পক্ষে হ্যান্ডেল হয়েছে। প্রথম চালায় একটি খালি স্ক্রীন বা ডাটাবেস ত্রুটি স্বাভাবিক।
কোনো পরিবর্তন করার আগে একটি বেসলাইন রান করুন: deps ইনস্টল করুন, env vars সেট করুন, মাইগ্রেশন চালান, সার্ভিসগুলো সঠিক ক্রমে চালান। শুধুমাত্র দরকারি বদলগুলো ঠিক করুন যাতে প্রত্যাশিত সেটআপের সাথে ম্যাচ করে।
সবচেয়ে সাধারণ দুর্ঘটনা হলো আসল API কী বা পাসওয়ার্ড কমিট করা, সাধারণত .env কপি করে বা টুল-জেনারেটেড কনফিগের মাধ্যমে।
শুধু টেমপ্লেট কমিট করুন। আসল মান লোকাল এনভায়রনমেন্ট বা সিক্রেট স্টোরে রাখুন।
প্যাকেজ আপগ্রেড বা ফোল্ডার পুনর্গঠন করে ফেললে সমস্যা যে এক্সপোর্ট থেকেই নাকি আপনার পরিবর্তন থেকেই হয়েছে—তা বোঝা কঠিন হয়।
প্রথমে একটি কাজ করা রান নিশ্চিত করুন, তারপর ছোট, আলাদা কমিটে উন্নতি করুন।
"আমার মেশিনে চলে" প্রায়ই অপরিপক্ক টুল ভার্সনের (Node, Go, Flutter, এমনকি প্যাকেজ ম্যানেজার) কারণে ঘটে।
রানটাইম ভার্সন একটি স্পষ্ট জায়গায় পিন করুন (একটি ফাইল বা README), লকফাইল রাখুন (package-lock, go.sum, pubspec.lock), এবং সেটআপ একটি দ্বিতীয় মেশিনে বা একটি ফ্রেশ কন্টেইনারে যাচাই করুন।
হ্যান্ডঅফ ব্যর্থ হয় কারণ কেউ স্মরণ করে না কিভাবে অ্যাপ শুরু করতে হয় এমন একটি অদ্ভুত ধাপ। এটা তাজা অবস্থায় লিখে রাখুন: প্রয়োজনীয় env vars, মাইগ্রেশন কীভাবে চালাতে হয়, লগ কোথায় যায়, এবং লোকাল স্টেট রিসেট কিভাবে করা যায়।
তিন-জনের একটি টিম Koder.ai-তে একটি কাস্টমার পোর্টাল বানায়: একটি React ওয়েব অ্যাপ, একটি Go API, এবং একটি PostgreSQL ডাটাবেস। যখন এটি বাইরে একটি ডেভ টিমকে হস্তান্তর করার সময় আসে, তারা চায় এক্সপোর্টটি একটি সাধারণ রেপোর মতো অনুভব করুক যা কেউ ডে-ওয়ান-এ চালাতে পারে।
Day 1: তারা এক্সপোর্ট করে, একটি ফ্রেশ Git রেপো তৈরি করে, এবং লোকালি চালায়। ফ্রন্টএন্ড শুরু হয়, কিন্তু API ব্যর্থ করে কারণ পরিবেশ ভ্যারিয়েবলগুলি নেই। তারা অনুমান করে না। কোড পড়ে নির্দিষ্ট কীগুলো সনাক্ত করে এবং প্লেসহোল্ডার সহ একটি .env.example তৈরি করে। আসল মানগুলো পাসওয়ার্ড ম্যানেজারে এবং লোকাল .env ফাইলগুলিতে থাকে।
তারা এছাড়াও লক্ষ্য করে যে প্ল্যাটফর্মে পোর্ট এবং CORS সেটিংস ঠিক ছিল কিন্তু লোকালে ডিফল্ট দরকার। তারা পূর্বানুমানযোগ্য ডিফল্ট সেট করে (উদাহরণ: API 8080-এ এবং web 3000-এ) যাতে নতুন মেশিনগুলো একইভাবে আচরণ করে।
Day 2: তারা মাইগ্রেশন এবং একটি ছোট সিড স্ক্রিপ্ট যোগ করে যা একটি ডেমো ইউজার ও কয়েকটি সারি তৈরি করে। তারপর তারা একটি সংক্ষিপ্ত README লেখে যা প্রয়োজনীয়তা, চালানোর কমান্ড, এবং কিভাবে যাচাই করা যায় তা কভার করে (API-এর জন্য একটি হেলথ এন্ডপয়েন্ট এবং UI-র জন্য একটি স্যাম্পল লগইন)।
Day 3: তারা একটি বেসিক CI ওয়ার্কফ্লো যোগ করে যা প্রতিটি পুল রিকুয়েস্টে উভয় সার্ভিসের টেস্ট, লিন্টিং, এবং বিল্ড চালায়। স্টেজিংয়ের জন্য তারা একটি সরল পরিকল্পনা ডকুমেন্ট করে: কনটেইনার বিল্ড করা, এনভায়রনমেন্টে সিক্রেট সেট করা, ডিপ্লয়-এ মাইগ্রেশন চালানো, এবং একটি রোলব্যাক অপশন রাখা।
একটি ভাল হ্যান্ডঅফ সাধারণত এমন একটি রেপো নিয়ে আসে যা ফ্রেশ ক্লোন থেকে লোকালি চলে, .env.example ও সিক্রেট কোথায় আছে তার নোট, মাইগ্রেশন ও সিড ডাটা, CI চেক যা দ্রুত ব্যর্থ করে, এবং স্টেজিং ও রোলব্যাকের জন্য একটি সংক্ষিপ্ত ডিপ্লয় নোট।
এক্সপোর্টটি সম্পন্ন বলে ডাকার আগে প্রমাণ করুন প্রজেক্টটি প্ল্যাটফর্মের বাইরে থাকা সক্ষম। যদি আরেকজন ডেভ লোকালভাবে অনুমান ছাড়াই চালাতে পারে, আপনি ভালো অবস্থায় আছেন।
চূড়ান্ত চেকলিস্ট ব্যবহার করুন:
প্রযুক্তিগত চেকের পরে মালিকানা স্পষ্ট করুন। নির্ধারণ করুন কে ডিপেন্ডেন্সি আপডেট, অবকাঠামো পরিবর্তন (ডাটাবেস, কিউ, DNS), এবং রিলিজের দায়িত্ব নেবে। যদি কেউ এগুলো দায়িত্ব না নেয়, রেপো ধীরে ধীরে বার্ধক্যর্ত হবে যদিও আজ অ্যাপ কাজ করে।
প্রধান ফিচার কাজ শুরু করার আগে একটি সংক্ষিপ্ত স্থিতিশীলকরণ উইন্ডো পরিকল্পনা করুন। ২–৫ কার্যদিবস প্রায়ই যথেষ্ট হয় এক্সপোর্টের খুঁতগুলো ঠিক করতে, README মজবুত করতে, এবং "আমার মেশিনে চলে" সমস্যা দূর করতে।
আপনি যদি Koder.ai (koder.ai) ব্যবহার করে থাকেন, এক্সপোর্টগুলো প্লাস স্ন্যাপশট ও রোলব্যাকের মত ফিচার আপনাকে রিপো শক্ত করার সময় পুনরাবৃত্তি সহজ করে। একবার রেপো স্থির হলে, Git-কে সৃত্রু সত্য হিসেবে বিবেচনা করুন এবং ভবিষ্যতের এক্সপোর্টগুলোকে কেবল চেকপয়েন্ট হিসেবে ধরুন, প্রধান হিস্ট্রি হিসেবে নয়।
পরবর্তী হ্যান্ডঅফ মাইলস্টোন সাদাসিধা ভাষায় নির্ধারণ করুন: "কোনো ডেভেলপার ৩০ মিনিটে এটি চালাতে পারবে।" তারপর একজন নতুনকে ছোট করে README অনুসরণ করতে বলুন। তাদের প্রশ্নগুলো আপনার চূড়ান্ত টু-ডু লিস্ট হবে।
Treat ownership as independence: you can build, run, change, and deploy the app from a normal repo without needing the original platform project, special UI settings, or hidden build steps.
A good test is: can a new teammate clone the repo and get it running using only the README?
Start with a quick completeness check:
package.json, go.mod, pubspec.yaml).package-lock.json, yarn.lock, pnpm-lock.yaml, go.sum).migrations/ or similar).docker-compose.yml).If anything required to run is only described in a UI or chat, write it down and move it into the repo.
Do it in small, verifiable steps:
.env.example → .env.Don’t refactor immediately—first prove it runs as-is, then improve it in separate commits.
Because the hosted environment often had things you never made explicit:
Fix this by making the setup visible: .env.example, migration scripts, and a README with exact commands.
A server “starting” isn’t enough—verify real data flow:
If you can’t reliably reproduce data changes locally, your setup or migrations are incomplete.
Default approach:
.env.example with fake values..env to .gitignore.If you find real keys in the repo, assume they’re compromised and rotate them. Prioritize database credentials, OAuth client secrets, and webhook signing secrets.
Keep the first CI simple and consistent with local commands:
go test ./... and build the backend.Make CI call the same scripts you expect developers to run (for example make test or npm run build). That reduces “works locally but not in CI.”
Yes—if you want a predictable handoff. A good default is:
README.md with copy-paste commands..env.example describing required vs optional variables.Aim for a new developer being able to run the app in 15–30 minutes without guessing.
Common structure is:
apps/ for frontends (web, mobile).services/ for APIs and workers.shared/ for shared types/utilities.infra/ for deployment templates and environment examples.The exact names don’t matter as much as making it obvious what runs where, and how the pieces connect.
A practical sequence:
Once stable, treat Git as the source of truth and any future platform exports as checkpoints, not the primary history.