这是一个创建于 1074 天前的主题，其中的信息可能已经有所发展或是发生改变。
比如代码从开发环境提交到 staging 环境，那么对应的配置（比如 服务配置、环境变量、数据库改动、创建 s3 bucket...）也需要上到对应的环境，如果同时有多个环境，那么配置的管理就比较麻烦，很容易遗漏，有什么好用的工具来做这个事情吗？
关于数据库改动，有 yearning 或者 bytebase 这样的工具，但是这俩工具只针对数据库的场景
 |
1 chendy 2023 年 7 月 5 日 1
在项目里专门建个路径，里面放一堆 txt （ md 也行，但是考虑到有些大哥不知道 md 是啥，还是 txt 稳妥） |
 |
2 LeegoYih 2023 年 7 月 5 日 1
每个版本迭代都会写技术方案文档（比如语雀、金山文档），除了技术方案本身还会把需要执行的脚本、添加的配置、申请的资源、涉及的服务等列出来做一个 TODO LIST ，开发期间有变动就补充，及时通知相关人员，发布前完成一个打一个勾。 推动团队流程规范最重要，工具看团队哪个方便用哪个。 |
 |
3 dobelee 2023 年 7 月 5 日 1
每个需求方案设计时就建一个 todo list 文档。 |
 |
4 sunxiaping521 2023 年 7 月 5 日 1
Jenkins + ArgoCD ，不过 Jenkins 只是 CI 工具，可以替换成任意的 CI 工具，ArgoCD 是持续集成工具，你可以了解一下。 |
 |
5 flyqie 2023 年 7 月 5 日 via Android 1
|
 |
6 WispZhan 2023 年 7 月 5 日 1
先手动整理流程，建立规范。 然后尝试用自动化方案，减少重复。 |
|
7 WispZhan 2023 年 7 月 5 日 1
写脚本，写工具。 没有工具就制造工具。DRY |
 |
8 eephee 2023 年 7 月 5 日看了下好像大家普遍会用文档的形式来记录，emmm 为啥我总感觉文档的形式记录不太直观。 我目前是尝试使用 JIRA 来搞，但是 JIRA 里面一个事项的状态转换是有流程顺序的，对于环境比较多而且并行的情况下（比如两家私有部署客户的配置更改）还是没法适用。 k8s 配置的话，我们测试环境已经在尝试使用 helm 那套了，但是生产环境一开始没有用 helm 。如果需要使用 helm 的话，那些负载得重新创建，一直不太敢下手。。。 |
 |
9 arischow 2023 年 7 月 5 日 via iPhone 1
写成 release plan / rollback plan |
 |
10 skyrim61 2023 年 7 月 5 日 1
都是记事本记录, 等时间久了就忘记, 然后再写一个记事本,然后故障还是会发生 |
 |
12 proxychains 2023 年 7 月 5 日README 呗. changlog 啥的也加上, 跟着项目迭代走 |
|
15 flyqie 2023 年 7 月 5 日 via Android@proxychains #12 readme 可以理解，changelog 不太理解。。 changelog 可以通过 git commit log 替代吧，单独抽个 changelog 出来会不会出现更新不当的问题？ |
 |
16 nothingistrue 2023 年 7 月 5 日配置也需要版本化。DevOps 要求的可不止代码版本化，配置、构建脚本都是要做版本化的。 |
|
18 arischow 2023 年 7 月 5 日@eephee 重新看了一下你的描述，你们的配置应该是没有人代码管理对吗？（例如用 Terraform / Helm / Jsonnet ） 我们对于没有上云的项目（没有办法用到我前面所述的这些工具）现在的做法是需要写 release plan / rollback plan ，如果你们公司有订阅 Confluence / Jira ，用来写文档作为知识共享是再方便不过。Release plan / rollback plan 也应该让其他同事 review ，具体的文档格式当然可以约定，我认为一个合格的 plan 应该是交由哪位同事做，只要看着文档来操作就可以完成。 |
|
19 eephee 2023 年 7 月 5 日@arischow 确实我们目前没有很贯彻 configuration as code 那一套，目前 helm charts 也是放在一个单独的仓库里面的，还没有放到每个服务的仓库里面去。 看下来其实最好的做法就是尽可能地将所有的配置放到仓库里面：比如创建 s3 bucket 也可以搞一个脚本放到版本控制里面，然后一切交给版本管理的流程去做。 但是其实还是有一些东西要人为操作的：比如某些比较敏感的环境变量（比如一些 password ），还是需要人去配置的，这部分东东没法放到仓库中。 |
|
20 eephee 2023 年 7 月 5 日@sunxiaping521 请教一下，使用 argocd 时，每当有新提交，就需要构建最新的镜像，并且把服务的镜像也更新。那这样的话，是不是每一次服务代码更新，都需要把 yaml 文件改一下呢？那这样的话是不是充斥了很多改 image tag 的提交呢？ |
 |
22 zhuzhibin 2023 年 7 月 5 日 via iPhone我们不论是项目还是需求都会编写上线清单，上线前按照上线清单以及上线计划执行 |
|
24 sunxiaping521 2023 年 7 月 6 日@eephee ArgoCD 是持续部署工具吧；逻辑其实很简单，ArgoCD 支持 kustomize 、基本的 yaml 方式以及 Helm 等方法，并且其实就是在 Git 仓库中维护了一个项目而已；当你用 CI 工具（持续集成工具，如：Jenkins ） 等将镜像构建并推送到 Docker 仓库（如：Harbor 仓库），然后更新 Git 仓库中的镜像版本即可，ArgoCD 默认会 3 分钟自动同步 Git 仓库中的配置到环境中；当然，你也可以手动同步；或者配置 Argo 和 Git 仓库的钩子，实现自动的持续部署。 |
|
26 sunxiaping521 2023 年 7 月 6 日@eephee @AngryPanda 我没办法发流程图的图片，aHR0cHM6Ly9pLmltZ3VyLmNvbS9xb0hiZDBsLnBuZw== 这个是 base64 编码，你解码，就能看到对应的图片地址了。 |
 |
27 8355 2023 年 7 月 6 日我不是很理解这个东西需要什么特别的工具吗。。 |
|
28 eephee 2023 年 7 月 6 日 via iPhone@sunxiaping521 这样的话那个 git 仓库里面是不是充斥了大量的改 docker image tag 得提交？主要是这点我不太喜欢 |
|
32 eephee 2023 年 8 月 7 日最终走了 * helm/helmfile/helm-secrets/sops 的路线，只不过是用 `helmfile template` 生成 k8s manifest 最后 `kubectl apply` 的 |
|
33 eephee 2023 年 8 月 26 日最终还是弃用了 helmfile ，直接将 charts 包放在中各个仓库下面，结合 gitlab-ci ，目前用下来感觉很不错，打算长期这样使用 |
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。