分母

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

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

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

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

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

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

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

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

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

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

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

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

@ClericPy 为什么呢

感谢大佬们，我大概明白了，k8S 对这个情况的处理还是挺细的

@iyear
确实，是 resources 是 containerSpec 下面的东西，我没注意到这一点 :thumb_up:

huggingface 吗

@tianzhou 感谢！老板威武，看好 bytebase!

好我去康康，感谢大佬们！

@kd9yYw2RyhQwAwzn 嗯嗯，我说的开源产品就是 bytebase ，企业版使用过期之后我发现有一个核心问题：开源版本没法限制开发者访问生产数据库，所以才想着自己 DIY 一套流程的。

我们后端主要是好像没用 orm ，分了二十几个服务吧，都是裸写 SQL :laugh:

@xiaomudk orz 大佬!

可真好看

是用 LaTex 写的吗？是的话求个 LaTex 模板 @.@