如果流程是标准化的，为啥每次都要写这些东西。

另外，现在有很多CI工具可以帮你简化一大堆事情，自己再写点模板，后面定义具体项目的CI/CD就简单多了：

  # .gitlab-ci.yml
  include:
    - project: 'devops/ci-templates'
      file: '/build/Java.Build.gitlab-ci.yml'   # 指定编译模板
    - project: 'devops/ci-templates'
      file: '/deploy/Web.Deploy.gitlab-ci.yml'  # 指定部署模板


  variables:
  #  CANARY_ENABLED: "true"                     # 是否启用金丝雀部署
    XXX_DEV_REPLICAS: 1                    # dev环境副本数为1
    XXX_STG_REPLICAS: 2                    # stg环境副本数为1
    CANARY_PIAOSHEN_PRD_REPLICAS: 1             # prd环境的金丝雀部署副本数为1
    XXX_PRD_REPLICAS: 4                    # prd环境副本数为4
    ADDITIONAL_HOSTS: "live-web.$CI_ENVIRONMENT_NAME.com"
    XXX_PRD_ADDITIONAL_HOSTS: "live-web.xxx.com"
  #  INCREMENTAL_ROLLOUT_MODE: "manual"         # 滚动部署模式为手动，可选项为: manual 手动，timed 定时，为空则禁用滚动部署模式


  .deploy:
    variables:
      HELM_RELEASE_NAME: "live-web"
    environment:
      url: "live-web.k8s.${CI_ENVIRONMENT_NAME}.com"


【 在 oldwatch (一条叫java的鱼◎城内风光独好) 的大作中提到: 】
: 美好旧时光的CI/CD:
: 内网装个jenkins，鼠标点点从git拉代码，调maven/npm/...构建
: 写段脚本把生成结果上传服务器
: 重启服务，完活
: 容器/公有云时代的CI/CD：
: 写脚本将目标文件上传到S3，在aws管理控制台里写段脚本
: 从ec2到s3拉数据，更新/发布服务，再把这段脚本保存在云端以备调用
: 创建一个单独的ci/cd流程项目
: 将以上各种脚本的调用全写进一个dockerfile
: 把构建出来的docker镜像上传某个公有repo
: 在业务项目中再写个脚本，让脚本在提交master时自动在git服务器云端执行
: 脚本会依次下载各种docker镜像，创建容器
: 执行容器内的脚本，完成构建，上传目标文件，发布全过程
: 最后别忘了为ci/cd流程项目配置一个
: 更新dockerfile后自动构建docker镜像并发布到公共repo的脚本……
: 好处是，从头到尾，你不需要任何一台本地服务器，也没有任何重复性劳动
: 代价是，必须学习三种不同领域脚本的语法格式
--
FROM 111.199.220.*

这些放到一个工具镜像里呗，然后这个工具镜像单独一个仓库，同样走CI/CD，分出层次就好了。

【 在 oldwatch (一条叫java的鱼◎城内风光独好) 的大作中提到: 】
: 但是对于服务调度方节省了很多折腾环境的工作……
: 毕竟现在的运行时除了java/python/node/powershell/bash这些老黄历外，
: 还有一大堆诸如aws-cli,azure-cli,firebase,heroku之类的存在
: ...................
--
FROM 111.199.220.*

那你得确保所有的依赖都是稳定的，不仅仅是你自己的代码。

其实既然在测试环境已经完成了构建，直接拷贝到生产环境不是更直接么

【 在 Mikov (Mikov Chain) 的大作中提到: 】
: 这算是最佳实践了, 最近几年的项目我都是这样做的
: 年初给一个微软云的客户做方案也是用的这个
: 不知担心在何处?
: ...................
--
FROM 221.220.225.*

【 在 Mikov (Mikov Chain) 的大作中提到: 】
: 生产和测试用的nexus私服肯定是同一个, 依赖的一致性没问题
: 在生产环境构建, 解决的问题是两个:
: 1. 减小传输代价. 因为是远程发布, 几十上百M的文件传输会占发布时间的大头. 对于一个项目十几个模块的完整发布, 这个代价太大了, 如果有紧急修复, 根本等不起.
    设计好镜像分层可以在很大程度上解决这个问题，否则你扩容的时候也会存在镜像传输过大的问题。

: 2. 生产隔离. 生产环境对研发和测试可以做到完全隔离. 那些在本地构建的, 你是可以把一部分参数配到脚本里, 但是你的jar包war包里面几乎是一定会带着生产配置. 用远程构建可以很好避免这个问题.
    你说的这种配置，恐怕认为是代码更合适，无非写到哪里而已，否则只要修改就得重新build，岂不是更重，紧急调整的时候更等不起，或者是所谓“根本没打算改”的配置。没看出隔离了什么，传输源代码跟镜像的区别而已
--
FROM 221.220.225.*

镜像交付，测试环境测完之后推到生产镜像仓库

【 在 eventvwr (精光互撸娃) 的大作中提到: 】
: 你们生产环境运行的jar或者war包是哪来的？
--
FROM 221.220.225.*