কখন একটি নো-কোড টুল বদলানো উচিত?

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

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

টুলটি কি ডেলিভারি আটকে দিচ্ছে, নাকি শুধু দলকে বিরক্ত করছে?

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

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

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

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

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

সোর্স এক্সপোর্টকে মালিকানার পরীক্ষা পাস করতে হবে

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

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

দৃশ্যমান ফলসহ একটি চেকলিস্ট ব্যবহার করুন:

1. নথিভুক্ত একটি কমান্ড থেকে, নির্দিষ্ট সংস্করণের নির্ভরতা নিয়ে রিপোজিটরি ইনস্টল হয়।
2. ডেটাবেস স্কিমা ও মাইগ্রেশন প্রোডাকশনে ব্যবহৃত একই কাঠামো তৈরি করে।
3. প্রমাণীকরণ, ফাইল স্টোরেজ, নির্ধারিত কাজ, ইমেইল ও বাইরের সেবার স্পষ্ট কনফিগারেশন পয়েন্ট আছে।
4. যে ব্যবসায়িক নিয়মগুলো আবার খুঁজে বের করা ব্যয়বহুল হবে, পরীক্ষা সেগুলো কভার করে।
5. বিল্ডারের বাইরে ডেপ্লয় করা সংস্করণ এমন কোনো ব্যক্তিগত রানটাইমে কল না করেও স্মোক টেস্ট পরিবেশন করতে পারে যা কেবল ভেন্ডর দেয়।

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

প্রতিটি সম্ভাব্য এক্সপোর্টের পরে রিপোজিটরির এই ছোট পরিদর্শন চালান:

find . -type f | sort
find . -type f \( -name '*.env*' -o -name '*migration*' -o -name '*schema*' \) | sort
grep -R "https://\|vendor-runtime\|TODO" .

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

ডেটা পোর্টেবিলিটি সারি ডাউনলোডের চেয়েও বেশি কিছু

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

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

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

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

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

entity,source_count,target_count,status
customers,1842,1842,pass
orders,9714,9714,pass
attachments,2281,2279,fail

সংযুক্তির ওই ব্যর্থ সংখ্যা থেকেই বোঝা যায় দল কেন মহড়া দেয়। পরিমাপ করা ইমপোর্ট ছাড়া পুরোনো অ্যাকাউন্ট বাতিল করার পর মানুষ অনুপস্থিত নথি খুঁজে পায়।

ওয়ার্কফ্লোর জটিলতাই আগে সীমা প্রকাশ করে

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

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

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

প্রচলিত ব্যাকএন্ডে কাজটির স্পষ্ট চুক্তি দেওয়া যায়:

POST /orders/817/charge
Idempotency-Key: 817-approved-v3

202 Accepted
{"operation_id":"op_2941","status":"pending"}

গুরুত্বপূর্ণ বিষয়টি এন্ডপয়েন্টের সিনট্যাক্স নয়। সার্ভার idempotency key সংরক্ষণ করে, পুনরায় চেষ্টায় একই অপারেশন ফেরত দেয় এবং একজন worker-কে চার্জ শেষ করতে দেয়। নেটওয়ার্ক অনুরোধ তাৎক্ষণিক বলে ভান না করে ইন্টারফেস pending, succeeded বা failed দেখাতে পারে।

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

কাস্টম ইন্টিগ্রেশনে কানেক্টরের সংখ্যা নয়, চুক্তি দরকার

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

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

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

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

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

ডেভেলপার হস্তান্তর ডেভেলপার আসার আগেই শুরু হয়

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

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

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

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

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

ধাপে ধাপে মাইগ্রেশন সাধারণত পুনর্লিখনের চেয়ে ভালো

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

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

নিরাপদ ধারাবাহিকতায় চারটি ধাপ থাকে:

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

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

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

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

কিছু সীমিত ক্ষেত্রে পুনর্লিখন যুক্তিযুক্ত

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

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

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

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

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

চুক্তি ও কমপ্লায়েন্স সময়সীমা এগিয়ে দিতে পারে

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

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

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

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

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

গ্রহণযোগ্যতার নথি হিসেবে একটি ছোট অনুমতি ম্যাট্রিক্স ব্যবহার করুন:

operation,member,manager,administrator
view_own_order,allow,allow,allow
approve_discount,deny,allow,allow
export_all_customers,deny,deny,allow

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

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

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

সাবস্ক্রিপশন মূল্য নয়, মোট মালিকানা ব্যয় তুলনা করুন

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

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

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

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

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

পাইলটের প্রমাণ দিয়ে সিদ্ধান্ত নিন

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

পাইলটের আগে সম্মত পাস বা ফেল মানদণ্ডে ফল মূল্যায়ন করুন:

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

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

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

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

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

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