feat: Implement configuration bundling for customer-specific builds and enhance build scripts
This commit is contained in:
parent
4e5deab7e9
commit
a355c13c82
5 changed files with 750 additions and 22 deletions
299
docs/CUSTOMER_BUILD_EXAMPLES.md
Normal file
299
docs/CUSTOMER_BUILD_EXAMPLES.md
Normal file
|
|
@ -0,0 +1,299 @@
|
|||
# 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
|
||||
Loading…
Add table
Add a link
Reference in a new issue