CI/CD using GitHub Actions

🧠 What is CI/CD?

ধরো তুমি প্রতিদিন স্কুলে গিয়ে ছবি আঁকো। তোমার টিচার চায়, তুমি আঁকা শেষ করলেই সেটা তাকে দেখাও — যাতে সে দেখে ঠিক আছে কিনা। এটাই CI/CD-এর মতো।

প্রতিবার তুমি ছবি আঁকো (code লেখো), সঙ্গে সঙ্গে একজন টিচার সেটা দেখে (test করে)। -> CI (Continuous Integration)

যদি ছবি ঠিক হয় (test পাস করে), তখন সেটা অটোমেটিকভাবে তোমার বন্ধুদের দেখানোর জন্য পাঠিয়ে দেওয়া হয় (release বা deploy করা হয়)। -> CD (Continuous Delivery)

• CI = Continuous Integration
  ➤ Code push করলেই সিস্টেম অটো বিল্ড করে দেখে bug আছে কিনা
  ➤ Automatically build & test code after every commit/pull request

• CD = Continuous Delivery or Deployment
  ➤ সব কিছু ঠিক থাকলে apk/build/upload করে দেয় — human ছাড়াই
  ➤ Automatically prepare artifacts (APK/AAB) for release
  ➤ Automatically push to Play Store/internal track (optional, risky for prod)

আমরা Android Studio দিয়ে অ্যাপ বানাই, Gradle দিয়ে build করি, test চালাই, APK তৈরি করিই QA বা Client কে পাঠাই। এইসব কাজ আমরা প্রতিবার নিজে নিজে করতে হয়।

CI/CD হল এমন একটা অটো সিস্টেম, যেটা আমাদের হয়ে এইসব কাজ নিজে নিজেই করে ফেলে — আমাদের কিছুই করতে হয় না!

🧰 CI/CD Tools

Benefits

• Faster release cycle
• fewer bugs
• consistent builds

🏗️ GitHub Actions

– GitHub Actions হল একটা ছোট্ট Robot যেটা Code Push হলেই কাজ শুরু করে!

আমরা কখন কী করতে চাই, সেটা YAML এ বলে দেই(Think of GitHub Actions YAML file as a রোবটকে নির্দেশনা দেয়ার খাতা, একটা Text ফাইল, যেটা তুমি GitHub Actions বা অন্য configuration-এ ব্যবহার করো রোবটকে নির্দেশনা দিতে।)

আমরা .github/workflows/ ফোল্ডারে একটা YAML ফাইল দেই, যেমন:

your-project/
└── .github/
    └── workflows/
        └── firebase-ci.yml

এই GitHub Actions রোবট —

• Code ডাউনলোড করে নেয় (checkout)
• Gradle দিয়ে build করে
• JUnit/Mockito দিয়ে test চালায়
• সব ঠিক থাকলে ➤ APK ফাইল বানায়
• তারপর ➤ Firebase App Distribution বা Google Drive-এ upload করে
• চাইলে ➤ Slack, Email বা Telegram-এ notify করে দেয়

যখনই তুমি main ব্রাঞ্চে কোড push করো, তখন নিচের ধাপগুলো চলবে:

• Android Lint Check: Code clean আছে কিনা, Android guideline মেনে লেখা হয়েছে কিনা — সেটা দেখে।

• Unit Test: ছোট ছোট function ঠিকমতো কাজ করছে কিনা সেটা পরীক্ষা করে।

• Instrumentation Test: পুরো UI/Activity সঠিকভাবে কাজ করছে কিনা দেখে।

• Static Code Analysis: Code-এ ভুল ধরণ বা সমস্যা আছে কিনা দেখে (যেমন SonarQube দিয়ে)।

• APK Build (Packaging): .apk ফাইল বানায়।

• Functional Test: UI বাটন, স্ক্রিন ঠিকমতো রেসপন্ড করে কিনা দেখে।

• Deploy: যদি সব ঠিক থাকে, তখন Firebase App Distribution বা Google Drive এ আপলোড করে দেয় — যাতে QA টিম টেস্ট করতে পারে।

Pipeline Building Blocks

These are the stages of a typical Android CI/CD pipeline:

Build Artifact Management:

Deployment & Distribution:

🧱 YAML-এর মূল কাঠামো (Structure)

একটা YAML ফাইল সাধারণত ৩টি অংশে ভাগ করা যায়:

name: এই পুরো Workflow-এর নাম (Just একটা টাইটেল).
on: কবে এই কাজগুলো চলবে? (Trigger condition)
jobs: আসল কাজগুলো, Step by Step, কী কী হবে?

বাস্তবে YAML ফাইল এর মাধ্যমে রোবটকে বলি:

name: Android Build

on:
  push:
    branches: [ main ]

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - name: কোড নাও
        uses: actions/checkout@v4

      - name: JDK সেট করো
        uses: actions/setup-java@v4
        with:
          java-version: '17'

      - name: gradlew চালাও
        run: chmod +x ./gradlew

      - name: APK বানাও
        run: ./gradlew assembleDebug

      - name: APK Upload করো
        uses: actions/upload-artifact@v4
        with:
          name: app-debug.apk
          path: app/build/outputs/apk/debug/app-debug.apk

🎯 উদাহরণ:

on: push ➤ push করলে চলবে
on: pull_request ➤ PR করলে চলবে
on: schedule ➤ নির্দিষ্ট সময় অনুযায়ী চলবে

build: হল এই কাজের নাম — তুমি ইচ্ছেমতো অন্য কিছু দিতে পারো যেমন test:, deploy: ইত্যাদি।

runs-on, GitHub তোমার কাজ চালানোর জন্য একটা ভার্চুয়াল কম্পিউটার (server) চালু করবে।
runs-on: ubuntu-latest # Linux machine
runs-on: windows-latest # Windows machine
runs-on: macos-latest # Mac machine (iOS dev-এর জন্য দরকার)

GitHub Marketplace: https://github.com/marketplace

🔄 CI/CD Flow (GitHub Actions ➤ Firebase App Distribution)

এই ফ্লোটি Android অ্যাপের জন্য APK build করে Firebase-এ আপলোড করে — অটোমেটিকভাবে, যখনই main branch-এ কোড push করবে।

01: GitHub Repo তৈরি করো

02: এই .yml ফাইলটা রাখো your-project/.github/workflows/firebase-ci.yml ফাইল.

mkdir -p .github/workflows 
touch .github/workflows/firebase-ci.yml

your-project/
└── .github/
    └── workflows/
        └── firebase-ci.yml

03: Gradle wrapper (./gradlew) ফাইল যেন executable থাকে.

04: Firebase App ID সংগ্রহ করো: ➤ Firebase Console ➤ Project Settings ➤ General ➤ Android App ➤ App ID

05: Firebase Token জেনারেট করো। CLI দিয়ে লগইন করে token বানাও। কমান্ড দিয়ে : firebase login:ci। একটা লম্বা টোকেন আসবে। Copy করে রাখো।

brew install node
node -v
npm -v
npm install -g firebase-tools
firebase login:ci
firebase --version

06: GitHub Secrets সেট করো: GitHub Repo ➤ Settings ➤ Secrets and variables ➤ Actions ➤ “New repository secret” এ গিয়ে এই দুইটা key add করো

|Secret Name     |         Value                     |
|----------------|-----------------------------------|
|FIREBASE_APP_ID | Firebase Console থেকে নেয়া App ID.  |
|FIREBASE_TOKEN  | Firebase CLI দিয়ে generate করা token|

⚠ Important Warnings:

1. FIREBASE_TOKEN is deprecated

- You are using FIREBASE_TOKEN to authenticate.

- Firebase CLI will remove this method in a future release.

✅ Recommended: Use Service Account JSON instead.

🔒 Create Service Account & Get JSON Key:

- Go to Firebase Console → Project Settings → Service Accounts

- Click “Generate new private key” → Download the .json file

- Add the file to GitHub Secrets (name it SERVICE_ACCOUNT_JSON)

Update your GitHub Actions .yml like:

- name: Upload to Firebase App Distribution
  uses: wzieba/Firebase-Distribution-Github-Action@v1
  with:
    appId: ${{ secrets.FIREBASE_APP_ID }}
    serviceCredentialsFileContent: ${{ secrets.SERVICE_ACCOUNT_JSON }}
    file: app/build/outputs/apk/release/app-release.apk
    testers: [e-mail]
    releaseNotes: "Automated build from GitHub Actions"

07: Firebase Console-এ গিয়ে testers বা group তৈরি:

• Firebase Console ➝ App Distribution ➝ Testers & Groups

• • Add testers ➝ তোমার ইমেইল অ্যাড্রেস অথবা টেস্টারদের ইমেইল যোগ করো

• চাইলে Group তৈরি করে তার নাম রাখো, যেমন: internal-testers

08: এখন main branch-এ কোড push করলেই:

✅ APK build হবে
✅ Firebase App Distribution এ testers group-এ পাঠানো হবে
✅ QA টিম ফোনে Firebase থেকে install করতে পারবে

📄 firebase-ci.yml ফাইল

name: Android CI/CD - Build and Firebase Upload

on:
  push:
    branches: [ main ]  # main branch এ push হলে trigger হবে

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      # 1. কোড চেকআউট
      - name: Checkout project code
        uses: actions/checkout@v4

      # 2. JDK সেটআপ (Java 17)
      - name: Set up JDK 17
        uses: actions/setup-java@v4
        with:
          distribution: 'temurin'
          java-version: '17'

      # 3. gradlew পারমিশন দিন (Linux এর জন্য প্রয়োজন)
      - name: Make gradlew executable
        run: chmod +x ./gradlew

      # 4. Debug APK build করুন
      - name: Build Debug APK
        run: ./gradlew assembleDebug

      # 5. Firebase App Distribution এ আপলোড করুন
      - name: Upload to Firebase App Distribution
        uses: wzieba/Firebase-Distribution-Github-Action@v1
        with:
          appId: ${{ secrets.FIREBASE_APP_ID }}
          token: ${{ secrets.FIREBASE_TOKEN }}
          groups: "internal-testers"
          file: app/build/outputs/apk/debug/app-debug.apk
          releaseNotes: "Bug fixes and improvements"
          notifyTesters: true

https://singhajit.com/android-ci-cd-using-github-actions/

CI/CD Tools: GitHub Actions, GitLab CI, Jenkins, Bitrise, CircleCI, Fastlane

DevOps Skills: Automated build/test/deploy pipelines, Gradle optimization, Firebase App Distribution

• Start with: GitHub Actions → Lint → Test → Build

• Next: Add Firebase Upload + Slack Notification

• Advanced: Code Quality + Play Store Automation

• Use Secrets for safety (Firebase Token, API keys)

Recommended

• Start with GitHub Actions
• Learn Fastlane: Even if you use GitHub Actions, Fastlane handles signing, Play Store / App Store uploads, screenshots, and versioning
• Explore at least one alternative
  • Bitrise → for mobile apps
  • GitLab CI → if you work with GitLab repos
• Understand CI/CD fundamentals
  • Workflow triggers: push, PR, schedule
  • Environment variables and secrets
  • Caching, parallel jobs
  • Deploy strategies: canary, staged rollout

Ref

Tracks in Google Play

• Internal Track--> Internal testing track – ছোট টিম বা নির্দিষ্ট testers-এর জন্য, খুব দ্রুত আপলোড হয়।
• Alpha Track (Closed Testing)--> Closed testing track – select group of testers, release before beta/production.
• Beta Track (Open Testing) --> Open testing track – larger tester group, pre-release before production.
• Production Track --> Public release – সকল Play Store user-এর জন্য।

Status Parameter

• completed - Build immediately published to track (not draft).
• draft - Build saved as draft, manual publish needed.

whatsNew/
├─ internal/
│ └─ en-US.txt
├─ beta/
│ └─ en-US.txt
└─ production/
└─ en-US.txt

SkinBD app production release
- New features
- Bug fixes

GitFlow

1. Main Branch (Production ready code)

• এখানে সবসময় stable production code থাকে।
• Example: v1.0 app live আছে।

2. Develop Branch (Ongoing development)

• সব developer এখানে merge করে। এটা future release এর জন্য।

3. Feature Branch তৈরি

• Rakib নতুন feature বানাতে শুরু করলো:

git checkout develop &
git checkout -b feature/login-api & git commit -m "feat: add login API with JWT authentication" & 
git push origin feature/login-api

• Sara UI বানাতে শুরু করলো:

git checkout develop & 
git checkout -b feature/login-ui
git commit -m "feat: add login screen with username/password fields"
git push origin feature/login-ui

4. Pull Request (PR)

• Rakib GitHub/GitLab এ PR তৈরি করলো → feature/login-api → develop
• CI/CD pipeline run হলো → test & build pass
• Teammates review করলো, comments দিলো → Rakib fix করলো
• তারপর merge approved
• Sara ও একইভাবে feature/login-ui → develop PR দিলো → merge approved

5. Release Branch

• Release এর সময়:
• git checkout develop
• git checkout -b release/v1.1
• QA টিম এই branch টেস্ট করবে।
• Bug fix দরকার হলে সরাসরি এই branch এ করা হবে।

6. Production Release

git checkout main
git merge release/v1.1
git tag -a v1.1 -m "Release 1.1"
git push origin main --tags

7. Hotfix Example

• Production এ login bug ধরা পড়লো → hotfix branch:

git checkout main
git checkout -b hotfix/login-bug
# fix bug
git commit -m "fix: login null pointer exception"
git push origin hotfix/login-bug

• PR → review → merge into main and develop.

Real-life Output:

• main → v1.0 (old release), later updated to v1.1
• develop → চলমান development branch
• feature/login-api → Rakib এর কাজ
• feature/login-ui → Sara এর কাজ
• release/v1.1 → staging QA tested branch
• hotfix/login-bug → production bugfix