🏗️ Real-World Build Variants, Environments & CI/CD for Flutter Projects (Part 1)

🏗️ Real-World Build Variants, Environments & CI/CD for Flutter Projects (Part 1)

FlutterPulse

This article was translated specially for the channel FlutterPulseYou'll find lots of interesting things related to Flutter on this channel. Don't hesitate to subscribe!🚀

A comprehensive guide to managing multiple environments, build configurations, and automated deployment pipelines in Flutter applications.

"The best time to set up proper CI/CD was yesterday. The second-best time is now." — Me, after debugging production issues at 2 AM for the third time in a week.

👋 Introduction

In serious mobile app development, managing environments and automating deployments aren't just best practices — they're essential. Whether you're releasing a hotfix to production, testing QA builds in staging, or debugging in development, robust build variants and CI/CD systems ensure quality and speed.

In this article, we'll explore real-world build variant structures, secure configuration practices, and a CI/CD pipeline powered by GitHub Actions tailored for Flutter teams.

🎯 The Problem That Started It All

💡 What You'll Learn: Understanding why manual deployment processes fail and recognizing common deployment anti-patterns that hurt teams.

Picture this: It's Thursday evening, and we're preparing for a major app release. Our process looked something like this:

  1. Build the staging version manually
  2. Test it on a few devices
  3. Build the production version (fingers crossed we didn't mess up the config)
  4. Upload to app stores
  5. Pray everything works

Sound familiar? We were essentially playing Russian roulette with our deployments.

The breaking point came when we accidentally shipped our staging API endpoints to production. 50,000 users couldn't access their data for 6 hours. That's when I knew something had to change.

🚨 Common Deployment Horror Stories

  • Shipping debug builds with console logs to production
  • Using wrong API keys causing payment failures
  • Deploying with test data visible to real users
  • App crashes due to missing production certificates

🎁 Bonus Tip: Create a deployment checklist and stick it on your monitor. Even with automation, human oversight matters!

🧩 Understanding the Flutter Environment Puzzle

💡 What You'll Learn: The fundamental concepts of environment separation in Flutter and why it's different from traditional Android/iOS development.

Before diving into solutions, let's get one thing straight: Flutter doesn't have "flavors" like Android does natively. We need to create our own system, and thankfully, Flutter gives us the tools to do it elegantly.

🎯 Why Multiple Environments Matter (Beyond the Obvious)

Sure, everyone knows about dev/staging/prod separation. But here's what I learned the hard way:

🧭 Why Environment Separation Matters

  • Isolation: Avoid accidental production damage during testing
  • Staged Rollouts: Gradual feature release & testing
  • Security: Prevent production credentials from leaking
  • Configurability: Change endpoints, feature toggles, or logging behavior easily
  • Different API Keys: Your analytics, crash reporting, and payment processors all need different configurations
  • Feature Flags: Some features should only be available in certain environments
  • App Icons: Users (and your QA team) need visual cues about which version they're using
  • Debug Information: Development builds need extra logging that would be security risks in production

🎁 Bonus Tip: Use different color schemes for each environment. Your QA team will thank you when they can instantly identify which build they're testing!

🗂️ Organizing Your Flutter Project for Environments

📁 Project Structure

lib/
├── main.dart
├── main_dev.dart
├── main_staging.dart
├── main_prod.dart
├── config/
│   ├── app_config.dart
│   ├── dev_config.dart
│   ├── staging_config.dart
│   └── prod_config.dart

🏗️ Building a Bulletproof Configuration System

💡 What You'll Learn: How to create a scalable, maintainable configuration system that works across all environments without code duplication.

After researching various approaches and reading through Flutter's official documentation, I settled on a pattern that's served us well for over two years.

🎯 The Foundation: Abstract Configuration

Here's the approach that changed everything for us:

// config/app_config.dart
// 🎯 This abstract class defines the contract for all environments
abstract class AppConfig {
  static late AppConfig _instance;
  static AppConfig get instance => _instance;

  // 📱 App Identity
  String get appName;
  String get baseApiUrl;
  String get environment;
  bool get isDebugMode;
  String get appSuffix;

  // 📊 Analytics & Monitoring
  String get analyticsKey;
  String get crashlyticsKey;

  // 🚀 Feature Flags
  bool get enableBetaFeatures;
  bool get showDebugInfo;

  // 🔧 Configuration Method
  static void configure(AppConfig config) {
    _instance = config;
  }
}

🔍 Code Breakdown for Beginners:

  • abstract class: This is like a template that other classes must follow
  • static late: This creates a single instance shared across the entire app
  • get: These are getters that return values (like variables but computed)

🎯 Environment-Specific Implementations

The magic happens in the concrete implementations:

// config/environments/development_config.dart
// 🔴 Development Configuration - For daily coding
class DevelopmentConfig extends AppConfig {
  @override
  String get appName => "MyApp (Dev)";

  @override
  String get baseApiUrl => "https://api-dev.myapp.com";

  @override
  String get environment => "development";

  @override
  bool get isDebugMode => true; // 🐛 Debug logs enabled

  @override
  String get appSuffix => ".dev"; // 📱 Different bundle ID

  // 📊 Development Analytics (won't pollute prod data)
  @override
  String get analyticsKey => "dev-analytics-key";

  @override
  String get crashlyticsKey => "dev-crashlytics-key";

  // 🚀 All features enabled for testing
  @override
  bool get enableBetaFeatures => true;

  @override
  bool get showDebugInfo => true; // 📋 Show debug overlays
}
// config/environments/production_config.dart
// 🟢 Production Configuration - For real users
class ProductionConfig extends AppConfig {
  @override
  String get appName => "MyApp";

  @override
  String get baseApiUrl => "https://api.myapp.com";

  @override
  String get environment => "production";

  @override
  bool get isDebugMode => false; // 🔒 No debug info

  @override
  String get appSuffix => ""; // 📱 Clean bundle ID

  // 📊 Production Analytics
  @override
  String get analyticsKey => const String.fromEnvironment(
    'PROD_ANALYTICS_KEY',
    defaultValue: '',
  );

  @override
  String get crashlyticsKey => const String.fromEnvironment(
    'PROD_CRASHLYTICS_KEY', 
    defaultValue: '',
  );

  // 🚀 Feature flags controlled remotely
  @override
  bool get enableBetaFeatures => false;

  @override
  bool get showDebugInfo => false; // 🔒 Never show debug info
}

🔍 For Beginners:

  • @override: This means we're providing our own version of the abstract method
  • const String.fromEnvironment(): This reads values from build-time environment variables
  • Different environments = different behaviors without changing code

🎁 Pro Tip: Use const String.fromEnvironment() for sensitive data. It's read at compile-time, making it more secure than runtime configuration.

🚀 Entry Point Example

// main_development.dart
// 🔴 Development App Entry Point
import 'package:flutter/material.dart';
import 'config/environments/development_config.dart';
import 'app.dart';

void main() {
  // 🔧 Configure for development
  AppConfig.configure(DevelopmentConfig());

  // 🚀 Launch the app
  runApp(MyApp());
}

// main_production.dart  
// 🟢 Production App Entry Point
import 'package:flutter/material.dart';
import 'config/environments/production_config.dart';
import 'app.dart';

void main() {
  // 🔧 Configure for production
  AppConfig.configure(ProductionConfig());

  // 🚀 Launch the app
  runApp(MyApp());
}

Use flutter build apk --flavor dev -t lib/main_dev.dart to build.

🎁 Bonus Tip: Create a main_flavor_checker.dart that prints the current configuration on startup. Great for debugging configuration issues!

📱 Platform-Specific Configuration: The Flutter Way

💡 What You'll Learn: How to configure Android flavors and iOS schemes to work seamlessly with Flutter's build system, including bundle IDs, app names, and icons.

🤖 Android Setup: Gradle Flavors

In android/app/build.gradle, we define our flavors:

// android/app/build.gradle
android {
    compileSdkVersion flutter.compileSdkVersion

    defaultConfig {
        applicationId "com.example.myapp"
        minSdkVersion flutter.minSdkVersion
        targetSdkVersion flutter.targetSdkVersion
        versionCode flutterVersionCode.toInteger()
        versionName flutterVersionName
    }

    // 🎯 Define flavor dimensions (categories)
    flavorDimensions "environment"

    // 🎯 Product flavors for different environments
    productFlavors {
        development {
            dimension "environment"
            applicationIdSuffix ".dev" // 📱 com.example.myapp.dev
            versionNameSuffix "-dev"   // 📊 1.0.0-dev
            resValue "string", "app_name", "MyApp Dev" // 📱 App name

            // 🎨 Custom app icon for development
            // Place dev icons in: android/app/src/development/res/
        }

        staging {
            dimension "environment"
            applicationIdSuffix ".staging" // 📱 com.example.myapp.staging
            versionNameSuffix "-staging"   // 📊 1.0.0-staging
            resValue "string", "app_name", "MyApp Staging"

            // 🎨 Custom app icon for staging
            // Place staging icons in: android/app/src/staging/res/
        }

        production {
            dimension "environment"
            resValue "string", "app_name", "MyApp" // 📱 Clean app name

            // 🎨 Production app icon
            // Use default icons in: android/app/src/main/res/
        }
    }

    // 🔐 Signing configurations
    signingConfigs {
        release {
            if (project.hasProperty('android.injected.signing.store.file')) {
                storeFile file(project.property('android.injected.signing.store.file'))
                storePassword project.property('android.injected.signing.store.password')
                keyAlias project.property('android.injected.signing.key.alias')
                keyPassword project.property('android.injected.signing.key.password')
            }
        }
    }

    buildTypes {
        release {
            signingConfig signingConfigs.release
            minifyEnabled true // 🗜️ Code shrinking
            proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro'
        }
    }
}

🔍 For Beginners:

  • applicationIdSuffix: Adds text to your app's ID so you can install multiple versions
  • versionNameSuffix: Helps identify which version you're looking at
  • resValue: Creates Android resources (like strings) at build time
  • signingConfig: How Android knows the app is really from you

📁 Folder Structure for Custom Icons:

android/app/src/
├── main/res/                    # 🟢 Production icons
│   ├── mipmap-hdpi/
│   ├── mipmap-mdpi/
│   └── ...
├── development/res/             # 🔴 Development icons (red tint)
│   ├── mipmap-hdpi/
│   └── ...
└── staging/res/                 # 🟡 Staging icons (orange tint)
    ├── mipmap-hdpi/
    └── ...

🍎 iOS Configuration: Xcode Schemes

For iOS, we create different schemes in Xcode:

📋 Step-by-Step Setup:

  1. Open Xcode → Open ios/Runner.xcworkspace
  2. Duplicate Scheme:
  • Product → Scheme → Manage Schemes
  • Select "Runner" → Duplicate (3 times)
  • Rename to: Runner-Dev, Runner-Staging, Runner-Production

3. Configure Each Scheme:

Runner-Dev:
├── Build Configuration: Debug
├── Bundle Identifier: com.example.myapp.dev
├── Display Name: MyApp Dev
└── App Icon: AppIcon-Dev

Runner-Staging:
├── Build Configuration: Release  
├── Bundle Identifier: com.example.myapp.staging
├── Display Name: MyApp Staging
└── App Icon: AppIcon-Staging

Runner-Production:
├── Build Configuration: Release
├── Bundle Identifier: com.example.myapp
├── Display Name: MyApp
└── App Icon: AppIcon

4. Add Environment Variables:

  • Select scheme → Edit Scheme → Run → Arguments
  • Add Environment Variables:
ENVIRONMENT = development (or staging/production)

🎁 Pro Tip: Use Xcode's "User-Defined Settings" to manage configuration values that change between environments.

🚀 Build Commands That Actually Work

# 🔴 Development Build
flutter build apk --flavor development -t lib/main_development.dart

# 🟡 Staging Build  
flutter build apk --flavor staging -t lib/main_staging.dart

# 🟢 Production Build
flutter build apk --flavor production -t lib/main_production.dart

# 🍎 iOS Builds
flutter build ios --flavor production -t lib/main_production.dart

# 📦 App Bundle for Play Store
flutter build appbundle --flavor production -t lib/main_production.dart

🎁 Bonus Script: Create a build script to simplify commands:

#!/bin/bash
# build.sh - Smart build script

ENVIRONMENT=$1
TARGET="lib/main_${ENVIRONMENT}.dart"

if [ -z "$ENVIRONMENT" ]; then
    echo "Usage: ./build.sh [development|staging|production]"
    exit 1
fi

echo "🏗️ Building for $ENVIRONMENT environment..."

# Clean previous builds
flutter clean
flutter pub get

# Build APK
flutter build apk --flavor $ENVIRONMENT -t $TARGET

# Build App Bundle for production
if [ "$ENVIRONMENT" = "production" ]; then
    flutter build appbundle --flavor $ENVIRONMENT -t $TARGET
fi

echo "✅ Build complete!"

🤖 CI/CD: Where the Magic Really Happens

💡 What You'll Learn: How to set up a complete CI/CD pipeline with GitHub Actions that automatically tests, builds, and deploys your Flutter app across multiple environments.

After trying several platforms, we settled on GitHub Actions for its flexibility and integration with our existing workflow. Here's our battle-tested pipeline:

# .github/workflows/flutter_ci_cd.yml
# 🤖 Complete Flutter CI/CD Pipeline
name: Flutter CI/CD Pipeline

on:
  push:
    branches: [main, develop, 'release/**']
  pull_request:
    branches: [main, develop]

env:
  FLUTTER_VERSION: '3.32.0' # 📌 Pin Flutter version for consistency

jobs:
  # 🧪 Quality Gates - The Foundation
  code_quality:
    name: 🧪 Code Quality & Testing
    runs-on: ubuntu-latest

    steps:
      - name: 📥 Checkout Repository
        uses: actions/checkout@v4

      - name: 🎯 Setup Flutter
        uses: subosito/flutter-action@v2
        with:
          flutter-version: ${{ env.FLUTTER_VERSION }}
          cache: true # 🚀 Speed up builds with caching

      - name: 📦 Install Dependencies
        run: flutter pub get

      - name: 🎨 Verify Formatting
        run: dart format --output=none --set-exit-if-changed .

      - name: 🔍 Analyze Code
        run: flutter analyze

      - name: 🧪 Run Unit Tests
        run: flutter test --coverage

      - name: 📊 Upload Coverage
        uses: codecov/codecov-action@v3
        with:
          file: coverage/lcov.info
          fail_ci_if_error: true

  # 🏗️ Build Strategy: Matrix for Multiple Environments
  build_android:
    name: 🏗️ Build Android (${{ matrix.flavor }})
    needs: code_quality # ⛔ Don't build if tests fail
    runs-on: ubuntu-latest

    strategy:
      matrix:
        flavor: [development, staging, production]

    steps:
      - name: 📥 Checkout Repository
        uses: actions/checkout@v4

      - name: 🎯 Setup Flutter
        uses: subosito/flutter-action@v2
        with:
          flutter-version: ${{ env.FLUTTER_VERSION }}
          cache: true

      - name: ☕ Setup Java
        uses: actions/setup-java@v3
        with:
          distribution: 'temurin'
          java-version: '17'

      - name: 📦 Install Dependencies
        run: flutter pub get

      # 🔐 Configure Android Signing (Production Only)
      - name: 🔐 Configure Android Signing
        if: matrix.flavor == 'production'
        run: |
          echo "${{ secrets.ANDROID_KEYSTORE_BASE64 }}" | base64 -d > android/app/keystore.jks
          echo "storePassword=${{ secrets.KEYSTORE_PASSWORD }}" >> android/key.properties
          echo "keyPassword=${{ secrets.KEY_PASSWORD }}" >> android/key.properties
          echo "keyAlias=${{ secrets.KEY_ALIAS }}" >> android/key.properties
          echo "storeFile=keystore.jks" >> android/key.properties

      # 📱 Build APK
      - name: 📱 Build APK
        run: |
          flutter build apk \
            --flavor ${{ matrix.flavor }} \
            --target lib/main_${{ matrix.flavor }}.dart \
            --dart-define=ENVIRONMENT=${{ matrix.flavor }} \
            ${{ matrix.flavor == 'production' && '--obfuscate --split-debug-info=build/debug-info' || '' }}

      # 📦 Build App Bundle (Production Only)
      - name: 📦 Build App Bundle (Production Only)
        if: matrix.flavor == 'production'
        run: |
          flutter build appbundle \
            --flavor ${{ matrix.flavor }} \
            --target lib/main_${{ matrix.flavor }}.dart \
            --dart-define=ENVIRONMENT=${{ matrix.flavor }} \
            --obfuscate \
            --split-debug-info=build/debug-info

      # 📤 Upload Build Artifacts
      - name: 📤 Upload APK Artifact
        uses: actions/upload-artifact@v3
        with:
          name: apk-${{ matrix.flavor }}
          path: build/app/outputs/flutter-apk/*.apk
          retention-days: 30

      - name: 📤 Upload App Bundle (Production)
        if: matrix.flavor == 'production'
        uses: actions/upload-artifact@v3
        with:
          name: aab-production
          path: build/app/outputs/bundle/**/*.aab
          retention-days: 90

  # 🚀 Deployment Strategy
  deploy_to_firebase:
    name: 🚀 Deploy to Firebase App Distribution
    needs: build_android
    runs-on: ubuntu-latest
    if: github.ref == 'refs/heads/develop' || startsWith(github.ref, 'refs/heads/release/')

    steps:
      - name: 📥 Download Staging APK
        uses: actions/download-artifact@v3
        with:
          name: apk-staging

      - name: 🚀 Firebase App Distribution
        uses: wzieba/Firebase-Distribution-Github-Action@v1
        with:
          appId: ${{ secrets.FIREBASE_APP_ID }}
          serviceCredentialsFileContent: ${{ secrets.FIREBASE_SERVICE_ACCOUNT_JSON }}
          groups: internal-testers,qa-team # 👥 Distribution groups
          file: app-staging-release.apk
          releaseNotes: |
            🚀 New staging build from commit ${{ github.sha }}

            📋 Details:
            • Branch: ${{ github.ref_name }}
            • Triggered by: ${{ github.actor }}
            • Commit: ${{ github.event.head_commit.message }}

            🧪 Ready for testing!

  # 🏪 Deploy to Play Store
  deploy_to_play_store:
    name: 🏪 Deploy to Google Play (Internal Testing)
    needs: build_android
    runs-on: ubuntu-latest
    if: github.ref == 'refs/heads/main'

    steps:
      - name: 📥 Download Production App Bundle
        uses: actions/download-artifact@v3
        with:
          name: aab-production

      - name: 🏪 Deploy to Play Store
        uses: r0adkll/upload-google-play@v1.1.1
        with:
          serviceAccountJsonPlainText: ${{ secrets.GOOGLE_PLAY_SERVICE_ACCOUNT_JSON }}
          packageName: com.example.myapp
          releaseFiles: '**/*.aab'
          track: internal # 🧪 Start with internal testing
          status: completed
          releaseNotes: |
            🎉 New version deployed automatically!

            This release includes bug fixes and performance improvements.

🔍 Pipeline Breakdown for Beginners:

| Stage               | Purpose                                 | When It Runs        |
|---------------------|------------------------------------------|---------------------|
| 🧪 Code Quality      | Tests, linting, formatting               | Every push/PR       |
| 🏗️ Build             | Creates APKs/AABs for all environments   | After tests pass    |
| 🚀 Firebase Deploy   | Distributes staging builds               | On develop branch   |
| 🏪 Play Store Deploy | Uploads to Google Play                   | On main branch      |

🎁 Bonus Features:

  • Caching: Speeds up builds by reusing dependencies
  • Matrix Builds: Builds all environments in parallel
  • Conditional Logic: Different steps for different environments
  • Artifact Management: Stores builds with proper retention

🔐 Secrets Management: Keep It Safe

Set up these secrets in your GitHub repository (Settings → Secrets and variables → Actions):

Required Secrets:
├── 🔐 ANDROID_KEYSTORE_BASE64      # Your keystore file (base64 encoded)
├── 🔑 KEYSTORE_PASSWORD            # Password for keystore
├── 🔑 KEY_PASSWORD                 # Password for signing key
├── 🆔 KEY_ALIAS                    # Alias of your signing key
├── 🔥 FIREBASE_APP_ID              # Firebase App Distribution ID
├── 📄 FIREBASE_SERVICE_ACCOUNT_JSON # Firebase service account
└── 🏪 GOOGLE_PLAY_SERVICE_ACCOUNT_JSON # Google Play Console service account

📋 How to Generate Secrets:

# 🔐 Convert keystore to base64
base64 -i android/app/keystore.jks | pbcopy

# 🔥 Firebase service account
# 1. Go to Firebase Console → Project Settings → Service Accounts
# 2. Generate new private key
# 3. Copy entire JSON content

# 🏪 Google Play service account  
# 1. Go to Google Play Console → Setup → API access
# 2. Create service account
# 3. Download JSON key

🚀 Advanced Patterns That Actually Work

💡 What You'll Learn: Professional-grade patterns for feature flags, environment detection, and advanced deployment strategies used by major tech companies.

🎯 1. Environment-Aware Feature Flags

Instead of hardcoding feature availability, we use a smart system:

// services/feature_flag_service.dart
// 🎯 Smart feature flag system
class FeatureFlagService {
  // 🚀 Main feature flag checker
  static bool isFeatureEnabled(String featureKey) {
    // 🔴 In development, enable all features by default
    if (AppConfig.instance.environment == 'development') {
      return _getDevelopmentFeatureFlag(featureKey);
    }

    // 🟡 In staging, use local configuration
    if (AppConfig.instance.environment == 'staging') {
      return _getStagingFeatureFlag(featureKey);
    }

    // 🟢 In production, use remote config
    return _getProductionFeatureFlag(featureKey);
  }

  // 🔴 Development feature flags - Liberal for testing
  static bool _getDevelopmentFeatureFlag(String featureKey) {
    const devFlags = {
      'new_checkout_flow': true,    // ✅ Always test new features
      'beta_dashboard': true,       // ✅ Show all beta features  
      'experimental_api': true,     // ✅ Enable experimental APIs
      'debug_menu': true,           // ✅ Show debug options
      'mock_data': true,            // ✅ Use mock data
    };

    return devFlags[featureKey] ?? true; // 🚀 Default to enabled
  }

  // 🟡 Staging feature flags - Production-like but with beta features
  static bool _getStagingFeatureFlag(String featureKey) {
    const stagingFlags = {
      'new_checkout_flow': true,    // ✅ Test before production
      'beta_dashboard': true,       // ✅ QA testing
      'experimental_api': false,    // ❌ Too risky for staging
      'debug_menu': true,           // ✅ Debugging for QA
      'mock_data': false,           // ❌ Use real staging data
    };

    return stagingFlags[featureKey] ?? false; // 🔒 Default to disabled
  }

  // 🟢 Production feature flags - Remote controlled
  static bool _getProductionFeatureFlag(String featureKey) {
    try {
      // 🌐 Use Firebase Remote Config or similar
      return FirebaseRemoteConfig.instance.getBool(featureKey);
    } catch (e) {
      // 🛡️ Fail safely - return conservative defaults
      const safeDefaults = {
        'new_checkout_flow': false,   // ❌ Safe default
        'beta_dashboard': false,      // ❌ Safe default
        'experimental_api': false,    // ❌ Never enable by default
        'debug_menu': false,          // ❌ Never show in production
        'mock_data': false,           // ❌ Always use real data
      };
    return safeDefaults[featureKey] ?? false; // 🛡️ Ultra-conservative default
  }
}

// 📊 Feature flag analytics
static void trackFeatureUsage(String featureKey, bool wasEnabled) {
if (AppConfig.instance.environment != 'production') return;
// Track which features are actually being used
Analytics.track('feature_flag_accessed', {
  'feature': featureKey,
  'enabled': wasEnabled,
  'environment': AppConfig.instance.environment,
});
}
}

🎯 Usage Example:

// widgets/new_checkout_button.dart
class NewCheckoutButton extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    // 🎛️ Feature flag check
    final useNewCheckout = FeatureFlagService.isFeatureEnabled('new_checkout_flow');

    if (useNewCheckout) {
      return NewCheckoutWidget(); // 🆕 New implementation
    }

    return LegacyCheckoutWidget(); // 🗝️ Fallback to old version
  }
}

🎁 Pro Tip: Always have a fallback. Feature flags should degrade gracefully, not crash your app.

🎯2. Smart Environment Detection

Sometimes you need to make runtime decisions based on the build environment:

// utils/environment_detector.dart
// 🕵️ Smart environment detection utility
class EnvironmentDetector {

  // 🎯 Main detection method
  static String detectEnvironment() {
    // 🔍 Method 1: Check if we have a configured environment
    try {
      return AppConfig.instance.environment;
    } catch (e) {
      // AppConfig not initialized yet
    }

    // 🔍 Method 2: Check build mode
    if (kDebugMode) {
      return 'development';
    }

    // 🔍 Method 3: Check app bundle ID (Android/iOS)
    return _detectFromBundleId();
  }

  // 📱 Bundle ID detection
  static String _detectFromBundleId() {
    final packageInfo = PackageInfo.fromPlatform();

    return packageInfo.then((info) {
      final bundleId = info.packageName;

      if (bundleId.endsWith('.dev')) {
        return 'development';
      } else if (bundleId.endsWith('.staging')) {
        return 'staging';
      } else {
        return 'production';
      }
    }).catchError((_) => 'unknown');
  }

  // 🧪 Quick environment checks
  static bool get isDevelopment => detectEnvironment() == 'development';
  static bool get isStaging => detectEnvironment() == 'staging';
  static bool get isProduction => detectEnvironment() == 'production';

  // 🚀 Environment-specific behavior
  static T environmentSwitch<T>({
    required T development,
    required T staging,
    required T production,
  }) {
    switch (detectEnvironment()) {
      case 'development':
        return development;
      case 'staging':
        return staging;
      case 'production':
      default:
        return production;
    }
  }
}

🎯 Usage Examples:

// 🎨 Environment-specific styling
final primaryColor = EnvironmentDetector.environmentSwitch(
  development: Colors.red,      // 🔴 Red for dev
  staging: Colors.orange,       // 🟠 Orange for staging
  production: Colors.blue,      // 🔵 Blue for production
);

// 🔗 Environment-specific URLs
final wsUrl = EnvironmentDetector.environmentSwitch(
  development: 'ws://localhost:8080',
  staging: 'wss://staging-ws.myapp.com',
  production: 'wss://ws.myapp.com',
);

// 📊 Environment-specific analytics
if (EnvironmentDetector.isProduction) {
  Analytics.initialize(); // Only initialize in production
}

🎯 3. Advanced Build Automation

Here's our production-grade build script that handles everything:

#!/bin/bash
# scripts/build_and_deploy.sh
# 🚀 Advanced build automation script

set -e # Exit on any error

# 🎨 Colors for pretty output
RED='\033[0;31m'
GREEN='\033[0;32m'
YELLOW='\033[1;33m'
BLUE='\033[0;34m'
NC='\033[0m' # No Color

# 📋 Configuration
ENVIRONMENT=${1:-development}
BUILD_TYPE=${2:-apk}
DEPLOY=${3:-false}

# 🎯 Validate inputs
validate_inputs() {
    if [[ ! "$ENVIRONMENT" =~ ^(development|staging|production)$ ]]; then
        echo -e "${RED}❌ Invalid environment: $ENVIRONMENT${NC}"
        echo "Usage: ./build_and_deploy.sh [development|staging|production] [apk|aab] [true|false]"
        exit 1
    fi

    if [[ ! "$BUILD_TYPE" =~ ^(apk|aab|ios)$ ]]; then
        echo -e "${RED}❌ Invalid build type: $BUILD_TYPE${NC}"
        exit 1
    fi
}

# 🧹 Clean and prepare
clean_and_prepare() {
    echo -e "${BLUE}🧹 Cleaning previous builds...${NC}"
    flutter clean
    flutter pub get

    # 🔍 Run code quality checks
    echo -e "${BLUE}🔍 Running code quality checks...${NC}"
    dart format --set-exit-if-changed .
    flutter analyze

    # 🧪 Run tests
    echo -e "${BLUE}🧪 Running tests...${NC}"
    flutter test
}

# 🏗️ Build application
build_app() {
    local target="lib/main_${ENVIRONMENT}.dart"
    local flavor_arg=""

    if [[ "$BUILD_TYPE" != "ios" ]]; then
        flavor_arg="--flavor $ENVIRONMENT"
    fi

    echo -e "${BLUE}🏗️ Building $BUILD_TYPE for $ENVIRONMENT...${NC}"

    case $BUILD_TYPE in
        "apk")
            flutter build apk $flavor_arg -t $target \
                --dart-define=ENVIRONMENT=$ENVIRONMENT \
                $([ "$ENVIRONMENT" = "production" ] && echo "--obfuscate --split-debug-info=build/debug-info")
            ;;
        "aab")
            flutter build appbundle $flavor_arg -t $target \
                --dart-define=ENVIRONMENT=$ENVIRONMENT \
                $([ "$ENVIRONMENT" = "production" ] && echo "--obfuscate --split-debug-info=build/debug-info")
            ;;
        "ios")
            flutter build ios -t $target \
                --dart-define=ENVIRONMENT=$ENVIRONMENT \
                $([ "$ENVIRONMENT" = "production" ] && echo "--obfuscate --split-debug-info=build/debug-info")
            ;;
    esac
}

# 📤 Deploy application
deploy_app() {
    if [[ "$DEPLOY" != "true" ]]; then
        echo -e "${YELLOW}⏭️ Skipping deployment (DEPLOY=$DEPLOY)${NC}"
        return
    fi

    echo -e "${BLUE}📤 Deploying $ENVIRONMENT build...${NC}"

    case $ENVIRONMENT in
        "development")
            echo -e "${YELLOW}📱 Development builds are not deployed automatically${NC}"
            ;;
        "staging")
            deploy_to_firebase
            ;;
        "production")
            deploy_to_stores
            ;;
    esac
}

# 🔥 Deploy to Firebase App Distribution
deploy_to_firebase() {
    if ! command -v firebase &> /dev/null; then
        echo -e "${RED}❌ Firebase CLI not found. Install with: npm install -g firebase-tools${NC}"
        exit 1
    fi

    echo -e "${BLUE}🔥 Deploying to Firebase App Distribution...${NC}"

    firebase appdistribution:distribute \
        build/app/outputs/flutter-apk/app-staging-release.apk \
        --app "$FIREBASE_APP_ID" \
        --groups "internal-testers,qa-team" \
        --release-notes "Automated staging build from $(git rev-parse --short HEAD)"
}

# 🏪 Deploy to app stores
deploy_to_stores() {
    echo -e "${BLUE}🏪 Deploying to app stores...${NC}"

    # This would integrate with your store deployment tools
    # For example, using Fastlane or direct API calls
    echo -e "${YELLOW}🚧 Store deployment requires manual approval${NC}"
    echo -e "${GREEN}✅ Production build ready for store submission${NC}"
}

# 📊 Generate build report
generate_report() {
    local build_size=""
    local build_path=""

    case $BUILD_TYPE in
        "apk")
            build_path="build/app/outputs/flutter-apk/app-${ENVIRONMENT}-release.apk"
            ;;
        "aab")
            build_path="build/app/outputs/bundle/${ENVIRONMENT}Release/app-${ENVIRONMENT}-release.aab"
            ;;
    esac

    if [[ -f "$build_path" ]]; then
        build_size=$(du -h "$build_path" | cut -f1)
        echo -e "${GREEN}📊 Build Report:${NC}"
        echo -e "  📱 Environment: $ENVIRONMENT"
        echo -e "  📦 Type: $BUILD_TYPE"
        echo -e "  📏 Size: $build_size"
        echo -e "  📍 Location: $build_path"
        echo -e "  🕐 Built: $(date)"
    fi
}

# 🚀 Main execution
main() {
    echo -e "${GREEN}🚀 Starting Flutter build process...${NC}"

    validate_inputs
    clean_and_prepare
    build_app
    deploy_app
    generate_report

    echo -e "${GREEN}✅ Build process completed successfully!${NC}"
}

# Execute main function
main "$@"

🎯 Usage Examples:

# 🔴 Development build
Report content on this page

Report Page

Please submit your DMCA takedown request to dmca@telegram.org