HIM-public/webdrop-bridge
1
0
Fork 0
Code Issues Pull requests Projects Releases 3 Packages Wiki Activity Actions 1
webdrop-bridge/docs/CUSTOMER_BUILD_EXAMPLES.md

8.3 KiB
Raw Blame History

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:

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

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:

# 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

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:

# 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:

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

# 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:

.\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:

# 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:

# 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:

# 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