মনোরেপো বনাম পলিরেপো: ওয়েব, মোবাইল, ব্যাকএন্ড কীভাবে সমন্বয় রাখবেন

বাস্তব সমস্যা: তিনটি কোডবেসে পরিবর্তন পাঠানো

টিমগুলো মনোরেপো বনাম পলিরেপো নিয়ে বিতর্ক করে কারণ তারা গিটের দর্শন নিয়ে ভাবছে না। তারা বিতর্ক করে কারণ একটি ছোট প্রোডাক্ট পরিবর্তন তিনটি আলাদা বদলায় পরিণত হয় — ওয়েব, মোবাইল, এবং ব্যাকএন্ড — এবং কোথাও না কোথাও কিছু ভেঙে যায়।

প্রথম যা ভেঙে পড়ে সেটা সাধারণত UI হয় না। সেটা প্রায়ই অদৃশ্য গ্লু: একটি API কনট্র্যাক্ট বদলেছে কিন্তু মিলছে না, একটি শেয়ার্ড লাইব্রেরি এক জায়গায় আপডেট হয়েছে কিন্তু অন্য জায়গায় হয়নি, বা বিল্ড পাইপলাইনে হঠাৎ নতুন ধাপ দরকার পড়ে। যখন একটি অংশ অন্যগুলোর চেয়ে আগে চলে যায়, ব্যবহারকারী সেটা বাগ হিসেবে দেখে — “ওয়েবে বোতাম আছে কিন্তু মোবাইল বলে অ্যানসাপোর্টেড” বা “অ্যাপ লোড হচ্ছে না কারণ ব্যাকএন্ড রেসপন্স বদলেছে।”

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

আপনি সম্ভবত রিপো সমন্বয় ট্যাক্স দিচ্ছেন যদি এগুলো বারবার ঘটে:

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

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

যদি প্রতিটি অর্থবহ পরিবর্তন তিন জায়গায় ল্যান্ড করতে হয়, আপনি কোনো না কোনোভাবে সেই ট্যাক্স দেবেন। রিপো কৌশল মূলত ঠিক করে যে আপনি কিভাবে তা দিতে চান।

মনোরেপো ও পলিরেপো — জার্গন নেই

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

একটি মনোরেপো একটি রিপো যেখানে একাধিক অ্যাপ এবং প্রায়শই শেয়ার্ড কোডও থাকে। ওয়েব, iOS/Android, ব্যাকএন্ড সার্ভিস এবং শেয়ার্ড লাইব্রেরিগুলো পাশাপাশি থাকে।

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

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

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

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

যদি আপনি এমন একটি প্ল্যাটফর্ম ব্যবহার করেন যা এক সোর্স অব ট্রুথ থেকে ব্যাকএন্ড, ওয়েব, এবং মোবাইল জেনারেট করে, তাহলে ড্রিফ্ট কমে কারণ কনট্র্যাক্ট ও লজিক একসাথে থাকে। উদাহরণস্বরূপ, AppMaster (appmaster.io) একক মডেল থেকে প্রোডাকশন-রেডি ব্যাকএন্ড, ওয়েব, এবং নেটিভ মোবাইল অ্যাপ জেনারেট করে। এটা রিলিজ বাস্তবতাগুলো দূর করে না (মোটােবাইল এখনও ধীরই থাকবে), কিন্তু অনেক “আমরা কি তিনটায় আপডেট করেছি?” ওভারহেড দূর করতে পারে।

ডিপেনডেন্সি ম্যানেজমেন্ট: শেয়ার্ড কোড নিরাপদ রাখা

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

যখন আপনি লাইব্রেরি শেয়ার করেন (UI কম্পোনেন্ট, ভ্যালিডেশন রুল, অঅথ হেলপার), তখন আপনি বেছে নিচ্ছেন সবার জন্য এক ভার্সন বা সময়কে ধরে একাধিক ভার্সন।

• একটি ভার্সন সহজ এবং "আমার ব্রাঞ্চে কাজ করছে" ধাঁধা কমায়।
• একাধিক ভার্সন টিমগুলোকে তাদের গতিতে এগোতে দেয়, কিন্তু ক্লাটার তৈরি করে এবং সিকিউরিটি ফিক্স রোল আউট করা কঠিন করে।

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

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

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

কয়েকটি নিয়ম যা ডিপেনডেন্সি আপডেটকে বোরিং (ভাল অর্থে) রাখে:

• কেডেন্সে আপডেট করুন। সাপ্তাহিক ছোট আপডেট চার মাসের বড়গুলোর চেয়ে ভালো।
• ব্রেকিং চেঞ্জের জন্য স্পষ্ট অনুমোদন প্রয়োজন, এবং একটি সংক্ষিপ্ত মাইগ্রেশন নোট লাগান।
• চেকগুলো অটোমেট করুন: ডিপেনডেন্সি বাম্প, ক্লায়েন্ট জেনারেশন, এবং মৌলিক কনট্র্যাক্ট টেস্ট।
• “ডান” সম্পন্ন হওয়ার সংজ্ঞা রাখুন: “ওয়েব, মোবাইল, এবং ব্যাকএন্ড বিল্ড সবুজ”, কেবল “আমার রিপো” পাস করেছে নয়।

জেনারেটেড কোড ড্রিফ্ট কমাতে পারে, কিন্তু এটা শৃঙ্খলা বদলে দেয় না। আপনার এখনও একটি কনট্র্যাক্ট, স্পষ্ট ডিপ্রেকেশন, এবং পূর্বনির্দিষ্ট আপডেট দরকার।

রিলিজ সমন্বয়: ওয়েব, মোবাইল, এবং ব্যাকএন্ড সারিবদ্ধ করা

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

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

টিমগুলো যে ভার্সনিং প্যাটার্নগুলো বাস্তবে ব্যবহার করে

অধিকাংশ টিম এই ধরনের একটি পন্থা বেছে নেয়:

1. একটি শেয়ার্ড রিলিজ ট্রেন: ওয়েব, মোবাইল, এবং ব্যাকএন্ড এক ভার্সন ইউনিট হিসেবে শিপ করে।

2. প্রতি-সার্ভিস ভার্সনিং ও কম্প্যাটিবিলিটি নিয়ম: প্রতিটি অ্যাপ/সার্ভিসের নিজস্ব ভার্সন থাকে, এবং ব্যাকএন্ড নির্দিষ্ট রেঞ্জের ক্লায়েন্ট ভার্সন সমর্থন করে।

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

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

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

কে রিলিজ ক্যালেন্ডারের মালিক

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

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

যদি আপনার ওয়ার্কফ্লো এক মডেল থেকে ওয়েব, মোবাইল, এবং ব্যাকএন্ড জেনারেট করে, তবুও রিলিজ মালিক লাগবে। আপনি সাধারণত কম “তিন জায়গায় আপডেট করেছি কি না?” মুহূর্ত পাবেন, কিন্তু মোবাইল টাইমিং থেকে মুক্ত হবেন না।

CI সময় নিয়ন্ত্রণে রাখা

CI ধীর হওয়ার কারণ দুই সেটাপেই একই: আপনি বেশি rebuild করছেন, বারবার ডিপেনডেন্সি ইনস্টল করছেন, এবং প্রতিটি চেঞ্জে সব টেস্ট চালাচ্ছেন।

সাধারণ টাইম কিলারগুলো: ছোট পরিবর্তনে ফুল বিল্ড, ক্যাশ মিস, টেস্ট স্যুট যা সব কিছু চালায়, এবং সিরিয়াল জব যা প্যারালেলে চালানো যেতে পারে।

শুরু করুন এমন উন্নতির সঙ্গে যা সবার জন্যই সাহায্য করে:

• ডিপেনডেন্সি ডাউনলোড ও বিল্ড আউটপুট ক্যাশ করুন।
• লিন্ট, ইউনিট টেস্ট, এবং বিল্ড প্যারালেলে চালান যেখানে সম্ভব।
• দ্রুত চেক (প্রতি কমিট) ও ধীর চেক (মেইন ব্রাঞ্চ, নাইটলি, অথবা প্রি-রিলিজ) আলাদা করুন।

মনোরেপো কৌশল যা সাহায্য করে

মনোরেপো কষ্টকর হয় যখন প্রতিটি কমিট "বিল্ড দ্য ওয়ার্ল্ড" পাইপলাইন ট্রিগার করে। সমাধান হলো শুধুমাত্র পরিবর্তিত অংশই বিল্ড ও টেস্ট করা।

পথ ফিল্টার ও affected-only পন্থা ব্যবহার করুন: যদি আপনি মোবাইল UI কোড বদলান, ব্যাকএন্ড ইমেজ বিল্ড করবেন না। যদি আপনি একটি শেয়ার্ড লাইব্রেরি বদলান, শুধুমাত্র সেই লাইব্রেরিতে নির্ভরশীল অ্যাপগুলো বিল্ড ও টেস্ট করুন। অনেক টিম সহজ একটি ডিপেনডেন্সি গ্রাফ formalize করে যাতে CI সিদ্ধান্ত নিতে পারে অনুমান না করে।

পলিরেপো কৌশল যা ড্রিফ্ট ঠেকায়

পলিরেপো দ্রুত হতে পারে কারণ প্রতিটি রিপো ছোট, কিন্তু তারা প্রায়শই টুলিং ও কনভেনশন অসামঞ্জস্যের কারণে সময় নষ্ট করে।

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

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

যদি আপনি সোর্স কোড এক্সপোর্ট করে আপনার নিজস্ব CI চালান, একই নিয়ম প্রযোজ্য: যা বদলেছে শুধু তাই বিল্ড করুন, ক্যাশ শক্তভাবে reuse করুন, এবং ধীর চেকগুলো সেগুলোয় রাখুন যেখানে তারা প্রকৃত মান দেয়।

ধাপে ধাপে: আপনার টিমের জন্য উপযুক্ত রিপো স্ট্র্যাটেজি বেছে নিন

দিন-প্রতি-দিনের কাজ থেকে শুরু করলে সিদ্ধান্ত সহজ হয়, আইডিয়োলজির না।

1) একসাথে কি কি বদলাতে হয় তা লিখে নিন

5–10টি সাম্প্রতিক ফিচার নিন এবং নোট করুন কোনগুলো একসাথে চলে। চিহ্ন দিন — UI স্ক্রিন, API এন্ডপয়েন্ট, ডেটা টেবিল, অটেনটিকেশন রুল, বা শেয়ার্ড ভ্যালিডেশন। যদি বেশিরভাগ ফিচার তিন জায়গাতেই সমন্বয় চায়, একটি বিভক্ত সেটআপ কষ্টকর হবে যদি না আপনার রিলিজ প্রসেস খুব শৃঙ্খলাবদ্ধ হয়।

2) শেয়ার্ড কোড ও সিদ্ধান্তগুলো ট্রেস করুন

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

3) সীমা ও মালিক নির্ধারণ করুন

নির্ধারণ করুন ইউনিটগুলো কী (অ্যাপ, সার্ভিস, লাইব্রেরি), তারপর প্রতিটি ইউনিটের মালিক চিহ্নিত করুন। সীমানাগুলো রিপো লেআউটের চেয়ে বেশি গুরুত্বপূর্ণ। মালিক ছাড়া, মনোরেপো গোলমেলে হয়ে যায়। মালিক ছাড়া, পলিরেপো বিচ্ছিন্ন হয়ে যায়।

সাধারণ চেকলিস্ট: প্রত্যেক ডেপ্লয়েবল সার্ভিস/অ্যাপের জন্য এক রিপো বা ফোল্ডার, শেয়ার্ড কনট্র্যাক্টের জন্য এক জায়গা, প্রকৃত শেয়ার্ড UI কম্পোনেন্টের জন্য এক জায়গা, ব্যবসায়িক লজিক কোথায় থাকবে তার স্পষ্ট নিয়ম, এবং প্রতিটির জন্য ডকুমেন্টেড মালিক।

4) একটি রিলিজ মডেল বেছে নিন যা আপনি অনুসরণ করতে পারেন

যদি মোবাইল রিলিজ ব্যাকএন্ড চেঞ্জের চেয়ে পিছিয়ে থাকে, একটি কম্প্যাটিবিলিটি পরিকল্পনা দরকার (ভার্সনড API, ব্যাকওয়ার্ড-কম্প্যাটিবল ফিল্ড, বা নির্দিষ্ট সাপোর্ট উইন্ডো)। যদি সবকিছু একসাথে শিপ করতে হবে, একটি রিলিজ ট্রেন কাজ করে, কিন্তু সমন্বয় বাড়ায়।

ব্রাঞ্চিং নিয়ম সহজ রাখুন: সংক্ষিপ্ত-বাচাই ব্রাঞ্চ, ছোট মার্জ, এবং স্পষ্ট হটফিক্স পথ।

5) সাধারণ চেঞ্জগুলোর চারপাশে CI ডিজাইন করুন

শুরুতেই সবচেয়ে খারাপ কেসের জন্য CI ডিজাইন করবেন না। দৈনন্দিন কাজে যা ঘটে তা অনুসারে ডিজাইন করুন।

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

উদাহরণ: একটি ফিচার যা ওয়েব, মোবাইল, এবং ব্যাকএন্ডে স্পর্শ করে

একটি ছোট টিমকে কল্পনা করুন যারা তিনটি জিনিস তৈরি করছে: একটি কাস্টমার পোর্টাল (ওয়েব), একটি ফিল্ড অ্যাপ (মোবাইল), এবং একটি API (ব্যাকএন্ড)। অনুরোধ আসে: কাজগুলিতে নতুন “Service status” ফিল্ড যোগ করুন এবং সব জায়গায় দেখান।

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

এবার প্রকৃত সমস্যা: API পরিবর্তনটি ভাঙ্গনকারী। ফিল্ডের নাম status থেকে service_status হয়, এবং পুরনো ক্লায়েন্টগুলো যদি হ্যান্ডেল না করে ভেঙে যায়।

মনোরেপোতে কি বদলে যায়

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

প্রধান ঝুঁকি সামাজিক—প্রযুক্তিগত নয়: এক রিপোতে ভাঙনকারী চেঞ্জ দ্রুত মার্জ করা সহজ, তাই আপনার রিভিউ নিয়ম শক্ত হওয়া উচিত।

পলিরেপোতে কি বদলে যায়

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

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

পছন্দ নেওয়ার সময় আপনার গত কয়েক মাস দেখুন:

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

সাধারণ ভুল ও ফাঁদ যা এড়াতে হবে

বেশিরভাগ টিম ভুল করে না কারণ তারা "ভুল" রিপো স্ট্রাকচার বেছে নিয়েছে। তারা তখন ব্যর্থ হয়ে পড়ে যখন দৈনন্দিন অভ্যাস ধীরে ধীরে ঘর্ষণ বাড়ায় যতক্ষণ প্রতিটি পরিবর্তন ঝুঁকিপূর্ণ মনে হয়।

শেয়ার্ড কোড ডাম্পিং গ্রাউন্ড হয়ে যায়

একটি শেয়ার্ড লাইব্রেরি লোভনীয়: হেলপার, টাইপ, UI টুকরা, "অস্থায়ী" ওয়ার্কঅ্যারাউন্ড। দ্রুতেই সেটা পুরনো কোড রাখার জায়গা হয়ে যায়, এবং কেউ জানে না কী নিরাপদভাবে পরিবর্তন করা যাবে।

শেয়ার্ড কোড ছোট ও কঠোর রাখুন। “শেয়ার্ড” মানে হওয়া উচিত বহু টিম ব্যবহার করে, সাবধানে রিভিউ করা হয়, এবং উদ্দেশ্য নিয়ে বদল করা হয়।

লুকানো অনুমানগুলো দিয়ে টাইট কাপলিং

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

উদাহরণ: মোবাইল status = 2 কে “Approved” ভাবে, ওয়েব এটাকে “Confirmed” ভাবে, ব্যাকএন্ড enum অর্ডার বদলে দেয়, এবং সবকিছু এমন ভাবে ভেঙে যায় যা র‍্যান্ডম মনে হয়।

এটা প্রতিরোধ করতে কনট্র্যাক্ট ডকুমেন্ট করুন (ফিল্ডগুলোর মানে কী, কোন ভ্যালু অনুমোদিত) এবং সেগুলোকে প্রোডাক্ট রুল হিসেবে দেখুন, trivia নয়।

অস্পষ্ট মালিকানা

যখন সবাই কিছুই নিজস্ব না মনে করে, রিভিউ হালকা হয়ে যায় এবং ভুল ছেড়ে যায়। যখন কেউই এলাকার মালিক নয়, বাগগুলো সপ্তাহ ধরে পড়ে থাকে।

ওয়েব, মোবাইল, ব্যাকএন্ড, এবং শেয়ার্ড মডিউলের মালিক নির্ধারণ করুন। মালিকানা অনুকূলতা বন্ধ করে না; বরং নিশ্চিত করে যে পরিবর্তনগুলো সঠিক চোখ দেখে।

CI ছাড়াই বৃদ্ধি

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

একটি সরল নিয়ম সাহায্য করে: প্রতিটি CI জবের একটি স্পষ্ট উদ্দেশ্য ও মালিক থাকতে হবে, এবং যদি তা বাস্তব সমস্যা ধরানো বন্ধ করে দেয় তবে তা সরিয়ে দিন।

সতর্কতাঃ duplicate টেস্ট, জব যা দিনগুলো ধরে লাল থাকে, “দ্রুত পরিবর্তন” যাচাই করতে বিল্ডের চেয়ে বেশি সময় নেয়, এবং এমন পাইপলাইন যা ব্যাকএন্ড-শুধু পরিবর্তনে মোবাইল বিল্ড ট্রিগার করে—এসব সিগন্যাল জানায় যে ক্লিনআপ দরকার।

রিলিজ সমন্বয় কেবল উপজাত জ্ঞান নির্ভর

যদি রিলিজগুলো এক ব্যক্তির মনে থাকা ক্রম ও গোপন জটিলতার ওপর নির্ভর করে, আপনি ধীর শিপ করবেন এবং বেশি ভাঙন ঘটবে।

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

রিপো পুনর্গঠন করার আগে দ্রুত চেক

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

পাঁচটি প্রশ্ন জিজ্ঞাসা করুন:

• স্বাধীনভাবে শিপিং: কি আপনি ব্যাকএন্ড ফিক্স রিলিজ করতে পারেন মোবাইল আপডেট বাধ্য না করে একই দিনে?
• API চেঞ্জ নিয়ম: কি আপনার কাছে ডিপ্রেকশন রুল এবং পুরনো আচরণ কতদিন সমর্থিত থাকবে তা লিখিত আছে?
• শেয়ার্ড কোড শৃঙ্খলা: শেয়ার্ড লাইব্রেরি (UI কম্পোনেন্ট, API ক্লায়েন্ট, বিজনেস রুল) কনসিসটেন্টভাবে রিভিউ ও ভার্সনিং করা হয় কি?
• CI যা গুরুত্বপূর্ণ চালায়: CI কি কী বদলেছে তা বলতে পারে এবং কেবল প্রভাবিত অংশগুলোর জন্য বিল্ড/টেস্ট চালায়?
• এক রিলিজ ভিউ: কি ওয়েব, মোবাইল, ও ব্যাকএন্ডে কী যাচ্ছে—এক জায়গায় দেখা যায়, মালিক ও তারিখসহ?

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

পরবর্তী ধাপ: সমন্বয় কাজ কমান এবং আত্মবিশ্বাসে শিপ করুন

লক্ষ্য কোনো “সঠিক” রিপো স্ট্রাকচার নয়। লক্ষ্য কম হ্যান্ডঅফ, কম বিস্ময়, এবং কম “কোন ভার্সন লাইভ?” মুহূর্ত।

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

ফাইল সরানোর আগে, সবচেয়ে ছোট বদল বেছে নিন যা বাস্তব ব্যথা কমায়:

• শেয়ার্ড প্যাকেজগুলোর জন্য ভার্সনিং নিয়ম যোগ করুন ও অনুসরণ করুন।
• API কনট্র্যাক্ট নির্ধারণ করুন এবং CI-তে কনট্র্যাক্ট টেস্ট বাধ্যত করুন।
• ওয়েব, মোবাইল, ও ব্যাকএন্ড জুড়ে একটি রিলিজ চেকলিস্ট মেনে নিন।
• একাধিক অংশ স্পর্শ করা পরিবর্তনের জন্য প্রিভিউ পরিবেশ ব্যবহার করুন।
• CI টাইম বাজেট নির্ধারণ করুন (উদাহরণ: PR চেক 15 মিনিটের কম)।

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

যদি আপনি সেই পন্থা অন্বেষণ করতে চান, AppMaster (appmaster.io) ব্যাকএন্ড সার্ভিস, ওয়েব অ্যাপ, এবং নেটিভ মোবাইল অ্যাপ জেনারেট করার জন্য তৈরি করা হয়েছে শেয়ার্ড ডেটা মডেল ও বিজনেস লজিক সহ। মূল্যায়ন করার নিম্ন-ঝুঁকি উপায় হলো প্রথমে একটি ছোট অভ্যন্তরীণ টুল বানিয়ে দেখুন, তারপর সিদ্ধান্ত নিন এটা আপনার সমন্বয় কাজ কতটা কমায়।

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