前端发布系统迭代 - 图1include需要gitlab版本升级到11.4以上

Git Runner
基于shell或者docker进行安装
https://www.yuque.com/mty/here/zcmesl#Z7kBz

Gitlab-Api
基于gitlab-api，封装gitlab相关操作
项目列表
项目详情
项目中的构建任务

关键词 描述 支持版本
script 被 runner 执行的shell 脚本
after_script 重写一套在 job 后执行的命令。
allow_failure 允许 job 失败，失败的 job 不会导致 commit 状态改变
artifacts 成功后要附加到job的文件和目录列表。仍然可用的：artifacts:paths, artifacts:exclude, artifacts:expose_as, artifacts:name, artifacts:untracked, artifacts:when, artifacts:expire_in, and artifacts:reports.
before_script 重写一套在 job 前执行的命令。
cache 应在后续运行期间缓存的文件列表。也可用：cache:paths, cache:key, cache:untracked, cache:when, and cache:policy.
coverage 给定job的代码覆盖率设置。
dependencies 定义了该job依赖哪一个job，如果设置该项，可以通过artifacts设置 不支持
except 限制未创建作业的时间。也可用：except:refs, except:kubernetes, except:variables, and except:changes.
extends 此作业继承的配置项。
image 使用 docker 镜像，也可用：image:name and image:entrypoint.
include 允许此作业包含外部YAML文件。也可用：include:local, include:file, include:template, and include:remote. 11.4
interruptible 定义在较新的运行使job变得冗余时是否可以取消job。 12.3
only 限制 job 创建的时间，也可用：only:refs, only:kubernetes, only:variables, and only:changes.
pages 上传与 gitlab pages 一起使用的结果 不支持
parallel 一个 job 的多少个实例可以同时运行 不支持
release 指示运行程序生成一个发布对象。 13.2
resource_group 限制 job 并发 12.7
retry 在失败的情况下，一个job可以自动重试几次。
rules 用于评估和确定作业的选定属性的条件列表，以及是否创建了该属性。不得only/except一起使用。
services 使用 Docker services images，也可用：services:name, services:alias, services:entrypoint, and services:command. 不支持
stage 定义 job 阶段（默认：test）
timeout 定义优先于项目范围设置的自定义作业级超时。 12.3
trigger 定义一个向下流动的管道触发器 12.8
variables 在 job 级别定义 job 变量
when 什么时候运行 job，也可用：when:manual and when:delayed.

前端发布系统迭代 - 图2

gitlab-ci与jenkins对比

1.分支可配置性

分支可配置性

  • 使用Gitlab-CI，新创建的分支无需任何一步配置即可立即使用CI管道中定义的作业

  • Jenkina 2基本gitlab的多分支流水线可以实现，相对配置来说gitlab更加方便

    2.定时执行构建

    定时执行构建
    有时，根据时间触发作业或整个管道会有所帮助。例如，非常规时间，夜间定时构建

  • 使用Jenkins 2可以立即使用，可以在应执行作业或管道中的那一刻以cron式语法定义

  • Gitlab CI没有此功能。但是可以通过一种变通办法实现：通过webAPI使用同一台或另一台服务器上的cronjob触发作业或管道实现

    3.拉取请求支持

    拉取请求支持
    如果很好地集成了存储库管理器和CI/CD平台，可以看到请求的当前构建状态，使用次功能，可以避免将代码合并到不起作用或无法正确构建的主分支中

  • Jenkins没有与源代码管理系统进一步集成，需要管理员自行写代码或插件实现

  • Gitlab与其CI平台紧密集成，可以方便查看每个打开或关闭拉取请求的运行和完成管道

    4.权限管理

    从存储库管理器的权限管理对于不想为每个服务分别设置每个用户的权限的大型开发人员或者组织团体很有用。大多数情况下，两种情况下的权限都是相同的，因此默认情况下应将他们配置在一个位置

  • 由于Gitlab与GitlabCI的深度整合，权限可以统一管理

  • 由于Jenkins 2没有内置的存储库管理器，因此它无法直接在存储库管理器和CI/CD平台之间合并权限

    5.存储库交互

  • Gitlab CI是Git存储库管理器Gitlab的固定组件，因此在CI/CD流程和存储库功能之间提供了良好的交互

  • Jenkins 2与存储库管理器都是松散耦合的，因此在选择版本控制系统时非常的灵活。此外，Jenkins 2强调了对插件的支持，以进一步扩展或改善软件的现有功能

    6.插件管理

  • 扩展Jenkins的本机功能是通过插件完成的。插件的维护，保护和升级成本很高

  • Gitlab是开放式的，任何人都可以直接向代码库贡献更改，一旦合并，他将自动测试并维护每个更改

    7.总结

    GitlabCI

  • 轻量级，不需要复杂的安装手段

  • 配置简单，与gitlab可直接适配
  • 实时构建日志十分清晰，UI交互体验很好
  • 使用YAML进行配置，任何人都可以很方便的使用
  • 没有统一的管理界面，无法统筹管理所有项目
  • 配置依赖与代码仓库，耦合度没有Jenkins低

  • 天然支持分布式，gitlab的runner可以装在任何一台电脑上，方便测试和集成

    Jenkins

  • 编译服务和代码仓库分离，耦合度低

  • 插件丰富，支持语言众多
  • 有统一的web管理界面
  • 插件以及自身安装较为复杂
  • 体量较大，不是很适合小型团队

GitLabCI有助于DevOps人员，例如敏捷开发中，开发和运维是同一个人，最便捷的开发方式。
JenkinsCI适合在多角色团队，职责分明、配置和代码分离、插件丰富
在使用过两者后，个人觉得gitlab-ci更简单易用，如果有gitlab-ci达不到的要求，可以考虑使用jenkins。

注意事项

  1. 需要保证cdn发布的静态资源是可以访问的，才能允许下载页面
  2. viewPath路径支持在yml中配置
  3. viewPath支持多页面片配置