基于 GXL 的开源工作流引擎,用于定义流程、组织执行逻辑、编排工程动作,并把自动化过程沉淀为可复用工作流。
Galaxy-Flow 的职责很清楚:把自动化流程写清楚、组织清楚、执行清楚。它关注的是流程模型、执行能力和工程动作编排,而不是系统交付结构。
env 负责变量和上下文,flow 负责执行路径。环境切换不再和命令步骤混写在同一个脚本里。
支持前置、主流程、后置关系,也支持模块化复用与参数化调用。
通过 #[transaction] 和 #[undo(...)] 显式定义失败后的回退关系,而不是把清理逻辑散落在脚本分支里。
执行结果会写入本地 report,日志和任务状态也可以接入上报链路,便于后续追踪与集成。
支持通过 extern mod 直接引用远端仓库模块,例如 extern mod net { git = "https://example.com/repo.git", branch = "main"; },也支持按 tag 或 channel 拉取。
既可以通过 gx.tpl 生成模板化配置,也可以通过 gx.patch_file 按 marker 对现有文件做定点修改、注释或反注释,避免把配置变更散落在手写脚本里。
Python 可以写自动化,行业里也有成熟 workflow runtime;但它们更多解决的是通用流程执行、调度和可靠性。Galaxy-Flow 解决的是另一层问题:把 Git Mod 复用、流程声明、回滚边界和运维动作统一进同一套模型。
Galaxy-Flow 不是在替代所有 workflow runtime,而是在提供一套更贴近交付与运维场景的流程语言和执行模型。
runtime = DeliveryRuntime()
ops = runtime.load_git_mod("https://github.com/example/ops-mods.git", branch="main")
env = "prod"
def render():
render_tpl("./tpls", "./out", "./values.json")
def patch():
patch_file("./nginx.conf", marker="upstream", value="api_upstream")
def deploy():
ops.deploy(env=env)
def rollback():
run("./rollback.sh")
runtime.run_flow([render, patch, deploy], rollback=rollback)
extern mod ops { git = "https://github.com/example/ops-mods.git", branch = "main"; }
mod main {
env prod : base;
#[transaction, undo(rollback)]
flow @release | render | patch | deploy;
flow render { gx.tpl(tpl: "./tpls", dst: "./out", file: "./values.json"); }
flow patch { gx.patch_file(file: "./nginx.conf", action: "set", marker: "upstream", value: "\"api_upstream\""); }
flow deploy { ops.deploy(env: "prod"); }
flow rollback { gx.shell(shell: "./rollback.sh"); }
}
这个例子要表达的是:即便团队已经有成熟 runtime,仍然不等于已经有了 Galaxy-Flow 这一层能力。
extern mod 这样的 Git 模块复用模型,也不会把模板、配置修改、回滚关系和工程动作统一收进同一种语言结构。load_git_mod(...)、run_flow(...) 这样的能力,通常还要在 runtime 之上再实现一层自己的交付或执行框架。env、flow、gx.tpl、gx.patch_file、#[transaction]、#[undo(...)] 这些显式结构里。如果你要先理解“流程如何定义与执行”,从 Galaxy-Flow 开始。如果你要理解“系统如何组织与交付”,继续看 Galaxy-Ops。