GitHub live migration এখন GA—repository চলবে, কিন্তু org settings যাবে না
GitHub-এর ১ সেপ্টেম্বরের release note অনুযায়ী, Enterprise Live Migrations বা ELM এখন সাধারণভাবে উপলভ্য; এটি GitHub Enterprise Server (GHES) থেকে data residency-সহ GitHub Enterprise Cloud (GHE.com)-এ repository সরায় এবং migration-এর অধিকাংশ সময় source-এ কাজ চালু রাখে। GA প্রকাশের সময় সমর্থিত ন্যূনতম patch ছিল GHES 3.17.18, 3.18.12, 3.19.9, 3.20.3, 3.21.3 ও 3.22.0। ১ সেপ্টেম্বরের স্বাধীন release index একই GA status, ধারাবাহিক synchronization, অল্প সময়ের cutover এবং বড় monorepo ব্যবহারের বিষয়টি নথিভুক্ত করেছে।
সুবিধাটির সীমানাও স্পষ্ট। GitHub-এর live migration documentation বলছে, একটি ELM migration কেবল একটি repository নেয়; organization settings, teams ও projects স্বয়ংক্রিয়ভাবে যায় না, cutover-এর সময় source repository read-only হয়, আর একটি GHES instance থেকে সর্বোচ্চ ১০টি ও একটি destination enterprise-এ সর্বোচ্চ ২০টি migration একসঙ্গে চালানো যায়। অর্থাৎ downtime অনেক কমানো সম্ভব, কিন্তু repository batching ও organization পুনর্গঠন migration দলের দায়িত্বেই থাকে।
Repository সচল থাকে, কিন্তু cutover শূন্য downtime নয়
ELM প্রথমে repository data backfill করে। এই পর্যায়ে webhook নতুন commit ও সমর্থিত পরিবর্তন শনাক্ত করে destination migration service-এ পাঠায়, ফলে দীর্ঘ initial copy চলার সময় developer-দের source repository ছেড়ে দিতে হয় না।
শেষ ধাপটি operator শুরু করেন। Cutover শুরু হলে source repository archive হয়ে read-only হয় এবং অবশিষ্ট পরিবর্তন destination-এ পাঠানো হয়; developer downtime এই interval-এ কেন্দ্রীভূত। তাই “near-zero downtime” বলতে দীর্ঘ code freeze এড়ানো বোঝায়, একেবারে বিরতিহীন migration নয়।
এই সীমা release ও incident-response পরিকল্পনায় গুরুত্বপূর্ণ। Backfill চলার সময় স্বাভাবিক কাজ সম্ভব হলেও cutover window-তে push, merge এবং write-নির্ভর automation বন্ধ থাকতে পারে। Repository owner, deployment owner ও incident coordinator-এর সম্মত সময় ছাড়া cutover শুরু করলে সংক্ষিপ্ত বিরতিও production কাজ আটকে দিতে পারে।
একটি repository ও দুই concurrency ceiling batch পরিকল্পনা নির্ধারণ করে
ELM organization বা একগুচ্ছ repository-কে একটি job হিসেবে নেয় না। প্রতিটি repository-র migration lifecycle, preflight ফল, owner, destination এবং cutover window আলাদাভাবে ধরতে হবে। ফলে inventory শুধু repository-র নামের তালিকা হলে যথেষ্ট নয়।
Source instance ও destination enterprise—দুটিই capacity key। শর্তসাপেক্ষ উদাহরণে, একটি GHES instance-এর ৮০টি repository অন্তত আটটি source-side batch চাইবে; তবে repository size, activity ও ব্যর্থ preflight-এর কারণে batchগুলো সমান সময়ে শেষ হবে না। একাধিক GHES instance একই destination-এ পাঠালে destination ceiling আগে পূর্ণ হতে পারে।
কার্যকর inventory-তে source instance, source organization, repository owner, destination organization, নির্বাচিত migration tool, আনুমানিক cutover window এবং নির্ভরশীল automation রাখা যায়। এতে কোন job কোন ceiling ব্যবহার করছে এবং একটি বিলম্ব পরের wave-কে কোথায় ঠেলে দেবে, তা আগেই দেখা যায়।
ELM বনাম GEI বাছাইয়ে repository inventory score
সব repository-র জন্য ELM বাধ্যতামূলক নয়। বড় ও সক্রিয় monorepo, গভীর Git history এবং দীর্ঘ read-only সময় সহ্য করতে না-পারা গুরুত্বপূর্ণ repository ELM থেকে বেশি সুবিধা পেতে পারে; স্বল্প নিয়ন্ত্রিত downtime গ্রহণযোগ্য সরল migration-এ GitHub Enterprise Importer বা GEI বিবেচনা করা যায়।
দলটি একটি repository inventory score ব্যবহার করে wave সাজাতে পারে। এটি GitHub-এর product requirement নয়, বরং operational অগ্রাধিকার নির্ধারণের একটি সম্পাদকীয় কাঠামো:
- Activity: commit, pull request ও release কত ঘন ঘন হয়।
- Downtime sensitivity: read-only অবস্থায় deployment, hotfix বা incident response কতটা বাধাগ্রস্ত হবে।
- Size and history: repository বা monorepo কত বড় এবং history কত গভীর।
- Dependency: bot, webhook, CI/CD এবং অন্য repository পুরোনো location-এর ওপর কতটা নির্ভরশীল।
প্রতিটি মাত্রায় শর্তসাপেক্ষে ০–২ দিলে মোট score হবে ০–৮। উচ্চ score-এর repository ELM wave-এ অগ্রাধিকার পেতে পারে, মাঝারি score pilot-এ এবং কম score GEI review-তে যেতে পারে। Score চূড়ান্ত সিদ্ধান্ত নয়; এটি downtime, জটিলতা ও dependency একই ভাষায় তুলনা করার উপায়।
Cutover runbook-এ অনুমোদন ও থামার শর্ত আগে লিখতে হবে
ELM GitHub CLI-এর gh elm extension দিয়ে পরিচালিত হয়। Site administrator source repository ও destination নির্ধারণ করে migration তৈরি করেন; preflight পর্যায়ে parameters, tokens, network connectivity এবং repository configuration যাচাই হয়। Backfill ও live update পর্যবেক্ষণের পর operator cutover শুরু করেন।
Production cutover runbook সংক্ষিপ্ত হলেও সিদ্ধান্তের মালিক ও যাচাইয়ের ধাপ স্পষ্ট হওয়া দরকার:
- Source GHES patch, destination enterprise, repository owner এবং source ও destination credentials যাচাই করুন।
- Preflight সফল এবং চলমান job উভয় concurrency ceiling-এর মধ্যে আছে কি না দেখুন। ব্যর্থ preflight নিয়ে cutover শুরু করবেন না।
- Repository owner, deployment owner ও incident channel-কে read-only window জানান; অনুমোদন এবং কোন অবস্থায় cutover থামবে তা লিখে রাখুন।
- Cutover-এর আগে merge ও write-নির্ভর automation স্থিতিশীল করুন। Final update destination-এ পৌঁছেছে এবং migration completed অবস্থায় গেছে কি না যাচাই করুন।
- Destination-এর default branch, সাম্প্রতিক commit, প্রয়োজনীয় repository data ও access পরীক্ষা করে নতুন location ব্যবহারের নির্দেশ দিন।
শুধু “rollback” লিখে রাখলে পুনরুদ্ধার পরিকল্পনা সম্পূর্ণ হয় না। Source কখন archive হবে, ব্যর্থতার কোন অবস্থায় আর এগোনো হবে না এবং source পুনরায় writable করার সিদ্ধান্ত কে নেবেন—এই তিনটি বিষয় cutover-এর আগেই নির্ধারিত থাকা দরকার।
Organization পুনর্গঠন repository migration-এর বাইরে
Repository destination-এ পৌঁছালেই organization প্রস্তুত হয় না। Organization settings, teams ও projects migration payload-এর বাইরে থাকায় এগুলোকে শেষ মুহূর্তের follow-up না ধরে আলাদা workstream হিসেবে পরিকল্পনা করা দরকার।
Migration-পূর্ব snapshot-এ organization policies ও settings, team ও membership তালিকা, repository access mapping, active projects এবং প্রতিটি configuration-এর owner রাখা যায়। Destination-এ পুনর্গঠনের পর দ্বিতীয় reviewer দিয়ে access যাচাই ELM-এর built-in ধাপ নয়; এটি অনুপস্থিত বা অতিরিক্ত permission শনাক্ত করার operational safeguard।
এখন পর্যন্ত নিশ্চিত অবস্থা হলো, ELM GHES থেকে GHE.com-এ repository নেওয়ার GA পথ এবং backfill চলাকালে source ব্যবহারের সুযোগ দেয়। তবে final cutover-এ read-only সময় থাকবে, প্রতিটি repository আলাদা job হবে এবং organization-level configuration migration দলকেই inventory থেকে পুনর্গঠন ও যাচাই করতে হবে।
আরও পড়ুন:
আমাদের নিউজলেটার নিন
সর্বশেষ Web3, AI ও ক্রিপ্টো সংবাদ সরাসরি আপনার ইনবক্সে পান।