GitHub Actions — এটি কী, CI/CD পাইপলাইন এবং অটোমেশন

GitHub Actions কী?

GitHub Actions হল GitHub-এ নির্মিত একটি ওয়ার্কফ্লো অটোমেশন প্ল্যাটফর্ম যা 2019 সালে চালু হয়েছিল। এটি আপনাকে YAML ফাইলে CI/CD পাইপলাইন সংজ্ঞায়িত করার অনুমতি দেয় যা সরাসরি রিপোজিটরিতে সংরক্ষিত থাকে। প্রতিটি workflow একটি ট্রিগার দ্বারা সক্রিয় হয়: push, pull request, ট্যাগ তৈরি বা সময়সূচী অনুযায়ী। Jenkins বা TeamCity-এর বিপরীতে, CI সার্ভার হোস্ট করার জন্য আলাদা অবকাঠামোর প্রয়োজন হয় না।

মোবাইল ডেভেলপমেন্টের প্রসঙ্গে, GitHub Actions APK এবং IPA বিল্ড, ইমুলেটরে ইউনিট টেস্ট এবং UI টেস্ট চালানো, লিন্টার দ্বারা কোড পরীক্ষা, সইকরণ এবং Google Play ও App Store-এ প্রকাশনা অটোমেট করে। প্ল্যাটফর্মটি বিনামূল্যে মিনিট সরবরাহ করে পাবলিক রিপোজিটরির জন্য এবং প্রাইভেটের জন্য মূল্য পরিকল্পনা অনুযায়ী। ওপেন-সোর্স মোবাইল প্রোজেক্টের জন্য, এটি বিনা খরচে একটি পূর্ণাঙ্গ CI/CD সমাধান।

GitHub Actions আর্কিটেকচার: Workflows, Jobs এবং Steps

GitHub Actions আর্কিটেকচার চারটি স্তর নিয়ে গঠিত। Workflow হল মূল YAML ফাইল যা অটোমেশন সংজ্ঞায়িত করে। Workflow Jobs নিয়ে গঠিত, প্রতিটি Job একটি পৃথক Runner-এ সম্পাদিত হয়। Job-এর ভিতরে Steps সম্পাদিত হয় — অনুক্রমিক কমান্ড বা বাহ্যিক actions। Events ট্রিগার সংজ্ঞায়িত করে: push, pull_request, schedule, workflow_dispatch। GitHub ইন্টারফেসে Actions ট্যাবের মাধ্যমে একটি workflow ম্যানুয়ালি ট্রিগার করা যেতে পারে।

GitHub পূর্ব-ইনস্টল করা OS সহ হোস্ট করা runners সরবরাহ করে: Ubuntu, macOS এবং Windows। iOS বিল্ডের জন্য macOS-runner বাধ্যতামূলক, Android-এর জন্য — Linux বা macOS। Self-hosted runners আপনাকে কাস্টম পরিবেশের সাথে আপনার নিজস্ব সার্ভারে jobs চালানোর অনুমতি দেয়, যা বিশেষ হার্ডওয়্যার প্রয়োজনীয়তা সহ বড় প্রোজেক্টের জন্য উপযোগী। GitHub jobs সম্পাদন সারি সংগঠিত করার জন্য self-hosted runner গ্রুপও সমর্থন করে।

Workflow ফাইলের কাঠামো

মৌলিক workflow ফাইলে বিভাগ থাকে: name, on (ট্রিগার), jobs। প্রতিটি job runs-on (runner ধরন), strategy (ম্যাট্রিক্স), steps (কর্মের তালিকা) নির্দিষ্ট করে। Steps শেল কমান্ড বা মার্কেটপ্লেস থেকে রেডিমেড actions হতে পারে, যা owner/repo@version সিনট্যাক্সের মাধ্যমে সংযুক্ত হয়।

GitHub Actions-এ মোবাইল অ্যাপ্লিকেশন বিল্ড

Android বিল্ডের জন্য, workflow সাধারণত ধাপ অন্তর্ভুক্ত করে: রিপোজিটরি checkout, JDK ইনস্টলেশন, Gradle ক্যাশ কনফিগারেশন, assembleRelease চালানো। iOS-এর জন্য macOS-runner প্রয়োজন, xcode-select-এর মাধ্যমে Xcode ইনস্টলেশন, provisioning profile সমাধান এবং xcodebuild চালানো। iOS বিল্ডের জটিলতা code signing এবং সার্টিফিকেট ব্যবস্থাপনায় নিহিত। Apple-নির্দিষ্ট সেটিংসের মধ্যে apple-actions/import-codesign-certs-এর মাধ্যমে provisioning profile ব্যবস্থাপনা অন্তর্ভুক্ত।

Matrix strategy একসাথে একাধিক সংস্করণে বিল্ড চালানোর অনুমতি দেয়। উদাহরণস্বরূপ: iOS সংস্করণ (15.0, 16.0, 17.0) এবং Xcode (14, 15) সহ ম্যাট্রিক্স। এটি যাচাইকরণ ত্বরান্বিত করে বিভিন্ন OS সংস্করণের সাথে অ্যাপ্লিকেশন সামঞ্জস্যের, যদিও এটি runner মিনিট খরচ বাড়ায়। সীমিত CI বাজেটের প্রোজেক্টের জন্য, ম্যাট্রিক্স শুধুমাত্র প্রধান কনফিগারেশনে সীমাবদ্ধ করা যেতে পারে।

Android-এর জন্য পরিবেশ সেট আপ করা

GitHub Actions JDK ইনস্টলেশনের জন্য setup-java action এবং Gradle ক্যাশিংয়ের জন্য caching সরবরাহ করে। Android SDK Ubuntu runners-এ পূর্ব-ইনস্টল করা আছে। কাস্টম API স্তরের জন্য, একটি পৃথক ধাপে sdkmanager ব্যবহার করা হয়। Android এবং iOS বিল্ডের জন্য আলাদা workflows তৈরি করার পরামর্শ দেওয়া হয়, কারণ তারা বিভিন্ন runners এবং বিল্ড টুল ব্যবহার করে।

GitHub Marketplace এবং রেডিমেড actions

GitHub Marketplace-এ কমিউনিটি এবং অফিসিয়াল ডেভেলপারদের দ্বারা তৈরি 15,000-এর বেশি actions রয়েছে। মোবাইল ডেভেলপমেন্টের জন্য, মূল বিভাগগুলির মধ্যে রয়েছে: Code signing (apple-actions/import-codesign-certs), টেস্টিং (react-native-community/action), ডিপ্লয়মেন্ট (google-github-actions/release-google-play), নোটিফিকেশন (slackapi/slack-github-action)। Firebase App Distribution, TestFlight আপলোড এবং Fastlane-এর জন্যও actions উপলব্ধ। প্রতিটি action-এর একটি নির্দিষ্ট runner OS-এর জন্য সামঞ্জস্য লেবেল থাকে।

প্রতিটি action-এর একটি সংস্করণ, বিবরণ, README এবং লাইসেন্স থাকে। action নির্বাচন করার সময়, বিক্রেতাদের (Google, Apple, Microsoft) থেকে অফিসিয়াল এবং Verified Badge-এর মাধ্যমে যাচাইকৃতকে অগ্রাধিকার দেওয়া উচিত। একটি নির্দিষ্ট মেজর সংস্করণ উল্লেখ করা গুরুত্বপূর্ণ (actions/checkout@v4), @main নয়, অপ্রত্যাশিত পরিবর্তন এড়াতে। যদি প্রয়োজনীয় action Marketplace-এ না থাকে, আপনি একটি কাস্টম action তৈরি করতে পারেন — স্থানীয়ভাবে রিপোজিটরিতে (Docker action বা JavaScript action) বা Marketplace-এ প্রকাশ করতে পারেন।

মোবাইল CI/CD-এর জন্য জনপ্রিয় actions

• actions/checkout — রিপোজিটরি runner-এ ক্লোন করে
• actions/setup-java — Android বিল্ডের জন্য JDK ইনস্টল করে
• gradle/actions/setup-gradle — Gradle কনফিগার এবং ক্যাশ করে
• apple-actions/import-codesign-certs — iOS-এর জন্য সার্টিফিকেট ইম্পোর্ট করে
• google-github-actions/submit-release — Google Play Console-এ প্রকাশ করে

iOS প্রোজেক্টের জন্য ওয়ার্কফ্লোর উদাহরণ

iOS অ্যাপ্লিকেশন ডেভেলপ করার সময়, সিমুলেটর এবং ডিভাইসের সাথে সঠিক কাজ সেট আপ করা গুরুত্বপূর্ণ। macOS-14 runner ARM আর্কিটেকচারে Intel বিল্ড চালানোর জন্য Rosetta 2 সহ পরিবেশ সরবরাহ করে। একটি workflow-এ একাধিক বিল্ড স্কিম অন্তর্ভুক্ত থাকতে পারে — pull request-এর জন্য Debug এবং ট্যাগের জন্য Release। GitHub Actions পরীক্ষার ফলাফল প্রদর্শনের জন্য xcparse/sonarqube action-এর মাধ্যমে xcresult পার্সিং সমর্থন করে। বিল্ড স্থিতি বিজ্ঞপ্তি পাঠানোর জন্য, একটি Slack বা Telegram action যোগ করা যেতে পারে।

iOS-এর জন্য Code signing-এ সার্টিফিকেট এবং provisioning profiles ইম্পোর্ট করা অন্তর্ভুক্ত। Apple-actions সরবরাহ করে P12 সার্টিফিকেট ইম্পোর্ট এবং provisioning profile ইনস্টল করার জন্য একটি ধাপ। সার্টিফিকেট GitHub Actions secrets হিসাবে সংরক্ষিত হয় এবং শুধুমাত্র বিল্ড ধাপে ডিক্রিপ্ট করা হয়। সইকরণ অটোমেশনের জন্য Fastlane match ব্যবহার করা হয়, যা workflow-এ একটি পৃথক ধাপ হিসাবে কল করা যেতে পারে।

আসুন Swift-এ iOS অ্যাপের জন্য একটি workflow বিবেচনা করি যা প্রোজেক্ট বিল্ড করে, পরীক্ষা চালায় এবং একটি আর্কাইভ করা বিল্ড তৈরি করে। Workflow ব্যবহার করে macOS-14 runner, Xcode 15.4 এবং সার্টিফিকেট ব্যবস্থাপনার জন্য actions।

name: iOS CI

on:
  push:
    branches: ["main"]
  pull_request:
    branches: ["main"]

jobs:
  build:
    runs-on: macos-14
    steps:
      - uses: actions/checkout@v4
      - name: Select Xcode
        run: sudo xcode-select -s /Applications/Xcode_15_4.app
      - name: Install CocoaPods
        run: pod install
      - name: Build and test
        run: xcodebuild clean test -workspace App.xcworkspace
            -scheme App -sdk iphonesimulator
      - name: Archive
        run: xcodebuild archive -workspace App.xcworkspace
            -scheme App -archivePath App.xcarchive

GitHub Actions-এ ডিপেন্ডেন্সি ক্যাশিং

ক্যাশিং ওয়ার্কফ্লো রানের মধ্যে ডিপেন্ডেন্সি সংরক্ষণ করে বিল্ড সময় কমায়। GitHub সরবরাহ করে actions/cache-এর মাধ্যমে বিল্ট-ইন ক্যাশিং। Gradle-এর জন্য, ~/.gradle ক্যাশ করা হয়, CocoaPods-এর জন্য — Pods/, SPM-এর জন্য — .build/। ক্যাশ কী-তে ডিপেন্ডেন্সি তালিকা ফাইলের হ্যাশ অন্তর্ভুক্ত থাকে — যখন ডিপেন্ডেন্সি পরিবর্তিত হয়, ক্যাশ স্বয়ংক্রিয়ভাবে অবৈধ হয়ে যায়।

ক্যাশ পুনরুদ্ধার কৌশল (restore-keys)-এ বিশেষ মনোযোগ দেওয়া উচিত। যদি সঠিক কী পাওয়া না যায়, GitHub Actions restore-keys দ্বারা আংশিক মিলানোর চেষ্টা করে। এটি উপযোগী যখন শুধুমাত্র একটি ডিপেন্ডেন্সি পরিবর্তিত হয় — ক্যাশ আংশিকভাবে ব্যবহারযোগ্য থাকে। Gradle-এর জন্য, Gradle Build Cache সক্ষম করার অতিরিক্ত পরামর্শ দেওয়া হয়, যা প্রোজেক্টের বিভিন্ন মডিউলের মধ্যে বিল্ড ফলাফল ক্যাশ করে।

Gradle ক্যাশিংয়ের উদাহরণ

- name: Cache Gradle
  uses: actions/cache@v4
  with:
    path: |
      ~/.gradle/caches
      ~/.gradle/wrapper
    key: ${{ runner.os }}-gradle-${{ hashFiles('*.gradle*') }}

ক্যাশ দক্ষতা Android প্রোজেক্টের জন্য: ক্যাশ ছাড়া প্রথম বিল্ড — 8–12 মিনিট, ক্যাশ সহ পরবর্তী বিল্ড — 2–4 মিনিট। CocoaPods সহ iOS-এর জন্য, সাশ্রয় একই রকম। সর্বোত্তম ক্যাশ ব্যবস্থাপনার জন্য actions/cache-কে Gradle-এর setup-gradle action-এর সাথে একত্রিত করার পরামর্শ দেওয়া হয়। React Native-এ npm ডিপেন্ডেন্সির জন্য, actions/cache ব্যবহার করা হয় package-lock.json হ্যাশিং সহ। সঠিক ক্যাশ কনফিগারেশনের সাথে, বিল্ড সময় 70% পর্যন্ত কমানো যেতে পারে।

GitHub Actions ওয়ার্কফ্লো, job এবং step স্তরে পরিবেশ চলক সমর্থন করে। পরিবেশ চলক ওভাররাইড করা যেতে পারে: step-স্তরের সর্বোচ্চ অগ্রাধিকার রয়েছে। গোপনীয় ডেটার জন্য, সর্বদা secrets ব্যবহার করুন — সেগুলি AES-256 দিয়ে এনক্রিপ্ট করা হয় এবং লগে প্রদর্শিত হয় না। পরিবেশ সুরক্ষা নিয়মও উপলব্ধ — ডিপ্লয়মেন্টের আগে বাধ্যতামূলক ম্যানুয়াল অনুমোদন। অতিরিক্ত সুরক্ষার জন্য, নির্দিষ্ট ব্যবহারকারী বা দল থেকে বাধ্যতামূলক অনুমোদন কনফিগার করা যেতে পারে।

GitHub Actions Reusable Workflows-ও সমর্থন করে — পুনর্ব্যবহারযোগ্য পাইপলাইন যা অন্যান্য workflows থেকে কল করা যেতে পারে। এটি অনুমতি দেয় একটি কেন্দ্রীভূত বিল্ড workflow তৈরি করার এবং এটি সংস্থার সমস্ত রিপোজিটরিতে পুনরায় ব্যবহার করার। Reusable workflow একটি লাইনে কল করা হয় এবং ইনপুট প্যারামিটার এবং secrets গ্রহণ করতে পারে। এটি বড় দলে CI/CD অনুশীলন মানক করার জন্য বিশেষভাবে উপযোগী।

নিরাপত্তা এবং সর্বোত্তম অনুশীলন

মোবাইল প্রোজেক্টের জন্য GitHub Actions কনফিগার করার সময়, নিরাপত্তা নীতি অনুসরণ করা গুরুত্বপূর্ণ। OIDC (OpenID Connect) আপনাকে দীর্ঘমেয়াদী ক্রেডেনশিয়াল দূর করতে এবং ক্লাউড প্রদানকারীদের জন্য অস্থায়ী টোকেন পেতে অনুমতি দেয়। স্ক্রিপ্টে কখনও plain-text secrets ব্যবহার করবেন না — GitHub Actions স্বয়ংক্রিয়ভাবে লগে secrets মাস্ক করে।

মোবাইল প্রোজেক্টের জন্য, তৃতীয়-পক্ষের forks-এর জন্য workflow অ্যাক্সেস সীমাবদ্ধ করা গুরুত্বপূর্ণ। pull_request_target সেটিং ব্যবহার করুন সতর্কতার সাথে — এটি fork থেকে নয়, বেস শাখা থেকে কোড সম্পাদন করে। iOS অ্যাপের code signing-এর জন্য, সার্টিফিকেট এনক্রিপ্টেড আকারে সংরক্ষণ করার এবং শুধুমাত্র বিল্ড ধাপে gpg বা openssl-এর মাধ্যমে ডিক্রিপ্ট করার পরামর্শ দেওয়া হয়।