Monorepo ETL-এর জন্য ৪টি GitHub Actions প্যাটার্ন
একটি Monorepo থেকে তিনটি সাইট চালানো কিছু সমস্যার সৃষ্টি করে। আপনাকে তিনটি আলাদা ETL জব, তিনটি কন্টেন্ট রিবিল্ড এবং তিনটি ডিপ্লয়মেন্ট পাইপলাইনের মুখোমুখি হতে হয়। আপনি যদি এগুলোকে সমন্বয় না করেন, তবে তারা একে অপরের সাথে সংঘর্ষ (collide) ঘটাবে।
এই সেটআপটিকে স্থিতিশীল করতে আমি ছয় সপ্তাহ সময় নিয়ে শিডিউলগুলো পরীক্ষা করেছি। আমি যে চারটি প্যাটার্ন ব্যবহার করি তা নিচে দেওয়া হলো।
১. Cron Jobs-এর জন্য Time Offsets ব্যবহার করুন
সব ETL জব একই সময়ে চালালে ব্যর্থতা দেখা দিতে পারে। জবগুলো API rate limit-এর জন্য প্রতিযোগিতা করে। যখন HuggingFace বা GitHub একটি 429 error প্রদান করে, তখন রানটি ব্যর্থ হয়।
এটি প্রতিরোধ করতে আমি ৩০ মিনিটের offset ব্যবহার করি।
- প্রথম জবটি শুরু হয় ০২:০০ মিনিটে
- দ্বিতীয় জবটি শুরু হয় ০২:৩০ মিনিটে
- তৃতীয় জবটি শুরু হয় ০৩:০০ মিনিটে
পরবর্তী জব শুরু হওয়ার আগে একটি ভারী pull শেষ করার জন্য ৩০ মিনিট যথেষ্ট সময়। এটি আপনার লগগুলোকে পরিষ্কার রাখে এবং API collision প্রতিরোধ করে।
২. অপ্রয়োজনীয় রিবিল্ড বন্ধ করতে Skip Flags ব্যবহার করুন
প্রতিটি ETL জব একটি Vercel deployment-এর মাধ্যমে শেষ হয়। সমস্যাটি তখন দেখা দেয় যখন আর্টিকেল কমিটগুলোও রিবিল্ড ট্রিগার করে। কোনো পরিকল্পনা না থাকলে, প্রতিটি আর্টিকেল আপডেট তিনটি সাইটকেই রিবিল্ড করতে বাধ্য করে। এতে build minutes নষ্ট হয়।
আমি ETL commit মেসেজে একটি [skip publish-articles] ট্যাগ ব্যবহার করি।
আমি আমার workflow-তে এই ফ্ল্যাগটি চেক করার জন্য একটি ধাপ যোগ করেছি। যদি ট্যাগটি থাকে, তবে workflow-টি build এবং deploy ধাপটি স্কিপ করে। এটি ETL পাইপলাইনগুলোকে আর্টিকেল পাইপলাইন থেকে আলাদা রাখে।
৩. নির্দিষ্ট সাইট টার্গেট করতে Path Filters ব্যবহার করুন
আপনি নিশ্চয়ই চাইবেন না যে একটি সাইটের আপডেটের কারণে তিনটি ডিপ্লয়মেন্ট ট্রিগার হোক। আমি প্রতিটি সাইটের workflow এমনভাবে কনফিগার করি যাতে এটি শুধুমাত্র তার নিজস্ব ফোল্ডার এবং shared packages ফোল্ডারটি পর্যবেক্ষণ (watch) করে।
উদাহরণস্বরূপ লজিক:
- AI tools সাইট শুধুমাত্র
apps/ai-tools/পর্যবেক্ষণ করে - OSS সাইট শুধুমাত্র
apps/oss-alternatives/পর্যবেক্ষণ করে
আপনি যদি shared ডিরেক্টরিতে কোড পরিবর্তন করেন, তবে সব সাইট রিবিল্ড হবে। আমি এই বিষয়টি মেনে নিয়েছি কারণ shared কোড পরিবর্তন খুব কমই ঘটে।
৪. নিয়ন্ত্রণের জন্য Manual Dispatch যোগ করুন
Cron দৈনন্দিন রুটিন সামলায়। Manual dispatch বাকি সবকিছু সামলায়। আমি workflow_dispatch ব্যবহার করি যাতে আমি পারি:
- একটি ব্যর্থ ETL জব পুনরায় চালানো (Re-run)
- ডেটা যোগ করার পর জোরপূর্বক রিফ্রেশ (Force refresh) করা
- ডেটাবেসে ডেটা না লিখে ডেটা পরীক্ষা করার জন্য একটি dry run চালানো
GitHub UI এই অপশনগুলোর জন্য একটি ড্রপডাউন মেনু দেখায়। এটি টাইপো (typos) প্রতিরোধ করে এবং ডিবাগিং সহজ করে তোলে।
সারসংক্ষেপ
এই প্যাটার্নগুলো জটিল নয়। এগুলো অত্যন্ত সুনির্দিষ্ট। আমি এই নিয়মগুলো নথিভুক্ত করার জন্য আমার রিপোজিটরিতে একটি সাধারণ markdown ফাইল রাখি। এটি নিশ্চিত করে যে নতুন workflow যোগ করার সময় আমি সিস্টেমটি নষ্ট না করি।