# Customer-Specific Build Examples

This document shows practical examples of how to build WebDrop Bridge for different customers or deployment scenarios.

## Scenario 1: Single Build with Default Configuration

**Situation:** You have one main configuration for your primary customer or general use.

**Setup:**
```
webdrop_bridge/
├── .env                  # Your main configuration
└── build/
    └── scripts/
        └── build_windows.py
```

**Build Command:**
```bash
python build/scripts/build_windows.py --msi
```

**Result:** `WebDropBridge-x.x.x-Setup.msi` with your `.env` configuration bundled.

---

## Scenario 2: Multi-Customer Builds

**Situation:** You support multiple customers, each with different URLs, allowed paths, etc.

**Setup:**
```
webdrop_bridge/
├── .env                           # Default project config
├── build/
│   └── scripts/
│       └── build_windows.py
└── deploy/                        # Create this directory
    └── customer_configs/
        ├── README.md
        ├── acme_corp.env
        ├── globex_corporation.env
        ├── initech.env
        └── wayne_enterprises.env
```

**Customer Config Example:** `deploy/customer_configs/acme_corp.env`
```dotenv
APP_NAME=WebDrop Bridge - ACME Corp Edition
APP_VERSION=1.0.0
WEBAPP_URL=https://acme-drop.example.com/drop
ALLOWED_ROOTS=Z:/acme_files/,C:/Users/Public/ACME
LOG_LEVEL=INFO
LOG_FILE=logs/webdrop_bridge.log
ENABLE_LOGGING=true
WINDOW_WIDTH=1024
WINDOW_HEIGHT=768
```

**Build Commands:**
```bash
# Build for ACME Corp
python build/scripts/build_windows.py --msi --env-file deploy/customer_configs/acme_corp.env

# Build for Globex
python build/scripts/build_windows.py --msi --env-file deploy/customer_configs/globex_corporation.env

# Build for Initech
python build/scripts/build_windows.py --msi --env-file deploy/customer_configs/initech.env

# Build for Wayne Enterprises
python build/scripts/build_windows.py --msi --env-file deploy/customer_configs/wayne_enterprises.env
```

**Result:** Four separate MSI files:
- `WebDropBridge-1.0.0-Setup.msi` (ACME - says "ACME Corp Edition")
- `WebDropBridge-1.0.0-Setup.msi` (Globex - say "Globex Edition")
- etc.

---

## Scenario 3: Development vs. Production Builds

**Situation:** You want different settings for internal testing vs. customer releases.

**Setup:**
```
webdrop_bridge/
├── .env                       # Production config (primary)
├── build/
│   └── scripts/
│       └── build_windows.py
└── build_configs/
    ├── development.env        # For internal testing
    ├── staging.env           # Pre-production testing
    └── production.env        # For customers (same as project .env)
```

**Development Config:** `build_configs/development.env`
```dotenv
APP_NAME=WebDrop Bridge DEV
WEBAPP_URL=http://localhost:3000
LOG_LEVEL=DEBUG
LOG_FILE=logs/webdrop_bridge.log
ENABLE_LOGGING=true
WINDOW_WIDTH=1024
WINDOW_HEIGHT=768
```

**Build Commands:**
```bash
# Development build (for testing)
python build/scripts/build_windows.py --env-file build_configs/development.env

# Staging build (pre-release testing)
python build/scripts/build_windows.py --env-file build_configs/staging.env

# Production build (for customers)
python build/scripts/build_windows.py --msi
# OR explicitly:
python build/scripts/build_windows.py --msi --env-file build_configs/production.env
```

---

## Scenario 4: Building with Code Signing

**Situation:** You have a code signing certificate and want to sign releases.

**Prerequisites:**
- Set environment variable: `CODE_SIGN_CERT=path/to/certificate.pfx`
- Set environment variable: `CODE_SIGN_PASSWORD=your_password`

**Build Command:**
```bash
python build/scripts/build_windows.py --msi --code-sign --env-file deploy/customer_configs/acme_corp.env
```

**Result:** Signed MSI installer ready for enterprise deployment.

---

## Scenario 5: Automated Build Pipeline

**Situation:** You have multiple customers and want to automate builds.

**Script:** `build_all_customers.ps1`
```powershell
# Build WebDrop Bridge for all customers

$PROJECT_ROOT = "C:\Development\VS Code Projects\webdrop_bridge"
$CONFIG_DIR = "$PROJECT_ROOT\deploy\customer_configs"
$BUILD_SCRIPT = "$PROJECT_ROOT\build\scripts\build_windows.py"

# Get all .env files for customers
$customerConfigs = @(
    "acme_corp.env",
    "globex_corporation.env",
    "initech.env",
    "wayne_enterprises.env"
)

$timestamp = Get-Date -Format "yyyy-MM-dd_HH-mm-ss"
$output_dir = "$PROJECT_ROOT\build\releases\$timestamp"
New-Item -ItemType Directory -Path $output_dir -Force | Out-Null

Write-Host "🚀 Building WebDrop Bridge for all customers..." -ForegroundColor Cyan
Write-Host ""

foreach ($config in $customerConfigs) {
    $customer_name = $config -replace '\.env$', ''
    $config_path = "$CONFIG_DIR\$config"
    
    Write-Host "Building for $customer_name..." -ForegroundColor Yellow
    
    # Build
    python $BUILD_SCRIPT --msi --env-file "$config_path"
    
    # Copy to output directory
    $msi_file = Get-ChildItem "$PROJECT_ROOT\build\dist\windows\*.msi" | Sort-Object LastWriteTime | Select-Object -Last 1
    if ($msi_file) {
        Copy-Item $msi_file.FullName "$output_dir\WebDropBridge-${customer_name}.msi"
        Write-Host "✅ Built: WebDropBridge-${customer_name}.msi" -ForegroundColor Green
    }
    
    Write-Host ""
}

Write-Host "✅ All builds complete!" -ForegroundColor Green
Write-Host "📦 Outputs in: $output_dir"
```

**Run:**
```bash
.\build_all_customers.ps1
```

**Result:** All customer builds in a timestamped directory:
```
build/releases/2024-01-30_14-30-00/
├── WebDropBridge-acme_corp.msi
├── WebDropBridge-globex_corporation.msi
├── WebDropBridge-initech.msi
└── WebDropBridge-wayne_enterprises.msi
```

---

## Configuration Best Practices

### 1. **Version Numbers**
Keep APP_VERSION in sync across all builds. Options:
- Use project `.env` with single source of truth
- Or explicitly set in each customer config

### 2. **Naming Convention**
Customer configs:
```
deploy/customer_configs/
├── {customer_name_lowercase}.env
├── {customer_name_lowercase}-staging.env
└── {customer_name_lowercase}-dev.env
```

### 3. **Security**
- Don't commit customer configs to git (if they contain sensitive URLs)
- Use `.gitignore`: `deploy/customer_configs/*.env` (but keep template)
- Store customer configs in secure location (separate backup/version control)

### 4. **Documentation**
In each customer config, add comments:
```dotenv
# WebDropBridge Configuration - ACME Corp
# Last updated: 2024-01-30
# Contact: support@acmecorp.com

# The web application they'll connect to
WEBAPP_URL=https://acme-drop.example.com/drop

# Directories they can access
ALLOWED_ROOTS=Z:/acme_files/,C:/Users/Public/ACME
```

### 5. **Testing**
Before building for a customer:
1. Copy their config to `.env` in project root
2. Run the app: `python src/webdrop_bridge/main.py`
3. Test the configuration loads correctly
4. Then build: `python build/scripts/build_windows.py --msi`

---

## Troubleshooting

### "Configuration file not found"
**Problem:** `.env` file specified with `--env-file` doesn't exist.

**Solution:**
```bash
# Check the file exists
ls deploy/customer_configs/acme_corp.env

# Use full path if relative path doesn't work
python build/scripts/build_windows.py --msi --env-file C:\full\path\to\acme_corp.env
```

### Build fails with no --env-file specified
**Problem:** Project root `.env` doesn't exist, but no `--env-file` provided.

**Solution:**
```bash
# Option 1: Create .env in project root
copy .env.example .env
# Edit .env as needed

# Option 2: Specify custom location
python build/scripts/build_windows.py --msi --env-file deploy/customer_configs/your_config.env
```

### App shows wrong configuration
**Problem:** Built app has old configuration.

**Solution:**
1. Delete previous build: `rmdir /s build\dist`
2. Verify you're using correct `.env`:
   - Check with `python build/scripts/build_windows.py --help`
   - Look at the console output during build: "📋 Using configuration: ..."
3. Rebuild

---

## Summary

With the new configuration bundling system, you can:
- ✅ Build once, configure for different customers
- ✅ Maintain centralized customer configurations
- ✅ Automate multi-customer builds
- ✅ Deploy to different environments (dev/staging/prod)
- ✅ No manual customer setup required after installation