- 主题:怀念过去jenkins一把梭时代的ci/cd
jenkins直接在vpc内部跑么？
【 在 cmkylin (Kylin.C) 的大作中提到: 】
: 看标题吓我一跳，还以为自己out了。
: 实际上，aws+jackins，一样就是点点点就完事儿啊，舒服的很。
--
FROM 116.233.186.*
大部分都是这样干的吧
最多敏感信息拉到环境变量里
【 在 Mikov (Mikov Chain) 的大作中提到: 】
: 这么说, 你们应该是在代码仓库里维护了各个环境的配置了, 生产环境换一个profile就可以用?
--
FROM 116.233.186.*
不知道啊，sre搞的，我就知道写完代码提到gitlab上，jackins就有了，点点就编译了，过了就可以部署测试环境了，测试完点点就可以发布了~
【 在 oldwatch 的大作中提到: 】
: jenkins直接在vpc内部跑么？
:
:
: ...................
--
FROM 210.77.180.*
应该是在每个环境有单独的slave，不过话说gitlab ci就蛮好用的，jenkins太老了
【 在 cmkylin (Kylin.C) 的大作中提到: 】
: 不知道啊，sre搞的，我就知道写完代码提到gitlab上，jackins就有了，点点就编译了，过了就可以部署测试环境了，测试完点点就可以发布了~
--
FROM 221.220.225.*
网络传输慢的确是个问题
但是你直接在成产环境上面build镜像，不是也一样要从网上下基础景象吗？
【 在 Mikov (Mikov Chain) 的大作中提到: 】
: 生产和测试用的nexus私服肯定是同一个, 依赖的一致性没问题
: 在生产环境构建, 解决的问题是两个:
: 1. 减小传输代价. 因为是远程发布, 几十上百M的文件传输会占发布时间的大头. 对于一个项目十几个模块的完整发布, 这个代价太大了, 如果有紧急修复, 根本等不起.
: ...................
--
FROM 180.167.95.*
我们现在的配置是通过环境变量注入的
【 在 Mikov (Mikov Chain) 的大作中提到: 】
: 这么说, 你们应该是在代码仓库里维护了各个环境的配置了, 生产环境换一个profile就可以用?
--
FROM 180.167.95.*
我的原则是代码仓库里不留配置
各个环境的访问权限是一把钥匙, 各个环境的服务配置是另一把钥匙, 拿到代码就等于拿到了后者
而员工总是会离职的, 离职了代码99%会留一份, 这个代码说不准什么时候手一抖就上github了
我倾向于不让他们有犯错误的机会
【 在 oldwatch 的大作中提到: 】
: 大部分都是这样干的吧
:
: 最多敏感信息拉到环境变量里
: ...................
--
FROM 60.253.242.*
各有各的好处
Gitlab CI我也用, 我拿它去构建不同发行版的deb, 但是我不会用它去搞java项目.
Jenkins是很老, 但是很好用, jenkins也有ci
【 在 sayinger 的大作中提到: 】
: 应该是在每个环境有单独的slave，不过话说gitlab ci就蛮好用的，jenkins太老了
:
--
FROM 60.253.242.*
本地构建都是有缓存的, 依赖没变就不会走传输
【 在 guestking 的大作中提到: 】
: 网络传输慢的确是个问题
: 但是你直接在成产环境上面build镜像，不是也一样要从网上下基础景象吗？
:
--
FROM 60.253.242.*
镜像传输是个问题，不知道除了镜像分层，还有没有差异化更新技术用在cd上，就像OS或游戏的差分增量包一样的东西
配置的东西，启动参数上区分不同的配置中心好像更简洁？
【 在 Mikov 的大作中提到: 】
: 生产和测试用的nexus私服肯定是同一个, 依赖的一致性没问题
: 在生产环境构建, 解决的问题是两个:
: 1. 减小传输代价. 因为是远程发布, 几十上百M的文件传输会占发布时间的大头. 对于一个项目十几个模块的完整发布, 这个代价太大了, 如果有紧急修复, 根本等不起.
: ...................
--
FROM 103.61.155.*