上线时需要将迭代期内的各种配置改动同步到生产环境，有没有好用的配置备忘录的工具？

[eephee]

比如代码从开发环境提交到 staging 环境，那么对应的配置（比如 服务配置、环境变量、数据库改动、创建 s3 bucket...）也需要上到对应的环境，如果同时有多个环境，那么配置的管理就比较麻烦，很容易遗漏，有什么好用的工具来做这个事情吗？

关于数据库改动，有 yearning 或者 bytebase 这样的工具，但是这俩工具只针对数据库的场景

[chendy]

在项目里专门建个路径，里面放一堆 txt （ md 也行，但是考虑到有些大哥不知道 md 是啥，还是 txt 稳妥）
里面详细描述发版过程（比如说，先备份数据库到哪里哪里，然后修改表定义如何如何
虽然土，但是还是很有效的，主要对人员水平要求相对低，对着干就行
还适合各种奇形怪状的想自动化但是成本过于高的项目们

[LeegoYih]

每个版本迭代都会写技术方案文档（比如语雀、金山文档），除了技术方案本身还会把需要执行的脚本、添加的配置、申请的资源、涉及的服务等列出来做一个 TODO LIST ，开发期间有变动就补充，及时通知相关人员，发布前完成一个打一个勾。
工作这么多年没有发生过漏配置、SQL 漏执行类似低级错误。

推动团队流程规范最重要，工具看团队哪个方便用哪个。

[dobelee]

每个需求方案设计时就建一个 todo list 文档。

[sunxiaping521]

Jenkins + ArgoCD ，不过 Jenkins 只是 CI 工具，可以替换成任意的 CI 工具，ArgoCD 是持续集成工具，你可以了解一下。

[flyqie]

@chendy #1

真有大哥到现在都不知道 md 是啥的吗。。有点震惊。

txt 样式这块非常不好搞啊。。

比如表格，加粗，段落，字体大小，代码块，列表什么的。。

[WispZhan]

先手动整理流程，建立规范。 然后尝试用自动化方案，减少重复。
1. 整理迭代内容，输出 TODO-List
2. 明确迭代规范，将内容流程化，保证换个人也能正常事实。解放自己
3. 调研配置、DB 的 Migration ，比如数据库的 Flyway 或者 Liquibase 。
4. 集成到 CI/CD ，解放团队。

[WispZhan]

写脚本，写工具。 没有工具就制造工具。DRY

[eephee]

看了下好像大家普遍会用文档的形式来记录，emmm 为啥我总感觉文档的形式记录不太直观。

我目前是尝试使用 JIRA 来搞，但是 JIRA 里面一个事项的状态转换是有流程顺序的，对于环境比较多而且并行的情况下（比如两家私有部署客户的配置更改）还是没法适用。

k8s 配置的话，我们测试环境已经在尝试使用 helm 那套了，但是生产环境一开始没有用 helm 。如果需要使用 helm 的话，那些负载得重新创建，一直不太敢下手。。。

[arischow]

写成 release plan / rollback plan

[skyrim61]

都是记事本记录, 等时间久了就忘记, 然后再写一个记事本,然后故障还是会发生

[eephee]

@arischow 请教下有什么好用的工具来做这个事情嘛？还是也是写成文档呢？感觉这个文档的格式约定也需要好好斟酌一下

[proxychains]

README 呗. changlog 啥的也加上, 跟着项目迭代走

[chendy]

@flyqie 有，而且很多…
这种文档不需要啥格式，就是把所有需要的操作罗列下去就行
最多就是空格换行做好，方便用的时候复制粘贴

[sunxiaping521]

@eephee 如果我没记错的话，JIRA 已经死了吧

[flyqie]

@proxychains #12

readme 可以理解，changelog 不太理解。。

changelog 可以通过 git commit log 替代吧，单独抽个 changelog 出来会不会出现更新不当的问题？

[nothingistrue]

配置也需要版本化。DevOps 要求的可不止代码版本化，配置、构建脚本都是要做版本化的。

[sunxiaping521]

@nothingistrue 那不就是 ArgoCD 吗？太好用了~

[arischow]

@eephee 重新看了一下你的描述，你们的配置应该是没有人代码管理对吗？（例如用 Terraform / Helm / Jsonnet ）

我们对于没有上云的项目（没有办法用到我前面所述的这些工具）现在的做法是需要写 release plan / rollback plan ，如果你们公司有订阅 Confluence / Jira ，用来写文档作为知识共享是再方便不过。Release plan / rollback plan 也应该让其他同事 review ，具体的文档格式当然可以约定，我认为一个合格的 plan 应该是交由哪位同事做，只要看着文档来操作就可以完成。

[eephee]

@arischow 确实我们目前没有很贯彻 configuration as code 那一套，目前 helm charts 也是放在一个单独的仓库里面的，还没有放到每个服务的仓库里面去。

看下来其实最好的做法就是尽可能地将所有的配置放到仓库里面：比如创建 s3 bucket 也可以搞一个脚本放到版本控制里面，然后一切交给版本管理的流程去做。

但是其实还是有一些东西要人为操作的：比如某些比较敏感的环境变量（比如一些 password ），还是需要人去配置的，这部分东东没法放到仓库中。

[eephee]

@sunxiaping521 请教一下，使用 argocd 时，每当有新提交，就需要构建最新的镜像，并且把服务的镜像也更新。那这样的话，是不是每一次服务代码更新，都需要把 yaml 文件改一下呢？那这样的话是不是充斥了很多改 image tag 的提交呢？