রপ্তানি করা সোর্স কোডকে স্পষ্ট গভর্ন্যান্স নীতিতে সঙ্গত রাখুন

আপনি কোন সমস্যা সমাধান করছেন (সরল ভাষায়)

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

সত্যিকারের লক্ষ্য কখনই "কখনই কোড এক্সপোর্ট না করা" নয়। লক্ষ্য হলো ভিজ্যুয়াল মডেলকে সত্যের উৎস হিসাবে রাখা যাতে পরিবর্তনগুলো ধারাবাহিক এবং পুনরাবৃত্তিযোগ্য থাকে। AppMaster-এ সেই মডেলে আপনার ডেটা স্কিমা, ব্যবসায়িক প্রসেস, API এন্ডপয়েন্ট এবং UI স্ক্রিনগুলো থাকে। মডেল সঠিক থাকলে, রিজেনারেশন একটি ঝুঁকিমুক্ত রুটিন অ্যাকশন হয়ে যায় স্ট্রেসফুল ইভেন্টের পরিবর্তে।

"Exported source code" সাধারণত জেনারেট করা Go ব্যাকএন্ড, Vue3 ওয়েব অ্যাপ এবং Kotlin/SwiftUI মোবাইল অ্যাপগুলোকে নিয়ন্ত্রণে নিয়ে আসা বোঝায়। দলগুলো বাস্তব কারণে এক্সপোর্ট করে: সিকিউরিটি রিভিউ, সেলফ-হোস্টিং, কাস্টম ইনফ্রাস্ট্রাকচার নিয়ম, বিশেষ ইন্টিগ্রেশন, বা প্ল্যাটফর্মের বাইরে দীর্ঘমেয়াদি মেইনটেনেন্স।

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

গভর্ন্যান্স মূলত প্রক্রিয়া, টুলিং নয়। এটি কয়েকটি মৌলিক প্রশ্নের উত্তর দেয়:

• ম্যানুয়াল পরিবর্তন কোথায় অনুমোদিত এবং কোথায় নিষিদ্ধ?
• ভিজ্যুয়াল মডেল বনাম রপ্তানি রিপোতে পরিবর্তন কারা অনুমোদন করতে পারবে?
• কেন কোনো পরিবর্তন কোডে করা হয়েছে মডেলে না— তা কিভাবে রেকর্ড করা হবে?
• যখন রিজেনারেশন কাস্টম এক্সটেনশনের সাথে সংঘর্ষ করে তখন কি হবে?

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

সত্যের উৎস নির্বাচন করুন এবং তা মেনে চলুন

রিজেনারেটিং প্ল্যাটফর্মের সাথে রপ্তানি করা সোর্স কোড সিংক রাখতে হলে আপনাকে একটি স্পষ্ট ডিফল্ট নির্ধারণ করতে হবে: পরিবর্তনগুলো কোথায় থাকবে?

AppMaster-এর মতো প্ল্যাটফর্মগুলির জন্য, সবচেয়ে নিরাপদ ডিফল্ট সহজ: ভিজ্যুয়াল মডেলই সত্যের উৎস। পণ্য প্রতিদিন কী করে তা নির্ধারণকারী জিনিসগুলো মডেলে থাকা উচিত, রপ্তানি করা রিপোতে নয়। এতে সাধারণত আপনার ডেটা মডেল, ব্যবসায়িক লজিক, API এন্ডপয়েন্ট এবং প্রধান UI ফ্লোতে পড়ে।

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

একটি নীতি যা অধিকাংশ দল অনুসরণ করতে পারে:

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

উদ্দেশ্যগতভাবে অনুমোদিত জোনটি ছোট রাখুন। এটি যত বড় হবে, রিজেনারেশন তত বেশি পরিবর্তন ও গোপন ড্রিফট ওভাররাইট করবে।

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

কখন কোড এক্সপোর্ট করা বোধগম্য (এবং কখন নয়)

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

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

কী প্রশ্নটি হল: আপনি কি কোড অ্যাক্সেস চান না কি কোড এডিট?

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

রিড-অনলি এক্সপোর্ট সহজ কারণ আপনি ঘন ঘন রিজেনারেট করতে পারেন ম্যানুয়াল এডিট ওভাররাইট হওয়ার চিন্তা ছাড়া।

এডিটেবল এক্সপোর্টেই দলগুলো ঝামেলায় পড়ে। দীর্ঘস্থায়ী ম্যানুয়াল পরিবর্তন একটি গভর্ন্যান্স সিদ্ধান্ত, ডেভেলপার প্রেফারেন্স নয়। যদি আপনি উত্তর না দিতে পারেন "এই পরিবর্তনটি এক বছরে কোথায় থাকবে?", আপনি ড্রিফটে পড়বেন: মডেল এক কথা বলে, প্রোডাকশন কোড অন্য কথা বলে।

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

রিজেনারেশন আপনাকে ভাঙা না করুক—নিরাপদ এক্সটেনশন পয়েন্ট ডিজাইন করুন

কখনও জেনারেট করা ফাইলকে "শুধু একটু পরিবর্তন করে নেই" জায়গা মনে করবেন না। রিজেনারেশন শেষ পর্যন্ত জিতবে।

শুরু করুন মডেল যে অংশটি নিয়ন্ত্রণ করে এবং আপনার টিম যে অংশ নিয়ন্ত্রণ করে—এসবের মধ্যে একটি কঠোর লাইন টেনে। AppMaster-এর ক্ষেত্রে, মডেল ব্যাকএন্ড (Go), ওয়েব (Vue3) এবং মোবাইল (Kotlin/SwiftUI) কোড পুনরায় জেনারেট করতে পারে, তাই ধরে নিন জেনারেটেড এরিয়ায় থাকা যেকোনো জিনিস যেকোনো সময় প্রতিস্থাপিত হতে পারে।

এমন সীমানা তৈরি করুন যা ডাকা কঠিন

রিপো ও অভ্যাসে সীমানাটি সুস্পষ্ট করুন। যখন সঠিক কাজটি অসুবিধাজনক হয়, মানুষ ভুল কাজ করে ফেলে।

কিছু কার্যকর গার্ডরেইল:

• জেনারেটেড আউটপুটকে একটি নির্দিষ্ট ফোল্ডারে রাখুন যাকে রিড-অনলি হিসাবে বিবেচনা করা হয়।
• কাস্টম কোড আলাদা ফোল্ডারে রাখুন যার নিজস্ব বিল্ড এন্ট্রি পয়েন্ট আছে।
• কাস্টম কোডকে জেনারেটেড কোডকে কেবল পাবলিক ইন্টারফেস দিয়ে কল করতে বাধ্য করুন (ইন্টার্নাল ফাইল না)।
• CI চেক যোগ করুন যা ব্যর্থ হবে যদি "do not edit" ফাইল পরিবর্তিত হয়।
• জেনারেটেড ফাইলগুলিতে হেডার কমেন্ট যোগ করুন যা স্পষ্টভাবে বলে দেবে সেগুলো ওভাররাইট হবে।

শেষটিও গুরুত্বপূর্ণ। একটি পরিষ্কার "DO NOT EDIT: regenerated from model" বা সমতুল্য বার্তা ভবিষ্যতে ভালো ইচ্ছার ফিক্সগুলোকে ভবিষ্যৎ ব্রেকেজ থেকে আটকায়।

এডিটের বদলে র‍্যাপার পছন্দ করুন

কাস্টম আচরণ দরকার হলে, জেনারেটেড কোড পরিবর্তন করার বদলে সেটি র‍্যাপ করুন। ভাবুন "অ্যাডাপ্টার লেয়ার" বা একটি পাতলা ফ্যাসাদ হিসেবে যা আপনার অ্যাপ ও জেনারেটেড অংশের মধ্যে বসে।

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

1. জেনারেটেড এন্ডপয়েন্ট অপরিবর্তিত রাখুন।

2. একটি কাস্টম সার্ভিস যোগ করুন (আপনার কাস্টম এরিয়াতে) যা ইনভেন্টরি API কল করে।

3. জেনারেটেড লজিককে আপনার সার্ভিসকে স্থিতিশীল ইন্টারফেসের মাধ্যমে কল করতে বলুন, যেমন একটি ছোট প্যাকেজে InventoryClient মত একটি ইন্টারফেস।

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

যেখানে সম্ভব, স্থিতিশীল ইন্টিগ্রেশন পয়েন্ট ব্যবহার করুন

কাস্টম কোড লেখার আগে দেখুন আপনি কি API, webhook বা প্ল্যাটফর্ম মডিউলের মতো স্থিতিশীল হুক ব্যবহার করে আচরণ জোড়া দিতে পারেন। উদাহরণস্বরূপ, AppMaster-এ Stripe পেমেন্ট এবং Telegram বা ইমেইল/SMS মডিউল রয়েছে। স্থিতিশীল ইন্টিগ্রেশন পয়েন্ট ব্যবহার করলে রিজেনারেশন দমকে দেয়া সহজ হয়।

একটি ছোট পৃষ্ঠা জেনারেট না-এডিট জোনগুলো ডকুমেন্ট করুন এবং অটোমেশনের মাধ্যমে এরা কার্যকর করুন। মাথায় রাখা নিয়মগুলো কেবল মানুষের মনে থাকলে ডেডলাইন পাস হলে বেঁচে থাকেনা।

এমন রিপোজিটরি গঠন যা রিজেনারেশন টিকে থাকে

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

AppMaster-এর মত একটি প্ল্যাটফর্ম থেকে এক্সপোর্ট করলে, এক্সপোর্টকে একটি পুনরাবৃত্তিযোগ্য বিল্ড আর্টিফ্যাক্ট হিসেবে বিবেচনা করুন, এককালীন হ্যান্ডঅফ হিসেবে নয়।

একটি ব্যবহারিক কাঠামো মালিকানা এবং লাইফসাইকেল দ্বারা কোড আলাদা করে:

• generated/ (অথবা appmaster_generated/): যা কিছু পুনরায় জেনারেট করা যেতে পারে। কোনো ম্যানুয়াল এডিট নয়।
• custom/: সব হাতে লেখা এক্সটেনশন, অ্যাডাপ্টার, এবং glue কোড।
• config/: এনভায়রনমেন্ট টেমপ্লেট, ডিপ্লয়মেন্ট সেটিংস, সিক্রেট প্লেসহোল্ডার (বাস্তব সিক্রেট নয়)।
• scripts/: অটোমেশন যেমন "regen + patch + test"।
• docs/: রিপোর জন্য একটি সংক্ষিপ্ত নিয়ম পৃষ্ঠা।

নামকরণ কনভেনশন সাহায্য করে যখন মানুষ তাড়াহুড়ো করছে। কাস্টম অংশগুলোর জন্য একটি ধারাবাহিক প্রিফিক্স ব্যবহার করুন (উদাহরণ, custom_ বা ext_) এবং জেনারেটেড লেআউট কেবল সেখানে মিরর করুন যেখানে তা বাস্তবে সাহায্য করে। যদি আপনি লোভ বোধ করেন যে একটি জেনারেটেড ফাইল "শুধু এই একবার" স্পর্শ করবেন, থামুন এবং সেই পরিবর্তন custom/ এ নিন বা সম্মত এক্সটেনশন পয়েন্টে সরান।

ব্রাঞ্চিংও একই পৃথকীকরণ প্রতিফলিত করা উচিত। অনেক দল দুই রকম কাজ প্রদর্শন করে রাখে: মডেল-চালিত পরিবর্তন (ভিজ্যুয়াল মডেল আপডেট যা কোড রিজেনারেট করবে) এবং কাস্টম-কোড পরিবর্তন (এক্সটেনশন ও ইন্টিগ্রেশন)। এমনকি একটি একক রিপোতে, PR লেবেল বা ব্রাঞ্চ নামকরণ model/* এবং custom/* রাখলে রিভিউ স্পষ্ট হয়।

রিলিজের ক্ষেত্রে, "ফ্রেশ রিজেনারেশন"কে অপ্রতিহত করুন। রিলিজ ক্যান্ডিডেট শুরু হওয়া উচিত generated/-এ পুনরায় জেনারেট করে, যে কোন স্ক্রিপ্টেড প্যাচ পুনরায় প্রয়োগ করে, তারপর টেস্ট চালিয়ে। যদি এটি স্ক্র্যাচ থেকে পুনর্নির্মান না করা যায়, রিপো ইতিমধ্যে ড্রিফট করছে।

ধাপে ধাপে ওয়ার্কফ্লো যাতে মডেল ও কোড সংরক্ষণ থাকে

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

একটি কার্যকর ওয়ার্কফ্লো:

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

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

গভর্ন্যান্স নিয়ম: ভূমিকা, অনুমোদন ও পরিবর্তন নিয়ন্ত্রণ

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

কয়েকটি মালিক নির্দিষ্ট করুন। আপনাকে একটি কমিটি দরকার নেই, কিন্তু স্পষ্টতা দরকার।

• Model maintainer: ভিজ্যুয়াল মডেলটির মালিক এবং ডেটা, API, কোর লজিকের জন্য সত্যের উৎস রক্ষা করে।
• Custom code maintainer: হাতে লেখা এক্সটেনশন এবং সুরক্ষিত এক্সটেনশন বাউন্ডারির মালিক।
• Release owner: ভার্সনিং, রিজেনারেশন সময়সমন্বয় এবং প্রোডাকশনে কী যায় তা সমন্বয় করে।

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

পরিবর্তন নিয়ন্ত্রণের জন্য একটি ছোট চেঞ্জ রিকোয়েস্ট ফর্ম রাখুন যাকে কেউই দ্রুত পূরণ করতে পারে। এটিকে যথেষ্ট দ্রুত রাখুন যাতে মানুষ সত্যিই ব্যবহার করে।

• কি বদলেছে (মডেল, জেনারেটেড কোড সেটিংস, বা কাস্টম এক্সটেনশন)
• কেন বদলেছে (ইউজার চাহিদা বা ইন্সিডেন্ট)
• ঝুঁকি (কি ভাঙতে পারে, কে প্রভাবিত হবে)
• রোলব্যাক প্ল্যান (কিভাবে নিরাপদে পূর্বাবস্থায় ফিরানো যায়)
• কিভাবে যাচাই করবেন (এক বা দুই চেক)

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

ওভাররাইট এবং ড্রিফটের সাধারণ ভুলগুলো

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

ড্রিফট উদ্রেককারী প্যাটার্নগুলো

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

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

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

একটি আরও নীরব ভুল হল কোন মডেল ভার্সন কোন এক্সপোর্ট উৎপন্ন করেছে তা না রেকর্ড করা। একটি সহজ ট্যাগ বা রিলিজ নোট ছাড়া, আপনি মৌলিক প্রশ্নের উত্তর দিতে পারবেন না: "এই API আচরণ মডেল থেকে এসেছে নাকি কাস্টম প্যাচ থেকে?"

একটি দ্রুত উদাহরণ

একজন ডেভেলপার একটি মিসিং ভ্যালিডেশন দেখে জেনারেট করা Go হ্যান্ডলার সরাসরি এডিট করে ফাঁকা ভ্যালু ব্লক করে। এটি টেস্ট পাস করে এবং শিপ হয়। দুই সপ্তাহ পরে, টিম একটি AppMaster Business Process আপডেট করে এবং আবার এক্সপোর্ট করে। হ্যান্ডলার পুনরায় জেনারেট হয়, ভ্যালিডেশন gone, এবং বাগ ফিরে আসে।

প্রারম্ভিক সতর্কতা চিহ্ন:

• কাস্টম কমিটগুলো জেনারেটেড ডিরেক্টরির ভিতরে ল্যান্ড করা
• এক্সটেনশনের জন্য কোনও লিখিত নিয়ম নেই
• "আমরা এই রিলিজটা রিজেনারেট করতে পারছি না" স্বাভাবিক হয়ে ওঠা
• রিলিজগুলো মডেল ভার্সন উল্লেখ না করা
• কেবল কোডেই বিদ্যমান ফিক্স যা ভিজ্যুয়াল মডেলে নেই

ড্রিফট আগে ধরার কোয়ালিটি চেক

প্রতিটি রিজেনারেশনকে ছোট একটি রিলিজের মতো বিবেচনা করুন। আপনি শুধুমাত্র যাচাই করছেন না যে অ্যাপটি চালু হয় কিনা; আপনি যাচাই করছেন যে ভিজ্যুয়াল মডেল (উদাহরণ: আপনার AppMaster Data Designer এবং Business Process Editor) এখনও আপনার রিপো যা ডিপ্লয় করে তার সাথে মেলে।

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

কয়েকটি ফোকাসড চেক যা সহজে পুনরাবৃত্তি করা যায়:

• টপ 3 থেকে 5 ইউজার ফ্লোর জন্য স্মোক টেস্ট (ওয়েব ও মোবাইল যদি দুটোই শিপ করেন)
• কী API এর জন্য কনট্রাক্ট চেক (রিকোয়েস্ট/রেসপন্স শেপ) ও গুরুত্বপূর্ণ ইন্টিগ্রেশন যেমন Stripe বা Telegram
• এক্সপোর্টের পরে ডিফ রিভিউ যা কাস্টম ফোল্ডারগুলোর দিকে ফোকাস করে, জেনারেটেড এরিয়াতে নয়
• একটি রোলব্যাক ড্রিল: নিশ্চিত করুন আপনি দ্রুত শেষজন্য ভাল বিল্ড পুনরায় ডিপ্লয় করতে পারেন
• ভার্সন লগিং: মডেল ভার্সন, এক্সপোর্ট ডেট, এবং যে কমিট ট্যাগ ডিপ্লয় করেছে

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

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

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

উদাহরণ: কাস্টম ইন্টিগ্রেশন যোগ করা কিন্তু রিজেন-এ হারানো না হওয়া

ধরা যাক আপনার টিম AppMaster-এ একটি কাস্টমার পোর্টাল তৈরি করেছে কিন্তু একটি ন্যাচ সিমএস প্রোভাইডারের জন্য কাস্টম মেসেজিং ইন্টিগ্রেশন দরকার যা বিল্ট-ইন মডিউলে নেই। আপনি প্রোভাইডার SDK যোগ করতে সোর্স কোড এক্সপোর্ট করেন এবং কয়েকটি এজ কেস হ্যান্ডেল করেন।

পরে ব্যথা থেকে রক্ষা করার নিয়মটি সহজ: ভিজ্যুয়াল মডেলকে ডেটা, API এন্ডপয়েন্ট, এবং কোর ফ্লোর জন্য সত্যের উৎস হিসেবে রাখুন। কাস্টম প্রোভাইডার কোড একটি অ্যাডাপ্টার লেয়ারে রাখুন যা জেনারেটেড কোড কল করে কিন্তু সেটি মালিক নয়।

একটি পরিষ্কার বিভাজন দেখায়:

• ভিজ্যুয়াল মডেল (AppMaster): ডাটাবেস ক্ষেত্র, API এন্ডপয়েন্ট, authentication নিয়ম, এবং কখন একটি মেসেজ পাঠাবেন তা নির্ধারণ করা ব্যবসায়িক প্রসেস
• অ্যাডাপ্টার লেয়ার (হাতে লেখা): প্রোভাইডার ক্লায়েন্ট, রিকোয়েস্ট সাইনিং, রিট্রাই, এবং প্রোভাইডার এররগুলোকে ছোট স্থিতিশীল অ্যাপ এররসেটে ম্যাপ করা
• পাতলা বাউন্ডারি: একটি ইন্টারফেস SendMessage(to, text, metadata) যা ব্যবসায়িক প্রসেস ট্রিগার করে

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

রিভিউ ও টেস্ট আপনাকে ট্রাইবাল নলেজের উপর নির্ভর করা থেকে রক্ষা করে। একটি ভালো মিনিমাম:

• কেউ জেনারেটেড ফোল্ডারে সরাসরি এডিট করেনি তা চেক
• অ্যাডাপ্টারের জন্য ইউনিট টেস্ট (হ্যাপি পাথ, প্রোভাইডার টাইমআউট, অবৈধ নম্বর)
• রিজেনারেশনের পরে চালানো ইনটিগ্রেশন টেস্ট যা নিশ্চিত করে মেসেজটি পাঠানো হচ্ছে

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

পরবর্তী ধাপ: একটি ব্যবহারিক রোলআউট প্ল্যান (হালকা টুল নোটসহ)

ছোট থেকে শুরু করুন এবং লিখে রাখুন। একটি এক-পৃষ্ঠার নীতিই যথেষ্ট যদি এটি দুইটি প্রশ্নের উত্তর দেয়: রিপোতে কি পরিবর্তন করার অনুমতি আছে, এবং কি অবশ্যই ভিজ্যুয়াল মডেলে বদলানো দরকার। রিপো README-র পাশে একটি সীমারেখা ডায়াগ্রাম (এমনকি একটি স্ক্রিনশট) যোগ করুন যা কোন ফোল্ডার জেনারেটেড এবং কোনগুলো আপনার তা দেখায়।

তারপর একটি বাস্তব ফিচারে পাইলট চালান। কিছু মূল্যবান কিন্তু সীমাবদ্ধ পিলেক্ট করুন, যেমন একটি webhook যোগ করা, একটি ছোট এডমিন স্ক্রিন, বা একটি নতুন অনুমোদন ধাপ।

একটি ব্যবহারিক রোলআউট প্ল্যান:

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

টুল পছন্দ নোট: যদি আপনি AppMaster ব্যবহার করেন, ভিজ্যুয়াল মডেলকে ডেটা, API, এবং ব্যবসায়িক লজিকের জন্য ডিফল্ট জায়গা হিসেবে বিবেচনা করুন। এক্সপোর্ট করা কোড ডিপ্লয়মেন্ট প্রয়োজন (আপনার ক্লাউড, আপনার নীতি) বা সুক্ষ্মভাবে নিয়ন্ত্রিত এক্সটেনশনগুলোর জন্য ব্যবহার করুন, যেগুলো স্পষ্টভাবে পৃথক এলাকায় থাকে।

যদি আপনি AppMaster দিয়ে appmaster.io-তে নির্মাণ করে থাকেন, একটি ছোট নো-কোড প্রজেক্টে অনুশীলন করার অভ্যাস রাখুন: কোর অ্যাপ লজিক ভিজ্যুয়াল এডিটরগুলোতে তৈরি করুন, এক্সপোর্ট করুন, পুনরায় জেনারেট করুন, এবং আপনার সীমানাগুলো বড় সিস্টেমে যাওয়ার আগে প্রমাণ করুন।