如何在SST项目中实现无云厂商的CI/CD本地状态管理

背景介绍

SST(Serverless Stack)是一个流行的无服务器应用框架，通常与AWS等云服务商配合使用。但在某些特殊场景下，开发者可能需要在没有云服务商支持的环境中部署SST项目，同时希望在CI/CD流程中保持状态管理。

本地状态管理方案

传统SST部署依赖云服务商存储状态文件，但通过配置home: "local"可以实现纯本地状态管理。本文将介绍一种将状态文件纳入版本控制，并在CI/CD流程中同步的完整解决方案。

实现细节

1. 状态文件结构

SST本地状态主要包含两类文件：

• 应用状态文件：存储基础设施的当前状态
• 密码短语文件：用于敏感信息的加密

这些文件默认存储在~/.config/sst/state/目录下，按应用名称分类。

2. 核心脚本实现

准备阶段脚本(prepare_sst.sh)：

#!/bin/bash
# 参数：阶段名称(如mystagename)
SST_STAGE=$1

# 安装依赖
bun install --frozen-lockfile
bun sst install

# 获取SST配置目录
SST_CONFIG=$(bun sst version --verbose | grep config | awk '{split($0,a," "); print a[2]}')

# 创建目录结构
mkdir -p $SST_CONFIG/state/app/observability
mkdir -p $SST_CONFIG/state/passphrase/observability

# 从代码库复制状态文件
cp infra/state/app/$SST_STAGE.json $SST_CONFIG/state/app/observability/.
cp infra/state/passphrase/$SST_STAGE.json $SST_CONFIG/state/passphrase/observability/.

# 验证文件存在性
[ ! -f $SST_CONFIG/state/app/observability/$SST_STAGE.json ] && exit 1
[ ! -f $SST_CONFIG/state/passphrase/observability/$SST_STAGE.json ] && exit 1

提交阶段脚本(commit_local_stage.sh)：

#!/bin/bash
# 参数：阶段名称
SST_STAGE=$1

# 获取SST配置目录
SST_CONFIG=$(bun sst version --verbose | grep config | awk '{split($0,a," "); print a[2]}')

# 将状态文件复制回代码库
cp $SST_CONFIG/state/app/observability/$SST_STAGE.json infra/state/app/.
cp $SST_CONFIG/state/passphrase/observability/$SST_STAGE.json infra/state/passphrase/.

# 提交变更
git checkout -b main
git add .
git commit -m "feat: Update SST state"
git push --set-upstream origin main

3. CI/CD集成示例(Azure DevOps)

stages:
- stage: Deploy
  jobs:
  - job: deploy
    steps:
    - checkout: self
      persistCredentials: true
    
    # 配置Git
    - script: |
        git config --global user.email '[e-mail]'
        git config --global user.name 'Deploy Pipeline'
      
    # 安装Bun
    - task: Npm@1
      displayName: install bun
      inputs:
        command: custom
        customCommand: install -g bun
    
    # 准备环境
    - task: Bash@3
      displayName: Prepare SST
      inputs:
        filePath: infra/state/prepare_sst_stage.sh
        arguments: $(SST_STAGE)
    
    # 执行部署
    - bash: bun sst refresh --stage $(SST_STAGE) --print-logs
    - bash: bun sst deploy --stage $(SST_STAGE) --print-logs
    
    # 提交状态
    - task: Bash@3
      displayName: Commit SST state
      inputs:
        filePath: infra/state/commit_local_stage.sh
        arguments: $(SST_STAGE)

注意事项

1. 安全性考虑：状态文件中可能包含敏感信息，建议评估是否适合存入版本库
2. 并发控制：此方案不适合高并发部署场景，可能引发状态冲突
3. 文件路径：不同操作系统下SST配置目录可能有所不同
4. 版本兼容性：SST版本更新可能导致状态文件格式变化

扩展思考

这种本地状态管理方式虽然解决了无云厂商环境下的部署问题，但也带来了一些挑战：

1. 状态一致性：团队成员需要定期同步状态文件
2. 审计追踪：Git历史记录可作为简单的审计日志
3. 回滚机制：通过Git回退可快速实现基础设施回滚

对于小型团队或内部项目，这种方案提供了简单有效的状态管理方式，避免了维护额外云服务的开销。但对于大型项目或生产环境，仍建议考虑专业的远程状态存储方案。