৩০ দিনে এন্টারপ্রাইজ ভাইব কোডিং পাইলট

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

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

পাইলট নির্মাণের গতির পাশাপাশি বেরিয়ে আসার খরচও মাপে

কেউ তৈরি শুরু করার আগেই পাইলটের গ্রহণযোগ্যতা পরিকল্পনা স্থির করতে হবে। তা না হলে অস্বস্তিকর প্রতিটি ফল আরও সময়ের অনুরোধ, আরও সংকীর্ণ ব্যাখ্যা, বা পরের রিলিজে ঠিক করার প্রতিশ্রুতিতে বদলে যায়।

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

প্ল্যাটফর্মের বাইরে রাখা প্রমাণ ফাইলে প্রতিটি পরীক্ষা নথিবদ্ধ করুন। সহজ কাঠামো ফল পর্যালোচনাযোগ্য রাখে:

pilot:
  application: claims-intake-reference
  revision: 8f21c6a
  test_owner: enterprise-architecture
  vendor_observer: true
controls:
  source_export:
    result: pending
    evidence: []
    blocker_if_failed: true
  access_control:
    result: pending
    evidence: []
    blocker_if_failed: true
  data_location:
    result: pending
    evidence: []
    blocker_if_failed: true
exceptions:
  owner: procurement
  expires: 2026-09-30
  compensating_control: null

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

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

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

দল প্রমাণ ধারাবাহিকভাবে পরীক্ষা করলে ৩০ দিনের সময়সূচি কাজ করে। পরিধি স্থির করে শুরুতেই রেফারেন্স অ্যাপ্লিকেশন বানান, এরপর ধ্বংসাত্মক পরীক্ষা, পরিষ্কার পরিবেশ পুনর্গঠন, পরিচয় ব্যর্থতা, রিস্টোর অনুশীলন এবং হ্যান্ডঅফের জন্য যথেষ্ট সময় রাখুন। যেসব দল ২৮তম দিন পর্যন্ত ডেভেলপ করে, তারা সাধারণত শেষ বৈঠকে এমন ফিচার নিয়ে কথা বলে যেগুলো পরীক্ষা করা হয়নি।

সোর্স এক্সপোর্টে স্বাধীন বিল্ড তৈরি হতে হবে

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

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

বৈঠকে দেওয়া কমান্ড নয়, রিপোজিটরির ঘোষিত কমান্ড চালান। React ও Go অ্যাপ্লিকেশনের ট্রান্সক্রিপ্ট এমন হতে পারে:

$ npm ci
added 428 packages, and audited 429 packages
$ npm test
Test Suites: 18 passed, 18 total
$ go test ./...
ok   example/api/auth
ok   example/api/orders
$ go build ./cmd/server
$ ./server
configuration error: DATABASE_URL is required

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

Twelve-Factor App বলছে, একটি অ্যাপ্লিকেশনের রিভিশন নিয়ন্ত্রণে একটি কোডবেস ট্র্যাক করা এবং নির্ভরতা স্পষ্টভাবে ঘোষণা করা উচিত। নিয়মগুলো এখনও উপকারী, তবে বহনযোগ্যতার নিষ্পত্তি করে না। তৈরি করা অ্যাপ্লিকেশন প্রকাশ্য নির্ভরতা ঘোষণা করলেও নিজস্ব পরিচয় ব্রোকার, ডিপ্লয়মেন্ট মেটাডেটা, হোস্টেড ফাংশন, বিল্ড প্লাগইন বা রানটাইম এন্ডপয়েন্টের ওপর নির্ভর করতে পারে। আপনার পরীক্ষায় এসব নির্ভরতা খুঁজে বের করে কোনগুলো প্রতিস্থাপন করা যায় তা শ্রেণিবদ্ধ করতে হবে।

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

এই গেটের ভেতর ডেটাবেস বহনযোগ্যতার আলাদা পরীক্ষা প্রাপ্য। PostgreSQL ডকুমেন্টেশন ব্যাখ্যা করে যে pg_dump একটি ডেটাবেস এক্সপোর্ট করে ও সামঞ্জস্যপূর্ণ স্ন্যাপশট দেয়, কিন্তু ভূমিকার মতো ক্লাস্টার-ব্যাপী অবজেক্ট এক্সপোর্ট করে না। শুধু অ্যাপ্লিকেশন ডেটাবেস রিস্টোর করা দল দেখবে মালিকানা ও অনুমতির ধারণাগুলো হারিয়ে গেছে। স্কিমা তৈরি, সিড ডেটা, ভূমিকা পুনর্নির্মাণ, এক্সটেনশন এবং এন্টারপ্রাইজ নিয়ন্ত্রিত PostgreSQL ইনস্ট্যান্সে রিস্টোর পরীক্ষা করুন।

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

অ্যাক্সেস নিয়ন্ত্রণকে সরাসরি অনুরোধেও টিকতে হবে

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

অ্যাপ্লিকেশন তৈরির আগে ভূমিকা ও রিসোর্স নির্ধারণ করুন। টেন্যান্ট সীমা এবং সংবেদনশীল কাজসহ ছোট অনুমতি ম্যাট্রিক্স ব্যবহার করুন:

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

OWASP Application Security Verification Standard 4.0 বিশ্বস্ত সার্ভিস স্তরে অ্যাক্সেস নিয়ন্ত্রণ যাচাই রাখে এবং ডিফল্টভাবে অ্যাক্সেস অস্বীকারের কথা বলে। তৈরি করা সিস্টেমে এই পরামর্শ আরও গুরুত্বপূর্ণ, কারণ পরিপাটি ইন্টারফেস মিথ্যা আস্থা দিতে পারে। আমি এমন দল দেখেছি যারা ভূমিকার ডেমো গ্রহণ করেছে, যেখানে সীমাবদ্ধ ব্যবহারকারীর এডিট বাটন ছিল না, পরে দেখে একই ব্যবহারকারী হাতে করে এডিট অনুরোধ পাঠাতে পারত।

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

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

OpenID Connect Core sub ক্লেইমকে ইস্যুকারীর মধ্যে স্থানীয়ভাবে অনন্য এবং কখনও পুনর্ব্যবহৃত না হওয়া আইডেন্টিফায়ার হিসেবে সংজ্ঞায়িত করে। পাঠযোগ্য লগইন নামের পাশাপাশি সেই স্থায়ী আইডেন্টিফায়ার সংরক্ষণ ও অডিট করুন। ইমেইল ঠিকানা ও প্রদর্শিত নাম বদলায়, তাই শুধু এগুলো ব্যবহার করলে মালিকানা ইতিহাস নষ্ট হতে পারে বা অ্যাকাউন্ট পুনর্ব্যবহারের পর দুই আলাদা মানুষকে একই ব্যক্তি মনে হতে পারে।

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

ডেটার অবস্থানের জন্য উপাদানভিত্তিক মানচিত্র দরকার

প্রতিটি গুরুত্বপূর্ণ কপি, প্রসেসর, স্থানান্তর, ব্যাকআপ ও সহায়তা পথের হিসাব দল দিতে পারলেই ডেটার অবস্থান পাস করে। অ্যাপ্লিকেশন ওয়ার্কলোডের জন্য দেশ বাছাই করা সেই ওয়ার্কলোডের অবস্থান প্রমাণ করে, সম্পর্কিত সব ডেটার অবস্থান নয়।

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

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

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

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

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

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

ডিপ্লয়মেন্টকে একটি ব্রাউজার সেশনের বাইরে পুনরাবৃত্তিযোগ্য হতে হবে

নথিবদ্ধ, পুনরাবৃত্তিযোগ্য প্রক্রিয়ায় নির্দিষ্ট রিভিশন রিলিজ করে প্রতিটি পরিবেশে ঠিক কী পৌঁছেছে প্রমাণ করা গেলে ডিপ্লয়মেন্ট পাস করে। সফল প্রিভিউ URL রিলিজ নিয়ন্ত্রণ প্রতিষ্ঠা করে না।

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

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

রিলিজ রেকর্ড এই সংক্ষিপ্ত রূপে রাখা যায়:

{
  "release_id": "rel-1042",
  "source_revision": "8f21c6a",
  "environment": "pilot-prod",
  "schema_version": "20260728_03",
  "requested_by": "oidc:00u81c",
  "approved_by": "oidc:00u19a",
  "result": "succeeded",
  "health_check": "passed"
}

ইচ্ছা করে ডিপ্লয়মেন্ট ব্যর্থ করুন। প্রয়োজনীয় সিক্রেট সরান, মাইগ্রেশন নষ্ট করুন, বাহ্যিক সার্ভিসে অ্যাক্সেস অস্বীকার করুন এবং হেলথ চেক ব্যর্থ করুন। সিস্টেম নিরাপদে থামবে, কোন ধাপ ব্যর্থ হয়েছে বলবে, ডায়াগনস্টিক প্রমাণ রাখবে এবং আংশিক রিলিজকে সুস্থ হিসেবে দেখাবে না। কেবল «failed» দেখানো ডিপ্লয়মেন্ট UI ঘটনায় অপারেটরকে অনুমান করতে বাধ্য করে।

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

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

রোলব্যাকে কোড, স্কিমা, ডেটা ও পার্শ্বপ্রতিক্রিয়া থাকতে হবে

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

অনুশীলনের আগে রিকভারি টাইম অবজেক্টিভ ও রিকভারি পয়েন্ট অবজেক্টিভ ঠিক করুন। রিকভারি টাইম বলে সার্ভিস কতক্ষণ বিঘ্নিত থাকতে পারে। রিকভারি পয়েন্ট বলে ব্যবসা কতটা কমিট করা ডেটা হারাতে পারে। দল প্রায়ই বলে «রোলব্যাকে ছয় মিনিট লেগেছে», কিন্তু সাম্প্রতিক রেকর্ড উধাও হয়েছে কি না দেখে না, ফলে অর্ধেক ফলই জানায়।

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

সাধারণত প্রথম ব্যর্থতা দেখা দেয় যখন সংস্করণ A, সংস্করণ B-এর স্কিমার সঙ্গে চালু হয়। পুরোনো কোড এমন কলাম আশা করে যা মাইগ্রেশনে সরানো হয়েছে। তাই শুধু অ্যাপ্লিকেশন রিস্টোর করলে দ্বিতীয় আউটেজ হয়। ডেটাবেস স্ন্যাপশট রিস্টোরে সংস্করণ A ফিরতে পারে, তবে স্ন্যাপশটের পর কমিট হওয়া রেকর্ড বাদ পড়তে পারে। ইন্টিগ্রেশনে idempotency ব্যবস্থা না থাকলে রেকর্ড রিপ্লে করে বাহ্যিক নোটিফিকেশন নকল হতে পারে।

প্রতিটি রিলিজে একই পদ্ধতি চলবে ধরে না নিয়ে দলকে রিকভারি নকশা বেছে নিতে হবে। সামঞ্জস্যপূর্ণ expand and contract মাইগ্রেশন পুরোনো ও নতুন কোডকে একই স্কিমায় চলতে দিতে পারে। অপরিবর্তনীয় ডেটা রূপান্তরের পর উল্টে দেওয়ার চেয়ে সামনের দিকে মেরামত নিরাপদ হতে পারে। স্ন্যাপশট রিস্টোর কাজ করতে পারে, যখন ব্যবসা তার রিকভারি পয়েন্ট মেনে নেয় এবং দল রিপ্লে পরীক্ষা করেছে। কোন মাইগ্রেশন শ্রেণিতে কোন পদ্ধতি প্রযোজ্য নথিবদ্ধ করুন।

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

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

অডিট রেকর্ডে বিতর্কিত কাজ পুনর্গঠন করা সম্ভব হতে হবে

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

NIST SP 800-53 Revision 5, AC-2-তে অ্যাকাউন্ট ব্যবস্থাপনা আর AU নিয়ন্ত্রণে ইভেন্ট লগিং ও অডিট রেকর্ড তৈরিকে আলাদা করেছে। এ বিভাজন যুক্তিসংগত। পরিচয় প্রশাসন নির্ধারণ করে কোন প্রিন্সিপালের অ্যাক্সেস ছিল, আর অডিট তৈরি নথিবদ্ধ করে সে প্রিন্সিপাল কীভাবে তা ব্যবহার করেছে। বিতর্কিত ডিপ্লয়মেন্ট বা ডেটা এক্সপোর্ট তদন্তে দুই ইতিহাসই দরকার।

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

একটি উপকারী ইভেন্ট এমন হবে:

{
  "event": "role.assignment.changed",
  "time": "2026-07-28T14:03:22Z",
  "actor_sub": "oidc:00u81c",
  "actor_role": "platform-admin",
  "tenant": "tenant-204",
  "target": "user-771",
  "change": {"from": "viewer", "to": "manager"},
  "outcome": "success",
  "request_id": "req-9918",
  "approval_id": "apr-118"
}

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

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

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

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

ডেভেলপার হ্যান্ডঅফ গোপন প্ল্যাটফর্ম নির্ভরতা প্রকাশ করে

পাইলট তৈরি করেননি এমন ডেভেলপার মূল নির্মাতা বা প্ল্যাটফর্ম ছাড়াই এক্সপোর্ট করা অ্যাপ্লিকেশন রক্ষণাবেক্ষণ ও রিলিজ করতে পারলে ডেভেলপার হ্যান্ডঅফ পাস করে। কোডের পাঠযোগ্যতা গুরুত্বপূর্ণ, কিন্তু সফল মালিকানা হস্তান্তর আরও শক্ত পরীক্ষা।

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

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

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

পুনরুৎপাদনের দিকে বিশেষ নজর দিন। এক্সপোর্টের পর প্রচলিত কোড সম্পাদনা করুন, সমর্থন থাকলে প্রজেক্ট ইমপোর্ট বা পুনঃসংযোগ করুন, তারপর কাছাকাছি প্ল্যাটফর্ম-তৈরি পরিবর্তনের অনুরোধ করুন। প্ল্যাটফর্ম হাতে করা সম্পাদনা সংরক্ষণ, পুনর্লিখন, নকল, না নীরবে বিরোধ করে তা নির্ধারণ করুন। মানুষ ও তৈরি কাজের মিশ্রণের ঘোষিত অপারেটিং মডেল দলের দরকার। «ডেভেলপাররা কোড সম্পাদনা করতে পারেন» বললে পরের তৈরির সময় কী হয়, তা বোঝায় না।

অ্যাপ্লিকেশনে পুনরাবৃত্তিযোগ্য টেস্ট না থাকলে, ডেটা মডেল কেবল চ্যাট ইতিহাসে থাকলে, তৈরি মডিউলের স্থায়ী সীমা না থাকলে, হাতে করা পরিবর্তন হারিয়ে গেলে, বা প্রথম নির্মাতার অ্যাকাউন্ট ছাড়া ডিপ্লয়মেন্ট না হলে হ্যান্ডঅফ ফেল। একই সিস্টেমের তৈরি ডকুমেন্টেশন সাহায্য করতে পারে, কিন্তু গ্রহণকারী ডেভেলপারকে কোড ও রানটাইমের সঙ্গে তা যাচাই করতে হবে।

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

চুক্তিতে প্রমাণিত বিষয়গুলো সংরক্ষিত থাকা উচিত

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

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

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

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

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

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

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