সোর্স-এক্সপোর্ট করা প্রজেক্টের পোর্টেবিলিটি পরীক্ষা দরকার

সোর্স কোড এক্সপোর্ট করা প্রমাণ করে আপনি ফাইল পেয়েছেন। এটি প্রমাণ করে না যে মূল AI app builder অদৃশ্য হয়ে গেলে প্রজেক্টটি build, start, ব্যবহারকারী authenticate, production data পড়া বা deploy করতে পারবে। পোর্টেবিলিটিকে বিক্রয়চুক্তির চেকবক্স না ভেবে গ্রহণযোগ্যতার পরীক্ষা হিসেবে নিন।

আমি এত জেনারেট করা অ্যাপ্লিকেশনের দায়িত্ব নিয়েছি যে ঝকঝকে রিপোজিটরি দেখলেই সন্দেহ হয়। ব্যয়বহুল ব্যর্থতা সাধারণত চোখে পড়া application code-এর বাইরে লুকিয়ে থাকে: vendor service-এ runtime request, অন্যের tenant-এ নিবন্ধিত authentication callback, version control-এ না যাওয়া database policy, অথবা শুধু managed dashboard-এ থাকা deployment setting। একটি প্রজেক্ট তখনই পোর্টেবল, যখন আপনার দল এক্সপোর্ট এবং আপনার নিয়ন্ত্রণাধীন অ্যাকাউন্টের নথিভুক্ত বাইরের পরিষেবা ব্যবহার করে তার কাজের আচরণ পুনরুৎপাদন করতে পারে।

সোর্স এক্সপোর্ট করা প্রজেক্টও builder-এর ওপর নির্ভরশীল থাকতে পারে

প্রতিটি দরকারি build-time ও runtime dependency পাওয়া যায়, নথিভুক্ত, স্থানান্তরযোগ্য এবং builder-এর বাইরে ব্যবহারের জন্য লাইসেন্সকৃত হলেই সোর্স-এক্সপোর্ট করা প্রজেক্ট স্বাধীনভাবে চলে। এই সংজ্ঞা «রিপোজিটরিটি compile হয়»-এর চেয়ে কঠোর। এতে ফাঁকা মেশিন থেকে কার্যকর production release পর্যন্ত পথটি পড়ে, যার মধ্যে identity, data, নির্ধারিত কাজ, secret, network rule ও recovery রয়েছে।

তিনটি ভিন্ন দাবি প্রায়ই একাকার হয়ে যায়। সোর্স অ্যাক্সেস মানে ফাইল দেখা যায়। Build independence মানে builder-কে call না করেই artifact তৈরি করা যায়। Runtime independence মানে builder ছাড়া সেই artifact বাস্তব request সামলাতে থাকে। কোনো vendor প্রথম দাবিটি পূরণ করেও বাকি দুটিতে ব্যর্থ হতে পারে।

এই পার্থক্যের সরাসরি চুক্তিগত প্রভাব আছে। চুক্তিতে «source export» থাকলে আপনি React directory, package manifest ও README পেলেও proprietary SDK বা hosted gateway লাগতে পারে। তার বদলে একটি operational outcome চান: অনুমোদিত engineer গ্রাহকের মালিকানাধীন অ্যাকাউন্ট ব্যবহার করে পরিষ্কার পরিবেশে গৃহীত release build ও চালাতে পারবেন।

পরীক্ষার আগে সীমারেখা ঠিক করুন। Managed service মানেই পোর্টেবিলিটি ব্যর্থতা নয়। অধিকাংশ গুরুত্বপূর্ণ অ্যাপ্লিকেশন cloud, payment processor, email provider বা identity service-এর ওপর নির্ভরশীল। প্রশ্ন হলো, আপনি কি জেনেশুনে এই নির্ভরতাগুলো বেছেছেন এবং নিজের চুক্তিতে এগুলো সরাতে বা বদলাতে পারবেন। আলাদা করে চুক্তি করা যায় না এমন গোপন vendor service, আপনার cloud account-এ নথিভুক্ত PostgreSQL database থেকে আলাদা।

প্রতিটি বাইরের component-এর জন্য চারটি ঘর নিয়ে dependency register বানান: owner, purpose, replacement path এবং failure behavior। «Owner» বলতে আইনি account holder বোঝায়, password জানেন এমন ব্যক্তি নয়। «Replacement path» হতে পারে migration procedure, পুনরায় বাস্তবায়নযোগ্য interface, অথবা পরিষেবাটি রেখে দেওয়ার স্পষ্ট সিদ্ধান্ত। «Failure behavior»-এ পরিষেবাটি না থাকলে ব্যবহারকারী কী দেখবেন তা লিখুন। বিক্রেতা এই ঘরগুলো পূরণ করতে না পারলে ঝুঁকির মূল্য নির্ধারণের মতো করে এক্সপোর্টটি ব্যাখ্যা করা হয়নি।

সবচেয়ে ভালো প্রথম পরীক্ষা খুব সাধারণ: builder account-এর অ্যাক্সেস বিচ্ছিন্ন করে অ্যাপ্লিকেশন চালান। staging copy-তে তার token বাতিল করুন, network boundary-তে পরিচিত domain block করুন, তারপর কী ভাঙে দেখুন। শুরুতেই প্রতিটি ফাইল পড়বেন না। Runtime evidence code review-এ বাদ পড়া dependency খুঁজে দেয়, যেমন injected configuration ও compiled package-এর call।

বাস্তব workflow চলার সময় অ্যাপ্লিকেশন trace করুন

Representative workflow-তে DNS, outbound connection, browser request ও background job দেখলে runtime callback ধরা পড়ে। শুধু home page load হওয়া তেমন কিছু প্রমাণ করে না। sign-in, password recovery, file upload, search, billing transition, email delivery, scheduled task, administrative action এবং পণ্যটি যে AI-ভিত্তিক feature বিক্রি করে সেগুলো চালান।

নতুন staging network-এ অ্যাপ চালান, যেখানে outbound traffic লগ হয়। dependency register-এ থাকা গন্তব্য ছাড়া আর কিছু দেবেন না। পরিবেশে সম্ভব হলে তালিকাবহির্ভূত traffic-এর জন্য deny policy দিয়ে শুরু করুন। প্রতিটি blocked request একটি প্রশ্ন: এটি কি জরুরি, ঐচ্ছিক telemetry, update check, নাকি অনথিভুক্ত control-plane call?

Browser developer tool গুরুত্বপূর্ণ, কারণ কিছু dependency কখনও আপনার server ছোঁয় না। storage পরিষ্কার করে নতুন session নেওয়ার পর Network panel দেখুন। request host, ব্যর্থ preflight request, WebSocket connection, load হওয়া script ও redirect দেখুন। Server repository স্বয়ংসম্পূর্ণ মনে হলেও frontend সরাসরি builder API call করতে পারে। Service worker পুরোনো আচরণ ধরে রাখতে পারে, তাই পরীক্ষা ফের চালানোর আগে সেগুলো unregister করুন।

Unix-সদৃশ source tree-তে এই search একটি উপযোগী প্রাথমিক inventory দেয়:

grep -R -n -E 'https?:|wss?:|fetch[(]|axios|WebSocket|grpc|callback|webhook' .

আউটপুট হবে path/to/file:line:matching text ধরনের। Application code থেকে generated lockfile আলাদা করে দেখুন, কারণ package metadata-তে domain থাকলেই runtime call প্রমাণ হয় না। উল্টোদিকে পরিষ্কার search-ও independence প্রমাণ করে না: environment variable host তৈরি করতে পারে, DNS alias তা আড়াল করতে পারে, আর binary dependency নিজের request করতে পারে।

Vendor term, SDK import এবং environment-variable prefix আলাদা আলাদা ধাপে খুঁজুন। তারপর lockfile দেখে জানুন package public registry না private vendor registry থেকে resolve হয়। এখানে cache-এর সফলতা বিভ্রান্ত করতে পারে। isolated test environment-এ language package cache মুছে ফেলুন এবং শুধু নথিভুক্ত registry credential দিয়ে rebuild করুন।

Scheduler boundary পার হওয়ার মতো সময় ধরে background behavior trace করুন। Queue consumer ব্যর্থ হলেও, scheduled report বন্ধ হয়ে গেলেও এবং webhook retry জমলেও web process সুস্থ দেখাতে পারে। স্বাভাবিক schedule-এর জন্য অপেক্ষা করলে পরীক্ষা ধীর হলে job হাতে চালান। প্রতিটি outbound integration-এর destination, request method, authentication type, response class, retry rule এবং ব্যবহারকারীর ওপর প্রভাব লিখে রাখুন।

«ওই callback শুধু telemetry» কথাটি তার ব্যর্থতা পরীক্ষা ছাড়া মেনে নেবেন না। সেটি block করে workflow আবার চালান। ঐচ্ছিক telemetry দ্রুত timeout হওয়া উচিত বা ব্যবহারকারীর কাজ না বদলিয়েই ব্যর্থ হওয়া উচিত। আমি দেখেছি request transaction-এর ভেতরে logging call থাকায় নিরীহ analytics outage-ও save ব্যর্থ করেছে। ঝুঁকি নাম দিয়ে ঠিক হয় না, code path-ই ঠিক করে।

Proprietary SDK-এর অপসারণ বা লাইসেন্সের পথ দরকার

Proprietary SDK তখনই গ্রহণযোগ্য, যখন আপনি এটি পেতে, এর বিরুদ্ধে build করতে, আইনসম্মতভাবে চালাতে এবং ব্যবসার সহনীয় সময়ে বদলাতে পারেন। এক্সপোর্টে তার wrapper source থাকলেই SDK, protocol, hosted endpoint বা পেছনের model ব্যবহারের অধিকার মেলে না।

Manifest এবং source import দুই জায়গা থেকেই dependency-এর তালিকা করুন। JavaScript-এর জন্য package.json ও তার lockfile দেখুন। Go-এর জন্য go.mod ও checksum দেখুন। Flutter-এর জন্য pubspec.yaml ও তার lockfile দেখুন। Git repository, private registry, local path বা archive থেকে আনা package নোট করুন। Builder-মালিকানাধীন component লুকানোর সাধারণ জায়গা এগুলো।

প্রতিটি সন্দেহজনক package নিয়ে চারটি নির্দিষ্ট প্রশ্নের উত্তর দিন:

1. নতুন গ্রাহক-মালিকানাধীন build agent কি সঠিক version download করতে পারে?
2. Builder-এর চুক্তি শেষের পরেও কি license production ব্যবহার অনুমতি দেয়?
3. Package-টি কি এমন service call করে যার সঙ্গে গ্রাহক সরাসরি চুক্তি করতে পারেন?
4. Interface-টি কি বদলানোর মতো ছোট, এবং সেই interface পরীক্ষা করা হয়েছে কি?

গ্রাহক-মালিকানাধীন organization-এ তৈরি credential দিয়ে cold build করুন। কোনো developer-এর সম্পূর্ণ configuration directory test machine-এ copy করবেন না। তাতে cached package, implicit registry setting ও ব্যক্তিগত token ঢুকে যায়, যা পরীক্ষার উদ্দেশ্য নষ্ট করে। সঠিক build procedure নথিভুক্ত toolchain version দিয়ে শুরু হয় এবং প্রতিটি অতিরিক্ত credential আলাদাভাবে ঘোষণা করে।

Toolchain সমর্থন করলে software bill of materials তৈরি করুন, তবে তাকে পোর্টেবিলিটির রায় ভেবে ভুল করবেন না। SBOM component তালিকাবদ্ধ করে, কিন্তু remote account কার নিয়ন্ত্রণে বা কোনো package বাইরে call করে কি না তা সচরাচর বলে না। Repository যা ঘোষণা করে তার সঙ্গে built artifact-এ যা আছে মিলিয়ে দেখতে এটি ব্যবহার করুন।

যেখানে proprietary client সরু adapter-এর পেছনে থাকে, এখনই adapter-এর বিরুদ্ধে contract test লিখুন। পরিচিত request দিন, normalized response যাচাই করুন এবং network endpoint block করে একই test চালান। ব্যর্থতাটি স্পষ্ট ও সীমাবদ্ধ হওয়া দরকার। Proprietary call যদি view component, route handler ও data model জুড়ে ছড়িয়ে থাকে, চুক্তির আগে refactor-এর খরচ ধরুন। সমস্যা SDK-এর line count-এ নয়, call-site-এর সংখ্যা ও semantic coupling-এ বাড়ে।

দলগুলো প্রায়ই কেনার আগে প্রতিটি proprietary dependency বদলানোর পরামর্শ দেয়। শুনতে নিরাপদ লাগলেও ক্রেতা যে service রেখে দিতে চান তার পেছনে সপ্তাহ নষ্ট হতে পারে। ভালো নিয়ম হলো, যা পাওয়া যায় না বা যার সঙ্গে চুক্তি করা যায় না তা সরান, গ্রহণযোগ্যগুলো আলাদা করুন এবং বাকিগুলোর সঙ্গে migration cost যুক্ত করুন। পোর্টেবিলিটি মানে পছন্দের ওপর নিয়ন্ত্রণ, শূন্য বাইরের service নয়।

Authentication সোর্স ট্রির চেয়েও বড় বিষয়

Authentication পরিষ্কারভাবে সরানো যায় তখনই, যখন গ্রাহক identity tenant, redirect registration, signing key, user identifier, email template এবং recovery process নিয়ন্ত্রণ করেন। Application code সাধারণত এই ব্যবস্থার মাত্র একটি অংশ ধরে রাখে।

Login path-টি বাস্তব hop হিসেবে আঁকুন। Browser অ্যাপ্লিকেশনে যায়, অ্যাপটি identity provider-এ redirect করে, provider নিবন্ধিত callback-এ ফেরত আসে, আর backend credential exchange বা validate করে। প্রতিটি hop-এ owner ও configuration location লিখুন। কোনো console শুধু builder-এর organization দিয়ে খোলা গেলে গ্রহণের আগে transfer বা replacement চাইুন।

Managed authentication একটি বিশেষ জটিল data problem তৈরি করে। অ্যাপ্লিকেশনের user table email address বা স্থায়ী internal ID-এর বদলে provider-specific subject রাখতে পারে। নতুন identity tenant ভিন্ন subject দিলে row export করেও লাভ নেই। Account matching, duplicate handling, password user, social-login user, multifactor enrollment, locked account এবং email বদলানো ব্যবহারকারী পরীক্ষা করুন।

OpenID Connect-এ sub claim-কে issuer-এর scope-এর মধ্যে স্থানীয়ভাবে অনন্য ও কখনও পুনর্বণ্টন না হওয়া identifier বলা হয়েছে। Issuer গুরুত্বপূর্ণ। শুধু sub-কে বিশ্বজুড়ে বহনযোগ্য ভাবলে tenant বদলের পর ভুল application record যুক্ত হতে পারে। Subject-এর সঙ্গে issuer সংরক্ষণ ও তুলনা করুন, তারপর migration-এর জন্য স্পষ্ট mapping নকশা করুন।

আপনার পরীক্ষায় অন্তত চারটি account দরকার: সাধারণ user, administrator, disabled user এবং দ্বিতীয় authentication factor-সহ user। Identity configuration গ্রাহক-মালিকানাধীন tenant-এ সরান বা নতুন করে বানান, staging database copy restore করুন এবং সফল login ও denied access যাচাই করুন। Logout, token refresh, password reset, invitation acceptance ও session expiry-ও পরীক্ষা করুন। দলগুলো happy login path মনে রাখে, recovery নষ্ট হওয়ার বিষয়টি cutover-এর পর জানতে পারে।

Repository-তে redirect URI, client ID, issuer name, cookie domain, audience value এবং signing-key reference খুঁজুন। Secret repository-র বাইরে রাখুন, কিন্তু তাদের নাম, owner, তৈরির ধাপ, rotation-এর ধাপ ও দরকারি format deployment documentation-এ রাখুন। একটি sample environment file-এ live value না রেখে contract বোঝানো উচিত:

AUTH_ISSUER=
AUTH_CLIENT_ID=
AUTH_CLIENT_SECRET=
AUTH_CALLBACK_ORIGIN=
SESSION_SIGNING_KEY=

«পরে» migration করা যাবে বলে shared builder tenant-কে স্থায়ী ব্যবস্থা হিসেবে মেনে নেবেন না। Identity migration প্রতিটি সক্রিয় user এবং প্রতিটি authorization assumption স্পর্শ করে। চুক্তির আগে নিয়ন্ত্রণ হস্তান্তর করুন, অথবা replacement-কে চুক্তির মূল্য নির্ধারিত ও পরীক্ষিত শর্ত করুন।

ডেটাবেস পোর্টেবিলিটিতে আচরণ ও পরিচালনাও পড়ে

Schema, extension, row-level policy, trigger, object storage, queue, backup ও connection rule dump-এর বাইরে থাকলে database dump যথেষ্ট নয়। Database portability মানে data restore করা এবং সেটিকে সুরক্ষিত ও পরিবর্তনকারী আচরণটি পুনরুৎপাদন করা যায়।

নথিভুক্ত major version-এর ফাঁকা গ্রাহক-মালিকানাধীন PostgreSQL instance দিয়ে শুরু করুন। Repository migration-গুলো ক্রমানুসারে apply করুন। প্রজেক্টে migration না থেকে vendor-তৈরি schema dump import করতে হলে সেটি defect হিসেবে নথিবদ্ধ করুন। Dump আজকের অবস্থা ধরতে পারে, কিন্তু পরের release কীভাবে নিরাপদে তা বদলাবে বলে না।

Restored schema-র সঙ্গে production বা staging-এর তুলনা করুন। Table, column, type, constraint, index, sequence, view, function, trigger, enabled extension, role, grant ও row-level security policy দেখুন। অনেক migration tool role ও provider-level setting বাদ দেয়। Restored role-এর sequence বা function-এর permission না থাকলে application-এর সাধারণ read test পাস করলেও administrative job ব্যর্থ হতে পারে।

তারপর নিয়ন্ত্রিত round trip দিয়ে data path যাচাই করুন:

1. Public application workflow দিয়ে একটি record তৈরি করুন।
2. যেখানে share করার কথা, সেখানে দ্বিতীয় অনুমোদিত user দিয়ে সেটি পড়ুন।
3. অননুমোদিত user এটি পড়তে বা বদলাতে না পারে নিশ্চিত করুন।
4. Application দিয়ে এটি update ও delete করুন।
5. আরেকটি পরিষ্কার instance-এ database restore করে আবার read করুন।

এই ধাপগুলো একসঙ্গে application code, authorization policy, generated value এবং recoverability পরীক্ষা করে। সরাসরি SQL row count দিয়ে এই আচরণগুলো ধরা যায় না।

Row যখন uploaded file-এ নির্দেশ করে, object storage-কে database boundary-এর অংশ ভাবুন। Bucket, object metadata, access rule, lifecycle rule ও URL-generation setting এক্সপোর্ট করুন। Object key-ভরা restored database অকাজের, যদি আসল file builder-মালিকানাধীন bucket-এ থেকে যায়। একই সতর্কতা search index ও vector store-এর জন্য: সেগুলো সরাবেন নাকি আবার বানাবেন ঠিক করুন, এবং rebuild procedure প্রমাণ করুন।

একটি ছোট dump দিয়ে সফলতা বা ব্যর্থতা মাপবেন না। দীর্ঘ text, null, non-ASCII character, বড় object, daylight-saving পরিবর্তনের আশপাশের timestamp এবং representative relationship-সহ staging-আকারের copy ব্যবহার করুন। কল্পিত benchmark দরকার নেই। অনুমোদিত outage-এর মধ্যে transfer শেষ হয় এবং পরে application ঠিক চলে তার প্রমাণ দরকার।

Backup-এর দাবি restore ছাড়া গ্রহণযোগ্য নয়। কে backup schedule করে, copy কোথায় থাকে, কে decrypt করতে পারে, retention কীভাবে হয় এবং ব্যর্থ backup কীভাবে ধরা হয় তা চিহ্নিত করুন। লিখিত নির্দেশ মেনে isolated account-এ একটি restore করুন। শুধু builder restore button চাপতে পারলে এটি service feature, স্বাধীন recovery plan নয়।

CI pipeline না থাকলে পণ্যের জ্ঞানও অনুপস্থিত

পুনরুৎপাদনযোগ্য continuous integration ছাড়া এক্সপোর্ট করা repository ক্রেতাকে tool version, build order, test, artifact packaging, database migration timing এবং release gate নতুন করে খুঁজে বের করতে বাধ্য করে। বিক্রেতার internal pipeline হুবহু স্থানান্তর করা না গেলেও সেই জ্ঞান deliverable-এর অংশ।

Pipeline definition, container build file, tool-version file, test command, lint rule, migration command এবং infrastructure definition খুঁজুন। তারপর বাস্তব deployment log-এর সঙ্গে মিলিয়ে দেখুন। Documentation হয়তো সহজ web build-এর কথা বলে, অথচ managed platform নীরবে configuration তৈরি করে, server component inject করে, mobile bundle বানায় বা database migration চালায়।

গ্রাহক-মালিকানাধীন CI account-এ ন্যূনতম pipeline পুনর্গঠন করুন। এতে pinned revision checkout, ঘোষিত toolchain install, dependency fetch, test run, immutable artifact তৈরি এবং artifact identity record থাকা উচিত। পরীক্ষার সময় deployment manual থাকতেই পারে, কিন্তু staging-এ পৌঁছানো artifact অবশ্যই pipeline-এর তৈরি হতে হবে।

সংক্ষিপ্ত acceptance log এমন হতে পারে:

revision: 4f2c9ab
toolchain: declared versions loaded
dependencies: cold install passed
tests: unit and integration passed
artifacts: web, server, mobile
migrations: dry run passed
staging: health and workflow checks passed

Value ভিন্ন হবে, তবে প্রতিটি লাইনের জন্য machine output বা link করা internal record চাই, কারও স্মৃতি নয়। Acceptance evidence-এর সঙ্গে log রাখুন।

বিক্রেতার গোপন deployment ব্যবস্থা প্রয়োজন না হলে তা চাইবেন না। ফল পুনরুৎপাদনের জন্য যথেষ্ট নির্দেশ ও configuration চাইুন। Portable pipeline ভিন্ন CI product লক্ষ্য করতে পারে, যদি সেটি একই প্রয়োজনীয় stage সম্পন্ন করে এবং release control দুর্বল না করে।

Mobile application-এ signing asset, package identifier, store account ও push-notification credential যোগ হয়। এগুলো সহজে চোখ এড়ায়, কারণ source build emulator-এ এগুলো ছাড়াই চলতে পারে। Distribution account গ্রাহকের মালিকানাধীন কি না যাচাই করুন এবং certificate rotation নথিভুক্ত করুন। Server ও web application-এর ক্ষেত্রে release exercise-এ domain verification, TLS certificate issuance, DNS change ও cache invalidation রাখুন।

Pipeline test supplied commit আবার build করে শেষ হয় না, পরিবর্তন দিয়ে শেষ হয়। ক্ষতিহীন দৃশ্যমান edit করুন, rollback করা যায় এমন database migration যোগ করুন, build করে staging-এ deploy ও যাচাই করুন, তারপর rollback চালান। একবার check-in করা generated artifact পুনরায় তৈরি করা যায় না, এমন সমস্যা এতে ধরা পড়ে।

Language toolchain-এর পাশাপাশি build-এ ব্যবহৃত operating-system package pin করুন। Builder-এর image-এ কাকতালীয়ভাবে থাকা library-এর বিরুদ্ধে native module compile হতে পারে। নতুন runner-এ application test শুরুর আগেই ব্যর্থ হবে, অথবা আরও খারাপ, ভিন্ন আচরণের artifact তৈরি করবে। Container definition বা সমতুল্য machine-readable build description-এ package name ও version রাখুন।

CI log থেকে secret দূরে রাখুন, কিন্তু pipeline গ্রাহক-নিয়ন্ত্রিত store থেকে তা পেতে পারে প্রমাণ করুন। পরীক্ষায় স্বল্পমেয়াদি staging credential তৈরি করতে হবে, নথিভুক্ত পদ্ধতিতে inject করতে হবে এবং source বদলানো ছাড়াই rotate করতে হবে। Support staff-কে vendor dashboard-এ secret paste করতে হলে setup note-এ লুকিয়ে না রেখে dependency হিসেবে লিখুন।

Clean-room deployment-এ হোস্টিং অনুমান সামনে আসে

Clean-room deployment পোর্টেবিলিটি প্রমাণ করে, যখন builder-অপরিচিত একটি দল শুধু এক্সপোর্ট, ঘোষিত service ও লিখিত নির্দেশ ব্যবহার করে গ্রাহক-মালিকানাধীন পরিবেশে system চালু করতে পারে। Contract acceptance-এর আগে time box ও issue log-সহ এটি চালান।

উদ্দেশ্যপ্রণোদিত operating model-এর সঙ্গে মেলে এমন পরিবেশ বাছুন। Managed platform থেকে raw virtual machine-এ গেলে অপ্রাসঙ্গিক কাজ তৈরি হয় এবং portable project-ও ভাঙা মনে হতে পারে। Container, PostgreSQL, object storage, scheduled job, secret ও load balancing-এর মতো দরকারি primitive মেলান, কিন্তু অনথিভুক্ত vendor magic পুনরায় বানাবেন না।

Writable local disk, fixed port, sticky session, trusted proxy header, region name, injected hostname এবং platform-specific environment variable সম্পর্কে application-এর অনুমান দেখুন। Twelve-Factor App configuration environment-এ রাখা এবং backing service-কে attached resource হিসেবে বিবেচনার পরামর্শ দেয়। ধারণাগুলো এখনও উপকারী, কিন্তু শুধু environment variable owner, format বা তৈরির পদ্ধতি নথিভুক্ত করে না। প্রতিটি variable-এর সঙ্গে operational record রাখুন।

Health check সরাসরি পরীক্ষা করুন। Migration শেষ হওয়ার বা দরকারি dependency যুক্ত হওয়ার আগে success ফেরত দেওয়া process orchestrator-এর পেছনে restart loop-এ ঢুকতে পারে। Hosting system সমর্থন করলে liveness ও readiness আলাদা করুন। Database, object store ও queue একে একে বন্ধ করুন, তারপর status code, log, retry behavior এবং service ফেরার পর recovery দেখুন।

Application একাধিক instance কীভাবে সামলায় নিশ্চিত করুন। In-memory session, local upload directory এবং process-local job lock একটি managed instance-এ চলে, scale করার পর ব্যর্থ হয়। দুটি instance চালান, একই user-এর request দুটির মধ্য দিয়ে পাঠান এবং concurrent job worker চালান। Session থাকে কি না, file পাওয়া যায় কি না এবং scheduled task idempotent করার নকশা না থাকলে দুবার চলে কি না দেখুন।

Startup-এর মতো shutdown-ও মনোযোগ দিয়ে দেখুন। Request ও background job সক্রিয় থাকা অবস্থায় termination signal পাঠান। Process-এর নতুন কাজ নেওয়া বন্ধ করা, claimed job শেষ বা নিরাপদে ফিরিয়ে দেওয়া, connection বন্ধ করা এবং host-এর grace period-এর মধ্যে exit করা উচিত। Managed builder দীর্ঘ timeout বা retry দিয়ে হঠাৎ shutdown আড়াল করে রাখতে পারে, যা নতুন host-এ নাও থাকতে পারে।

Log ও metric-এও hosting assumption থাকে। Application নথিভুক্ত গন্তব্যে structured event লিখছে, প্রয়োজনমতো secret ও personal data বাদ দিচ্ছে এবং ব্যর্থ workflow বোঝার মতো তথ্য দিচ্ছে কি না নিশ্চিত করুন। Standard output বা অন্য গ্রাহক-নিয়ন্ত্রিত sink দরকারি evidence রাখলে proprietary dashboard ঐচ্ছিক।

Region ও data-location-এর দাবির জন্য configuration evidence দরকার। Application, database, backup, log ও object storage কোথায় চলে, এবং কোন বাইরের service data পায় তা লিখুন। Web process-এর region selector authentication বা analytics অন্যত্র data পাঠালে দেশেই data রাখে না। চুক্তিতে এই location পরিবর্তন কে অনুমোদন করবেন তা থাকা উচিত।

Koder.ai সোর্স এক্সপোর্ট, deployment ও hosting, custom domain, snapshot এবং rollback সমর্থন করে। স্বাধীনভাবে চালানোর জন্য এক্সপোর্ট করা Koder.ai project মূল্যায়ন করলে একই clean-room মানদণ্ড ব্যবহার করুন: আপনি যে পরিবেশের মালিক হতে চান সেখানে এক্সপোর্ট করা React, PostgreSQL-সহ Go, বা Flutter component পরীক্ষা করুন এবং যে service রেখে দেওয়ার সিদ্ধান্ত নেন তা নথিবদ্ধ করুন।

চুক্তিতে pass ও fail শর্ত রাখুন

চুক্তিতে পোর্টেবিলিটিকে পর্যবেক্ষিত আচরণ হিসেবে সংজ্ঞায়িত করা, acceptance environment উল্লেখ করা, remediation-এর দায়িত্ব দেওয়া এবং চূড়ান্ত payment বা lock-in-এর আগে ত্রুটি ঠিক করার যথেষ্ট সময় রাখা উচিত। অস্পষ্ট ownership language এমন অ্যাপ্লিকেশন উদ্ধার করতে পারে না, যা আর কেউ deploy করতে পারে না।

«source code» শিরোনামের একটি paragraph-এর ওপর নির্ভর না করে acceptance matrix সংযুক্ত করুন। প্রতিটি row-তে capability, test procedure, expected result, evidence, responsible party ও severity থাকবে। Cold build, runtime network call, identity transfer, database restore, file storage, background work, CI, clean deployment, monitoring, backup restore, ছোট পরিবর্তন ও rollback অন্তর্ভুক্ত করুন।

তৃতীয় পক্ষ দেখতে পারে এমন pass criteria ব্যবহার করুন। «কোনো critical proprietary dependency নেই» তর্ক ডাকে। «সব builder-owned credential বাতিল ও builder domain block থাকা অবস্থায় staging application workflow A থেকে F সম্পন্ন করে» পরীক্ষা করা যায়। অনুমোদিত dependency-র নাম ও account owner নির্ধারণ করুন, যাতে দল অনুমোদিত managed service-কে ব্যর্থতা না ভাবে।

Pinned revision-এ source ও operational material সরবরাহ চাইুন: lockfile, migration, build definition, যেখানে পাওয়া যায় infrastructure configuration, environment-variable catalog, dependency register, data export, identity migration plan, runbook, license notice এবং গ্রাহকের মালিকানাধীন signing বা distribution asset। Exclusion স্পষ্ট করে লিখুন। নীরবতা গ্রহণযোগ্যতার অর্থ হওয়া উচিত নয়।

Business effect অনুযায়ী severity ঠিক করুন। অনুপস্থিত ঐচ্ছিক analytics event আর login outage এক নয়। কার্যকর একটি পদ্ধতিতে build বা core workflow আটকানো blocker, গুরুত্বপূর্ণ capability বা recovery path বাদ দেওয়া major defect এবং documented workaround-সহ minor defect আলাদা করা হয়। কৃত্রিম সর্বজনীন সময়সূচি না বানিয়ে acceptance ও remediation date এই স্তরগুলোর সঙ্গে যুক্ত করুন।

Test data ও test operator-ও নির্ধারণ করুন। বিক্রেতারা কখনও ফাঁকা database ও সাধারণ authorization এড়িয়ে যায় এমন administrator account দিয়ে পোর্টেবিলিটি দেখান। Representative user, role, file ও background job চাইুন এবং গ্রাহকের কর্মীদের দিয়ে নথিভুক্ত procedure করান। Secret synthetic রাখুন, তবে relationship ও edge case বাস্তবসম্মত রাখুন।

খরচও evidence packet-এর অংশ। এক্সপোর্ট করা release চালাতে আলাদাভাবে বিল হওয়া service এবং বিক্রেতা চিহ্নিত করা minimum tier, data-egress charge বা private registry subscription লিখুন। পরীক্ষাকে ভবিষ্যতের প্রতিটি bill অনুমান করতে হবে না। সইয়ের পরেই অনিবার্য vendor contract প্রকাশ করে এমন কথিত স্বাধীন export ঠেকাতে হবে।

তাৎক্ষণিকভাবে transfer করা যায় না এমন service-এর জন্য cooperation duty রাখুন। বিক্রেতাকে key rotate, identity export অনুমোদন, domain সরানো বা শেষ data snapshot দেওয়ার প্রয়োজন হতে পারে। কাজটি ও দায়ী ব্যক্তির নাম দিন। Production বন্ধ থাকলে «reasonable assistance» কার্যকর করা কঠিন।

Remediation-এর পর এবং final export-এর পর test আবার চালানোর অধিকার রাখুন। Generated project দ্রুত বদলায়, আর গত মাসের revision-এ প্রমাণিত fix গতকাল যোগ হওয়া নতুন dependency সম্পর্কে কিছু বলে না। Acceptance record-এ পরীক্ষিত commit ও artifact hash pin করুন।

Escrow clause-কে এই কাজের বিকল্প হতে দেবেন না। কোনো trigger event-এর পরে escrow file দিতে পারে, কিন্তু বর্তমান build instruction, credential ownership ও পরীক্ষিত recovery path ছাড়া file খুব দেরিতে আসতে পারে। দুই পক্ষ সহযোগিতা করতে পারার সময়েই operational independence থাকতে হবে।

দ্বিতীয় একটি দল মূল builder-এর privileged help ছাড়া গৃহীত release build, run, change, deploy ও recover করতে পারলেই সই করুন। এর কম হলে আপনার কাছে সোর্সের দখল আছে, সঙ্গে অমীমাংসিত migration project, আর চুক্তির দামে সেই কাজের প্রতিফলন থাকা উচিত।