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

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

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

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

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

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

@chendy #1

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

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

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

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

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

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

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

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

写成 release plan / rollback plan

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

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

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

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

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

@proxychains #12

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

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

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

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

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

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

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

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

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

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

@eephee 关于密码管理的实践有很多，我也只是略懂皮毛，我们现在用的是 AWS Secrets Manager ，其他云商应该也有对标产品。

如果想用代码管理也可以看看： https://github.com/getsops/sops

我们不论是项目还是需求都会编写上线清单，上线前按照上线清单以及上线计划执行

@sunxiaping521 argo cd 应该是持续交付工具（根据官网），cd = continuous delivery

@eephee ArgoCD 是持续部署工具吧；逻辑其实很简单，ArgoCD 支持 kustomize 、基本的 yaml 方式以及 Hem 等方法，并且其实就是在 Git 仓库中维护了一个项目而已；当你用 CI 工具（持续集成工具，如：Jenkins ） 等将镜像构建并推送到 Docker 仓库（如：Harbor 仓库），然后更新 Git 仓库中的镜像版本即可，ArgoCD 默认会 3 分钟自动同步 Git 仓库中的配置到环境中；当然，你也可以手动同步；或者配置 Argo 和 Git 仓库的钩子，实现自动的持续部署。

@eephee @AngryPanda 我没办法发流程图的图片，aHR0cHM6Ly9pLmltZ3VyLmNvbS9xb0hiZDBsLnBuZw== 这个是 base64 编码，你解码，就能看到对应的图片地址了。

我不是很理解这个东西需要什么特别的工具吗。。
难道不是你要习惯性的检查一下即将要上线的代码或者文档起码看一下 commit 的记录 应该也能想到需要加个配置吧。。。

@sunxiaping521
> 然后更新 Git 仓库中的镜像版本即可

这样的话那个 git 仓库里面是不是充斥了大量的改 docker image tag 得提交？主要是这点我不太喜欢

@8355 仓库太多了，我没有参与核心业务开发，所以看不过来

@eephee 随你~

@sunxiaping521 请教一下你们也是微服务吗？能不能分享一下你们的那个存储 charts 的 git 仓库的结构呢？

最终走了

* helm/helmfile/helm-secrets/sops
* gitlab-ci/yq

的路线，只不过是用 `helmfile template` 生成 k8s manifest 最后 `kubectl apply` 的

最终还是弃用了 helmfile ，直接将 charts 包放在中各个仓库下面，结合 gitlab-ci ，目前用下来感觉很不错，打算长期这样使用