面试题：复杂Bash脚本架构与版本控制优化

一、Bash 脚本架构设计

web_service_deployment/
├── bin/
│   └── deploy.sh
├── config/
│   ├── service1.conf
│   ├── service2.conf
│   └──...
├── logs/
│   └── deployment.log
├── src/
│   ├── service1/
│   │   ├── main.py
│   │   └── requirements.txt
│   ├── service2/
│   │   ├── app.js
│   │   └── package.json
│   └──...
└── README.md

deploy.sh 脚本主体

#!/bin/bash

# 全局变量
LOG_FILE="logs/deployment.log"
CONFIG_DIR="config"
SRC_DIR="src"

# 日志记录函数
log() {
    echo "$(date '+%Y-%m-%d %H:%M:%S') - $1" | tee -a $LOG_FILE
}

# 更新配置文件函数
update_config() {
    local service_name=$1
    local config_file="$CONFIG_DIR/$service_name.conf"
    # 这里可以添加更新配置文件的具体逻辑，例如使用 sed 命令替换配置项
    log "Updating $config_file"
    sed -i 's/old_value/new_value/g' $config_file
}

# 启动服务函数
start_service() {
    local service_name=$1
    local service_dir="$SRC_DIR/$service_name"
    cd $service_dir || { log "Failed to enter $service_dir"; return 1; }
    if [ -f "requirements.txt" ]; then
        log "Installing Python dependencies for $service_name"
        pip install -r requirements.txt
    elif [ -f "package.json" ]; then
        log "Installing Node.js dependencies for $service_name"
        npm install
    fi
    if [ -f "main.py" ]; then
        log "Starting Python service $service_name"
        nohup python main.py &> /dev/null &
    elif [ -f "app.js" ]; then
        log "Starting Node.js service $service_name"
        nohup node app.js &> /dev/null &
    else
        log "Unsupported service type for $service_name"
        return 1
    fi
    cd - &> /dev/null
    return 0
}

# 主函数
main() {
    local services=("service1" "service2" "service3")
    for service in "${services[@]}"; do
        update_config $service
        start_service $service
    done
}

main

二、Git 分支策略和标签管理

分支策略
- 主分支（master）：用于存放稳定的、可发布的代码。只有在通过全面测试后，才允许将代码合并到 master 分支。该分支上的代码直接对应生产环境的部署。
- 开发分支（develop）：所有新功能的开发都在这个分支上进行。开发人员从 develop 分支创建各自的功能分支进行开发，完成后将功能分支合并回 develop 分支。
- 功能分支（feature-*）：基于 develop 分支创建，每个功能分支用于开发一个独立的功能。命名规则为 feature-功能描述，例如 feature-add-new-service。开发完成并通过自测后，将功能分支合并回 develop 分支。
- 测试分支（test）：从 develop 分支创建，用于集成测试。将 develop 分支的代码合并到 test 分支进行全面的测试，包括单元测试、集成测试、性能测试等。测试通过后，将 test 分支合并到 master 分支。
- 修复分支（hotfix-*）：基于 master 分支创建，用于紧急修复生产环境中的问题。命名规则为 hotfix-问题描述，例如 hotfix-service1-crash。修复完成并测试通过后，将修复分支同时合并到 master 分支和 develop 分支，以保证生产环境和开发环境的一致性。
标签管理
- 版本标签：在 master 分支上打版本标签，例如 v1.0、v1.1 等。每次发布新版本时，在 master 分支上创建一个对应的版本标签，便于跟踪和回滚。
- 测试标签：在 test 分支上打测试标签，例如 test-1.0、test-1.1 等。用于标识测试分支上不同阶段的代码状态，方便测试人员和开发人员进行沟通和协作。
- 功能标签：在功能分支上打功能标签，例如 feature-add-new-service-1.0。用于记录功能分支的开发进度和状态，便于回顾和追溯功能开发过程。

通过合理的分支策略和标签管理，可以有效地优化脚本的开发、测试和发布流程，提高项目的可维护性和扩展性。

面试题：复杂Bash脚本架构与版本控制优化

知识考点

面试题答案

一、Bash 脚本架构设计

二、Git 分支策略和标签管理