- 主题:怀念过去jenkins一把梭时代的ci/cd
这个，生产环境重新拉代码构建，不太好吧...
【 在 Mikov (Mikov Chain) 的大作中提到: 】
: 首先, 对于90%的Java项目, Jenkins依然很好用
: 其次, "好处是，从头到尾，你不需要任何一台本地服务器，也没有任何重复性劳动" 这个目标用jenkins一把梭完全没问题
: 我们在生产环境有一套专用的Jenkins, 上线时直接在生产环境拉代码构建部署, 不需要学习任何新语言.
: ...................
--
FROM 111.199.220.*
这种管理工具的访问凭证管理是大麻烦
【 在 sayinger 的大作中提到: 】
: 这些放到一个工具镜像里呗，然后这个工具镜像单独一个仓库，同样走CI/CD，分出层次就好了。 ...
--
FROM 39.144.104.*
这算是最佳实践了, 最近几年的项目我都是这样做的
年初给一个微软云的客户做方案也是用的这个
不知担心在何处?
【 在 sayinger 的大作中提到: 】
: 这个，生产环境重新拉代码构建，不太好吧...
:
--
FROM 223.72.71.*
担心代码被改动
如果pull之后再checkout一个之前打过的tag，那风险就会小很多了
我们这里现在的做法就是uat打包，测完没问题之后就直接把uat的镜像包推到生产，这
样可以确保万无一失
【 在 Mikov (Mikov Chain) 的大作中提到: 】
: 这算是最佳实践了, 最近几年的项目我都是这样做的
: 年初给一个微软云的客户做方案也是用的这个
: 不知担心在何处?
: ...................
--
FROM 180.167.95.*
从仓库里pull的代码被改动？全自动的构建加部署，还有这个可能性？
【 在 guestking 的大作中提到: 】
: 担心代码被改动
: 如果pull之后再checkout一个之前打过的tag，那风险就会小很多了
: 我们这里现在的做法就是uat打包，测完没问题之后就直接把uat的镜像包推到生产，这
: ...................
--
FROM 117.136.38.*
测试完成之后 到 上线之前
master分支被提交了新的代码
【 在 Mikov (Mikov Chain) 的大作中提到: 】
: 从仓库里pull的代码被改动？全自动的构建加部署，还有这个可能性？
--
FROM 180.167.95.*
生产发布基于 tag/revision 就完了
直接用 master head 当然问题多多
【 在 guestking (无) 的大作中提到: 】
: 测试完成之后 到 上线之前
: master分支被提交了新的代码
--
FROM 211.97.123.*
是的，我前面就是这么说的
【 在 cybereagle (2/3的沉默@XMUCSD) 的大作中提到: 】
: 生产发布基于 tag/revision 就完了
: 直接用 master head 当然问题多多
--
FROM 180.167.95.*
这和生产环境直接重新拉版本构建不矛盾
【 在 guestking (无) 的大作中提到: 】
: 是的，我前面就是这么说的
--
FROM 211.97.123.*
那你得确保所有的依赖都是稳定的，不仅仅是你自己的代码。
其实既然在测试环境已经完成了构建，直接拷贝到生产环境不是更直接么
【 在 Mikov (Mikov Chain) 的大作中提到: 】
: 这算是最佳实践了, 最近几年的项目我都是这样做的
: 年初给一个微软云的客户做方案也是用的这个
: 不知担心在何处?
: ...................
--
FROM 221.220.225.*