How does whistle manage configuration rules and how to perform team collaboration?

Answer

Whistle provides multiple ways to manage configuration rules, including through web interface, command line, and configuration files, supporting team collaboration and version control.

Configuration Rule Management Methods

1. Web Interface Management

Access Management Interface:

shell
http://127.0.0.1:8899/

Operation Steps:

Click "Rules" tab
Add or modify rules in the editor
Click "Save" to save rules
Rules take effect immediately

Advantages:

Visual operation, intuitive and easy to use
Real-time preview of rule effects
Suitable for quick debugging

2. Command Line Management

Start whistle:

bash
# Start whistle
w2 start

# Start with specified port
w2 start -p 8080

# Start with specified configuration file
w2 start -f custom.rules

Stop whistle:

bash
w2 stop

Restart whistle:

bash
w2 restart

Check running status:

bash
w2 status

3. Configuration File Management

Default Configuration File Location:

Windows: C:\Users\{username}\.whistle\rules
Mac/Linux: ~/.whistle/rules

Configuration File Format:

shell
# Comment: This is a rule description

# Basic rule
www.example.com host 127.0.0.1:8080

# Grouped rules
# Local development
www.local.com host 127.0.0.1:3000
api.local.com host 127.0.0.1:3001

# Test environment
www.test.com host test.example.com
api.test.com host api-test.example.com

# Production environment
www.prod.com host prod.example.com

Rule Priority

1. Matching Order

Whistle matches rules in the order they appear in the configuration file, from top to bottom. Once a rule matches successfully, subsequent rules are not matched.

2. Priority Rules

Exact match > Wildcard match > Regular expression match
More specific rules should be placed earlier
Use # comments to organize rules

3. Rule Examples

shell
# Exact match (highest priority)
www.example.com/api/user host 127.0.0.1:8080

# Wildcard match
*.example.com/api/* host 127.0.0.1:8080

# Regular expression match (lowest priority)
/^https:\/\/www\.example\.com\/api\/.*/ host 127.0.0.1:8080

Team Collaboration Management

1. Configuration File Version Control

Use Git to manage configuration files:

bash
# Initialize Git repository
cd ~/.whistle
git init

# Add configuration file
git add rules

# Commit configuration
git commit -m "Add whistle rules"

# Push to remote repository
git remote add origin https://github.com/your-org/whistle-rules.git
git push -u origin main

Method 1: Share through Git

Place configuration files in Git repository
Team members clone repository
Use symbolic links to whistle configuration directory

bash
# Clone configuration repository
git clone https://github.com/your-org/whistle-rules.git ~/whistle-config

# Create symbolic link
ln -s ~/whistle-config/rules ~/.whistle/rules

Method 2: Import/Export Configuration Files

Export configuration file
Share through team collaboration tools
Other members import configuration

3. Environment Configuration Separation

Create configuration files for different environments:

shell
# Development environment
rules-dev:
www.dev.com host 127.0.0.1:3000
api.dev.com host 127.0.0.1:3001

# Test environment
rules-test:
www.test.com host test.example.com
api.test.com host api-test.example.com

# Production environment
rules-prod:
www.prod.com host prod.example.com
api.prod.com host api-prod.example.com

Switch environments:

bash
# Use development environment configuration
w2 start -f rules-dev

# Use test environment configuration
w2 start -f rules-test

# Use production environment configuration
w2 start -f rules-prod

Configuration Management Best Practices

1. Rule Organization

Group by function:

shell
# Local development services
# ====================
www.local.com host 127.0.0.1:3000
api.local.com host 127.0.0.1:3001

# Test environment
# ====================
www.test.com host test.example.com
api.test.com host api-test.example.com

# Data mocking
# ====================
www.example.com/api/user resBody://{mock-user.json}
www.example.com/api/list resBody://{mock-list.json}

2. Comment Standards

Add clear comments:

shell
# User interface mocking
# For frontend development, mock user data
www.example.com/api/user resBody://{mock-user.json}

# CORS handling
# Solve cross-origin issues in development environment
www.example.com resHeaders://{cors-headers.json}

3. Configuration Backup

Regularly backup configuration:

bash
# Backup current configuration
cp ~/.whistle/rules ~/.whistle/rules.backup.$(date +%Y%m%d)

# Restore configuration
cp ~/.whistle/rules.backup.20240101 ~/.whistle/rules

4. Configuration Validation

Validate rule syntax:

Check if rules are highlighted in web interface
Verify rules are taking effect
Test if rules work as expected

Advanced Configuration Management

1. Using Values Files

Create Values files to store configuration:

Create file: values.json

json
{
  "local-host": "127.0.0.1",
  "local-port": "3000",
  "test-host": "test.example.com",
  "mock-data": {
    "user": {
      "name": "Zhang San",
      "age": 25
    }
  }
}

Use in rules:

shell
www.example.com host {{local-host}}:{{local-port}}

2. Using Plugins to Extend Configuration

Develop configuration management plugin:

javascript
module.exports = function(server, options) {
  server.on('request', function(req, res) {
    // Dynamically configure based on environment variables
    const env = process.env.NODE_ENV || 'development';
    
    if (env === 'development') {
      req.headers['X-Environment'] = 'dev';
    } else if (env === 'production') {
      req.headers['X-Environment'] = 'prod';
    }
  });
};

3. Automated Configuration

Use scripts for automatic configuration:

bash
#!/bin/bash
# auto-config.sh

# Get current environment
ENV=${1:-dev}

# Copy configuration file for corresponding environment
cp ~/.whistle/rules-$ENV ~/.whistle/rules

# Restart whistle
w2 restart

echo "Whistle configured for $ENV environment"

Use script:

bash
./auto-config.sh dev    # Configure development environment
./auto-config.sh test   # Configure test environment
./auto-config.sh prod   # Configure production environment

Common Issues and Solutions

1. Rules Not Taking Effect

Check items:

Confirm rule syntax is correct
Check rule priority
Confirm whistle is running
Clear browser cache

2. Configuration Conflicts

Solutions:

Use more specific rules
Adjust rule order
Use comments to mark rule purpose

3. Configuration File Corruption

Recovery methods:

Restore from backup
Reinitialize configuration
Use version control to restore