১০ ডিসে, ২০২৫·6 মিনিট

vibe-coding প্ল্যাটফর্ম থেকে সোর্স কোড পরিষ্কারভাবে রপ্তানি করুন

Q: What does “taking ownership” actually mean after I export the code?

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?

Q: What should I check first to see if an export is complete?

Start with a quick completeness check: - Find each app “root” ( , , ). - Confirm there’s a lockfile ( , , , ). - Look for database migrations ( or similar). - Check for a runnable workflow (README, Makefile, scripts, or ). If anything required to run is only described in a UI or chat, write it down and move it into the repo.

Q: What’s the safest way to get an exported project running locally?

Do it in small, verifiable steps: 1. Initialize Git and commit the raw export (baseline). 2. Set up local config using → . 3. Start the database. 4. Run migrations. 5. Start the backend. 6. Start the frontend. Don’t refactor immediately—first prove it runs as-is, then improve it in separate commits.

Q: How do I confirm the database part actually works after export?

A server “starting” isn’t enough—verify real data flow: - Load a page that clearly depends on database reads. - Create a record, refresh, and confirm it persisted. - Do one update and one delete if possible. - Watch logs for migration issues like “relation does not exist.” If you can’t reliably reproduce data changes locally, your setup or migrations are incomplete.

Q: How should I handle secrets so I don’t leak API keys in Git?

Default approach: - Commit with fake values. - Add to . - Store real secrets in a password manager or a secret store. 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.

Q: Do I really need a README and bootstrap script if the app already runs?

Yes—if you want a predictable handoff. A good default is: - A single top-level with copy-paste commands. - A describing required vs optional variables. - One bootstrap command/script to install deps and prepare the DB. Aim for a new developer being able to run the app in 15–30 minutes without guessing.

Q: How should I organize an exported repo (web + API + database) so it’s easy to maintain?

Common structure is: - for frontends (web, mobile). - for APIs and workers. - for shared types/utilities. - 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.

Q: What’s a good “next steps” plan after exporting from Koder.ai?

A practical sequence: 1. Export and commit the baseline. 2. Make it run locally with explicit config, migrations, and a clear README. 3. Add CI to keep builds and tests from silently breaking. 4. Add a simple deploy note (how to set secrets, run migrations, rollback). Once stable, treat Git as the source of truth and any future platform exports as checkpoints, not the primary history.

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

রপ্তানির পর মালিকানা নেওয়ার মানে কী

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

বেশিরভাগ লক-ইন উদ্বেগ একই কয়েকটি ফাঁক থেকে আসে:

কনফিগারেশন যা কেবল প্ল্যাটফর্ম UI-তে আছে
বিল্ড স্টেপস যা “কোথাও অন্যত্র” ঘটে
ডিপেন্ডেন্সি যা অনুমান করা হয়েছে কিন্তু লিখে রাখা হয়নি

আরেকটি সাধারণ অবাক করা বিষয় হল হোস্টেড ভার্সনে অ্যাপ ঠিকভাবে চলে কিন্তু লোকালভাবে কাজ করে না, কারণ পরিবেশ ভ্যারিয়েবল, ডাটাবেস সেটআপ বা সিক্রেটগুলো স্পষ্ট করা হয়নি।

একটি পরিষ্কার এক্সপোর্ট থেকে আপনি চারটি ফলাফল আশা করতে পারেন:

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

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

আপনি যদি Koder.ai ব্যবহার করে থাকেন, আপনার এক্সপোর্টে সাধারণ স্ট্যাক থাকতে পারে—যেমন React ওয়েব অ্যাপ, একটি Go ব্যাকএন্ড, PostgreSQL, বা একটি Flutter মোবাইল অ্যাপ। স্ট্যাক যতই হোক না কেন মূল নীতি একই: চালানোর জন্য যা যা দরকার সবই রিপোজিটরিতে দৃশ্যমান থাকা উচিত, হোস্টেড পরিবেশে আটকে থাকা উচিত নয়।

কল্পনা করুন একজন প্রতিষ্ঠাতাকে যখন একজন কন্ট্রাকটরকে অ্যাপ হস্তান্তর করছেন। “এখানে রেপো” বলে দেওয়াই যথেষ্ট হওয়া উচিত। কন্ট্রাকটরকে মূল প্ল্যাটফর্ম প্রজেক্টে অ্যাক্সেস নিয়ে API বেস URL খুঁজতে, ডাটাবেস স্কিমা তৈরি করতে বা ফ্রন্টএন্ড কিভাবে বিল্ড করতে হয় সেটি জানতে হওয়া উচিত নয়।

এক্সপোর্ট করা প্রজেক্টে আপনি কী আশা করবেন

এক্সপোর্টের পরে আপনার কাছে একটি সাধারণ রেপোজিটরি থাকা উচিত যা আপনি এডিটরে খুলতে, ল্যাপটপে চালাতে এবং মূল প্ল্যাটফর্ম ছাড়া অন্য টিমকে হস্তান্তর করতে পারবেন।

Koder.ai প্রজেক্টের ক্ষেত্রে, এক্সপোর্টগুলো প্রায়ই পরিচিত স্ট্রাকচারের সঙ্গে মেলে: একটি React ওয়েব অ্যাপ, একটি Go ব্যাকএন্ড, এবং (যদি তৈরি করা হয়ে থাকে) একটি Flutter মোবাইল অ্যাপ। ফোল্ডার নাম ভিন্ন হতে পারে, কিন্তু রেপোটি সহজেই বোঝাতে হবে প্রতিটি অংশ কোথায় আছে এবং তারা কীভাবে সংযুক্ত।

প্রজেক্ট আকৃতি: ফোল্ডার, এন্ট্রি পয়েন্ট, এবং কী চালায় কী

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

সাধারণ লক্ষণগুলো:

ওয়েব: একটি package.json প্লাস src/ ফোল্ডার (প্রায়ই main.tsx বা সমতুল্য)
ব্যাকএন্ড: go.mod এবং একটি cmd/ ফোল্ডার বা main.go
মোবাইল: Flutter-এর pubspec.yaml এবং lib/main.dart
একটি টপ-লেভেল README বা 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

ডাটাবেস সত্যিকারের কাজ করছে কিনা নিশ্চিত করা (শুধু “সার্ভার শুরু হয়েছে” নয়)

একটি সার্ভার বুট করে গেলেও অ্যাপ এখনও ভাঙা থাকতে পারে। নিশ্চিত করুন এটি ডাটা পড়তে এবং লেখতে পারে।

পণ্য অনুযায়ী দ্রুত চেকগুলো বেছে নিন:

এমন একটি পৃষ্ঠা খুলুন যা স্পষ্টভাবে ডাটার ওপর নির্ভর করে (একটি লিস্ট, প্রোফাইল, ড্যাশবোর্ড)।
একটি রেকর্ড তৈরি করুন (সাইনআপ, আইটেম তৈরি, নোট যোগ), রিফ্রেশ করুন, এবং নিশ্চিত করুন এটি স্থায়ী হয়েছে।
UI সমর্থন করলে একটি আপডেট এবং একটি ডিলিট ট্রিগার করুন।
মাইগ্রেশন ত্রুটি বা “relation does not exist” এর জন্য লগ দেখুন।

একবার আপনার কাছে একটি কাজ করা লোকাল রান থাকলে, আপনার খসড়া নোটটি একটি বাস্তব 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 থেকে এক্সপোর্ট করে থাকেন, এক্সপোর্টটিকে একটি নতুন স্বাধীন প্রজেক্টের প্রথম কমিট হিসেবে বিবেচনা করুন, এবং তবেই অন্যদের আমন্ত্রণ জানান।

লোকাল ডেভেলপমেন্ট সেটআপ যাতে নতুন মানুষ 따라 করতে পারে

Build and get rewarded

Share what you build with Koder.ai and earn credits to keep building.

Earn Credits

একটি ভালো লোকাল সেটআপ এক প্রশ্ন দ্রুত করে উত্তর দেয়: কি একটি নতুন মানুষ ১৫ মিনিটের মধ্যে অ্যাপ চালাতে পারে কি না, অনুমান ছাড়াই।

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

একটি সাধারণ প্যাটার্ন: একটি README পৃষ্ঠা, একটি স্যাম্পল env ফাইল, এবং একটি বুটস্ট্র্যাপ কমান্ড।

একটি ন্যূনতম, নিরাপদ 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 (কমিট করবেন না)
CI: CI প্রদানকারীর সিক্রেট স্টোর
প্রোডাকশন: ডেডিকেটেড সিক্রেট ম্যানেজার বা হোস্টিং এনভায়রনমেন্ট ভ্যারিয়েবল

আপনি যদি Koder.ai মত একটি vibe-coding প্ল্যাটফর্ম থেকে এক্সপোর্ট করে থাকেন, মনে করুন চ্যাট, লগ বা সেটিং প্যানেলে দেখানো যেকোনো কিছু কপি হতে পারে। সিক্রেটগুলো রিপো থেকে তৎক্ষণাত সরান।

একটি ব্যবহারিক পন্থা হলো একটি নিরাপদ টেমপ্লেট কমিট করা (যেমন .env.example), সত্যিকারের মান Git-এ না রাখা (.env-কে .gitignore-এ যোগ করুন), এবং প্রোডাকশনে ডিপ্লয় সময় সিক্রেট ইনজেক্ট করা।

যদি এক্সপোর্টের সময় কোনো সিক্রেট ফাঁস হওয়ার সম্ভাবনা থাকে, সেগুলো রোটেট করুন। ডাটাবেস পাসওয়ার্ড, OAuth ক্লায়েন্ট সিক্রেট এবং webhook সাইনিং কী এগুলোকে অগ্রাধিকার দিন।

কয়েকটি গার্ডরেল যোগ করুন যাতে এটি আবার না ঘটে: স্পষ্ট সিক্রেট প্যাটার্নের জন্য pre-commit চেক, CI-তে সিক্রেট স্ক্যান, বাধ্যতামূলক ভেরিয়েবল না থাকলে দ্রুত ব্যর্থ করে দেওয়া কনফিগ লোডিং, এবং প্রতিটি পরিবেশের জন্য আলাদা ক্রেডেনশিয়াল।

একটি ছোট SECRETS.md হ্যান্ডঅফে সহায়ক। সহজ রাখুন: প্রয়োজনীয় ভ্যারিয়েবল, কোন পরিবেশে কোথায় রাখা হয়, এবং কে এগুলো রোটেট করতে পারে।

CI সেটআপ যাতে রেপো স্বাস্থ্যবান থাকে

Collaborate, then hand off

Bring teammates in, then export a handoff-ready repo when it’s time to scale.

Invite Team

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

CI-কে এক প্রশ্ন দ্রুত উত্তর দিতে বলুন: "এই পরিবর্তনটি মার্জ করা নিরাপদ কি?" বেশিরভাগ রেপোর জন্য এর মানে হলো ডিপেন্ডেন্সি ইনস্টল করা, বিল্ড করা, লিন্ট করা, এবং ইউনিট টেস্ট চালানো।

জবগুলো অ্যাপ অংশ অনুযায়ী ভাগ করুন যাতে ব্যর্থতা স্পষ্ট হয়:

Web: install, lint/typecheck, build, run tests
Backend: build, run unit tests, run linters/format checks
Optional mobile (Flutter): analyze, test, build
Optional database check: apply migrations in a throwaway environment

ক্যাশিং ব্যবহার করুন, কিন্তু ক্যাশ সমস্যাগুলো লুকিয়ে রাখুক না। ক্যাশ মিস হ’লেও 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 আর্টিফ্যাক্ট হিসেবে সংরক্ষণ করুন। এমনকি যদি আপনি এখনও প্ল্যাটফর্ম থেকে ডিপ্লয় করেন, রিপিটেবল আর্টিফ্যাক্ট ভবিষ্যতে হোস্ট পরিবর্তন সহজ করে।

সাধারণ ভুলগুলো ও সেগুলো এড়ানোর উপায়

কোড এক্সপোর্ট করা কাজের অর্ধেক। অন্য অর্ধেক হলো নিশ্চিত করা যে প্রজেক্টটি প্ল্যাটফর্মের বাইরে একইভাবে আচরণ করে।

ভুল 1: শূন্য সেটআপে চালবে বলে আশা করা

এক্সপোর্টগুলো প্রায়ই environment variables, migrations, seed data, এবং বিল্ড স্টেপসের ওপর নির্ভর করে যা আপনার পক্ষে হ্যান্ডেল হয়েছে। প্রথম চালায় একটি খালি স্ক্রীন বা ডাটাবেস ত্রুটি স্বাভাবিক।

কোনো পরিবর্তন করার আগে একটি বেসলাইন রান করুন: deps ইনস্টল করুন, env vars সেট করুন, মাইগ্রেশন চালান, সার্ভিসগুলো সঠিক ক্রমে চালান। শুধুমাত্র দরকারি বদলগুলো ঠিক করুন যাতে প্রত্যাশিত সেটআপের সাথে ম্যাচ করে।

ভুল 2: সিক্রেট Git-এ ফাঁস করা

সবচেয়ে সাধারণ দুর্ঘটনা হলো আসল API কী বা পাসওয়ার্ড কমিট করা, সাধারণত .env কপি করে বা টুল-জেনারেটেড কনফিগের মাধ্যমে।

শুধু টেমপ্লেট কমিট করুন। আসল মান লোকাল এনভায়রনমেন্ট বা সিক্রেট স্টোরে রাখুন।

ভুল 3: খুব দ্রুত ডিপেন্ডেন্সি বদলানো

প্যাকেজ আপগ্রেড বা ফোল্ডার পুনর্গঠন করে ফেললে সমস্যা যে এক্সপোর্ট থেকেই নাকি আপনার পরিবর্তন থেকেই হয়েছে—তা বোঝা কঠিন হয়।

প্রথমে একটি কাজ করা রান নিশ্চিত করুন, তারপর ছোট, আলাদা কমিটে উন্নতি করুন।

ভুল 4: ভার্সন পিন না করা

"আমার মেশিনে চলে" প্রায়ই অপরিপক্ক টুল ভার্সনের (Node, Go, Flutter, এমনকি প্যাকেজ ম্যানেজার) কারণে ঘটে।

রানটাইম ভার্সন একটি স্পষ্ট জায়গায় পিন করুন (একটি ফাইল বা README), লকফাইল রাখুন (package-lock, go.sum, pubspec.lock), এবং সেটআপ একটি দ্বিতীয় মেশিনে বা একটি ফ্রেশ কন্টেইনারে যাচাই করুন।

ভুল 5: ডকুমেন্টেশন এড়িয়ে যাওয়া

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

একটি বাস্তবসম্মত উদাহরণ: প্ল্যাটফর্ম প্রজেক্ট থেকে স্বাধীন রেপো

Export and take control

Get source code you can commit, clone, and deploy from your own pipeline.

Export Code

তিন-জনের একটি টিম 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 চেক যা দ্রুত ব্যর্থ করে, এবং স্টেজিং ও রোলব্যাকের জন্য একটি সংক্ষিপ্ত ডিপ্লয় নোট।

দ্রুত চেকলিস্ট এবং পরবর্তী ধাপ

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

চূড়ান্ত চেকলিস্ট ব্যবহার করুন:

রেপো পাঠযোগ্য: স্পষ্ট README, যুক্তিসঙ্গত ফোল্ডার নাম, এবং অ্যাপ চালানোর একটি উপায়।
শূন্য থেকে লোকাল রান কাজ করে: ক্লোন, ইনস্টল, কনফিগার, চালানো, এবং অ্যাপ দেখা কোনো ম্যানুয়াল এডিট ছাড়াই।
টেস্ট চালায় (একটি স্মোক টেস্ট বা হেলথ চেক অন্যথায় কিছু না থাকলে ভালো)।
CI প্রতিটি পুশে চলে: lint, tests, এবং একটি দ্রুত ব্যর্থ হওয়া বিল্ড।
সিক্রেট আলাদা: রেপোতে কোনো কী নেই, এবং একটি স্যাম্পল কনফিগ ফাইল প্রয়োজনীয় ভ্যারিয়েবলগুলো দেখায়।
ডকস বেসিক কভার করে: কিভাবে চালাতে হয়, কিভাবে ডিপ্লয় করতে হয়, এবং সাধারণ সেটিংস কোথায় পরিবর্তন করতে হয়।

প্রযুক্তিগত চেকের পরে মালিকানা স্পষ্ট করুন। নির্ধারণ করুন কে ডিপেন্ডেন্সি আপডেট, অবকাঠামো পরিবর্তন (ডাটাবেস, কিউ, DNS), এবং রিলিজের দায়িত্ব নেবে। যদি কেউ এগুলো দায়িত্ব না নেয়, রেপো ধীরে ধীরে বার্ধক্যর্ত হবে যদিও আজ অ্যাপ কাজ করে।

প্রধান ফিচার কাজ শুরু করার আগে একটি সংক্ষিপ্ত স্থিতিশীলকরণ উইন্ডো পরিকল্পনা করুন। ২–৫ কার্যদিবস প্রায়ই যথেষ্ট হয় এক্সপোর্টের খুঁতগুলো ঠিক করতে, README মজবুত করতে, এবং "আমার মেশিনে চলে" সমস্যা দূর করতে।

আপনি যদি Koder.ai (koder.ai) ব্যবহার করে থাকেন, এক্সপোর্টগুলো প্লাস স্ন্যাপশট ও রোলব্যাকের মত ফিচার আপনাকে রিপো শক্ত করার সময় পুনরাবৃত্তি সহজ করে। একবার রেপো স্থির হলে, Git-কে সৃত্রু সত্য হিসেবে বিবেচনা করুন এবং ভবিষ্যতের এক্সপোর্টগুলোকে কেবল চেকপয়েন্ট হিসেবে ধরুন, প্রধান হিস্ট্রি হিসেবে নয়।

পরবর্তী হ্যান্ডঅফ মাইলস্টোন সাদাসিধা ভাষায় নির্ধারণ করুন: "কোনো ডেভেলপার ৩০ মিনিটে এটি চালাতে পারবে।" তারপর একজন নতুনকে ছোট করে README অনুসরণ করতে বলুন। তাদের প্রশ্নগুলো আপনার চূড়ান্ত টু-ডু লিস্ট হবে।

সাধারণ প্রশ্ন

What does “taking ownership” actually mean after I export the code?

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?

What should I check first to see if an export is complete?

Start with a quick completeness check:

Find each app “root” (package.json, go.mod, pubspec.yaml).
Confirm there’s a lockfile (package-lock.json, yarn.lock, pnpm-lock.yaml, go.sum).
Look for database migrations (migrations/ or similar).
Check for a runnable workflow (README, Makefile, scripts, or 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.

What’s the safest way to get an exported project running locally?

Do it in small, verifiable steps:

Initialize Git and commit the raw export (baseline).
Set up local config using .env.example → .env.
Start the database.
Run migrations.
Start the backend.
Start the frontend.

Don’t refactor immediately—first prove it runs as-is, then improve it in separate commits.

Why does an app run fine on the platform but fail on my laptop?

Because the hosted environment often had things you never made explicit:

Missing environment variables (API base URL, JWT secret, storage keys).
Database not created, migrations not applied, or seed data missing.
Different ports/CORS settings that were preconfigured in hosting.
Implicit build steps that were handled “somewhere else.”

Fix this by making the setup visible: .env.example, migration scripts, and a README with exact commands.

How do I confirm the database part actually works after export?

A server “starting” isn’t enough—verify real data flow:

Load a page that clearly depends on database reads.
Create a record, refresh, and confirm it persisted.
Do one update and one delete if possible.
Watch logs for migration issues like “relation does not exist.”

If you can’t reliably reproduce data changes locally, your setup or migrations are incomplete.

How should I handle secrets so I don’t leak API keys in Git?

Default approach:

Commit .env.example with fake values.
Add .env to .gitignore.
Store real secrets in a password manager or a secret store.

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.

What’s the minimum CI setup I should add once I own the repo?

Keep the first CI simple and consistent with local commands:

Build and lint/typecheck the web app.
Run go test ./... and build the backend.
Optionally apply migrations in an ephemeral database.

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.”

Do I really need a README and bootstrap script if the app already runs?

Yes—if you want a predictable handoff. A good default is:

A single top-level README.md with copy-paste commands.
A .env.example describing required vs optional variables.
One bootstrap command/script to install deps and prepare the DB.

Aim for a new developer being able to run the app in 15–30 minutes without guessing.

How should I organize an exported repo (web + API + database) so it’s easy to maintain?

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.

What’s a good “next steps” plan after exporting from Koder.ai?

A practical sequence:

Export and commit the baseline.
Make it run locally with explicit config, migrations, and a clear README.
Add CI to keep builds and tests from silently breaking.
Add a simple deploy note (how to set secrets, run migrations, rollback).

Once stable, treat Git as the source of truth and any future platform exports as checkpoints, not the primary history.