基于Gitlab CI的上线时间校验

ephererid 发布于2019-05-23 14:34 / 1249人阅读

摘要：之所以这么要求，是因为减少在人员不齐情况下上线带来的风险。只有具备以上两点才能进行下一步。所以目前只能通过这种方式来做到上线控制。

前提

目前公司在很多项目在上线时，都明确要求了，周四、周五上线production环境需要发邮件申请，周六、周日不允许上线，周一至周三每天下午5点到晚上9点不允许上线。

之所以这么要求，是因为减少在人员不齐情况下上线带来的风险。

而这种规范，只能由公司各个项目组之间的自觉，但是这种自觉其实是一种不可靠因素。我个人感觉还是需要一套约束，来降低这种不可靠因素。

目标

前提确定好后，那就需要一个目标了。也就说，在某些分支上的某些时间点是不允许让CI进行自动构建的。

一开始，我的想法是通过git hook来实现，但是后来给否决了，原因为：

pre-commit 只是针对当前commit的时间点，并不是push的时间点

pre-push 虽说可以做到，但是问题在于，可以通过--no-verify来跳过钩子，而且这种跳过是下发到组内每个成员的。

对merge无能为力，网上的方案都是通过prepare-commit-msg来判断当前commit是否存在Merge字符串，不可靠

理想情况下，组员是没有任何权限去控制这一块的，也就是说无法被绕过，git hook的方式都是在组员本地，也存在了各种被绕过的风险。

那既然无法在本地校验来达到目标，那就只能把目标放在gitlab-ci这一块了。

正文

这里有个前提，一个小组内，只能有部分人具有CI的控制权。并且一定有code review。只有具备以上两点才能进行下一步。

通过在CI Variables来增加以下两个变量：

NOT_SUPPORT_HOUR 17,18,19,20,21
NOT_SUPPORT_WEEK 4,5,6,0

这个变量就应对上上面所说的只能有部分人具有CI控制权

然后在.gitlab-ci.yml里增加一个check_deploy stages，以及增加相关的pip

stages:
 - check_deploy
check_time:
  image: busybox
  stage: check_deploy
  script:
    - export TZ=UTC-8
    - export CURRENT_WEEK=$(date "+%w")
    - export CURRENT_HOUR=$(date "+%H")
    - if [ $(echo $NOT_SUPPORT_HOUR | grep "${CURRENT_HOUR}") ]; then exit 126; fi;
    - if [ $(echo $NOT_SUPPORT_WEEK | grep "${CURRENT_WEEK}") ]; then exit 126; fi;
  only:
    - master

通过启动一个busybox容器，来对当前时间以及不允许时间段进行一个比较，当当前时间点在不允许时间端内，则抛出错误码126。且只对上线分支有效（这里为master分支）

这个也对应上了，之前所说的一定有code review

其实这个方法也有缺陷，那就是是刚刚所说的两个前提，以及不应该把这种限制下发到小组单位，理想的情况下各个小组都是没有权限进行控制的，正在的控制权应该上升到更高一层，但是目前还想不到好的方式让更高一层介入进来。所以目前只能通过这种方式来做到上线控制。

作者信息：

Author: Black-Hole

Blog: bugs.cc/

github: github.com/BlackHole1/

Twitter: twitter.com/Free_BlackH…

Email: 158blackhole@gmail.com

其他

我司招人，感兴趣的小伙伴可以来投简历呀。

弹性工作制、每日水果、小伙伴都nice、965、五险一金...

文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。

转载请注明本文地址：https://www.ucloud.cn/yun/7029.html

GitLab CI/CD 在 Node.js 项目中的实践

摘要：近期在按照业务划分项目时，我们组被分了好多的项目过来，大量的是基于的，也是我们组持续在使用的语言。部署环境强依赖本地，因为需要在本地建立仓库的临时目录，并经过多次的方式完成部署上线的操作。近期在按照业务划分项目时，我们组被分了好多的项目过来，大量的是基于 Node.js 的，也是我们组持续在使用的语言。现有流程中的一些问题在维护多个项目的时候，会暴露出一些问题：如何有效的使用...

Profeel 2019-08-23 17:52 评论0 收藏0
几分钟看完 flow.ci 全部功能

摘要：正式内测月初，上线，正式进入开发者的视野。公测注册取消邀请码限制，用户可直接注册使用。支持持续部署相比持续集成，持续部署的工作流程更受关注。从 0 到 1，从邀请式内测到收费上线，flow.ci 经历了十个多月的沉淀与打磨。这期间，flow.ci 工程师们奋力赶工，进行了一系列的大功能更新，Bug 修复，功能优化。这篇文章记录了 flow.ci 内测期间的大功能更新和相关的实践教程...

yuanzhanghu 2019-06-28 15:38 评论0 收藏0
Docker 实践（九）：生产环境优化

摘要：系列文章第五篇中介绍了线上生产环境使用集群，这篇文章对原来的架构进行了优化，同时使用了最新的一些特性，记录一些流水账。配置文件鉴于上次搭建时配置文件管理混乱，这次做了统一规划为每个环境创建不同的配置文件，可以以环境名后缀。删除无用的容器。系列文章第五篇中介绍了线上生产环境使用 Docker 集群，这篇文章对原来的架构进行了优化，同时使用了 Docker 最新的一些特性，记录一些流水账...

AlienZHOU 2019-06-28 15:53 评论0 收藏0
如何设计npm包的开发和发布流程

摘要：所以此版本号在这里的作用并不是用来区分版本的，小版本号才是真正用来做版本区分的，那么在引用这个就要这么来控制版本号，举个栗子锁定大版本号和小版本号，不管我们开发过程中提交了多少次，我们引用都是最新的。最近在把公司内部用的一个库发布到内网的npm私服上，仅仅是发布的话是比较简单的，但这个库是由多个人一起维护的，而且npm私服只有一套，所以生产环境和开发环境，用的是同一个，那么，我们的需...

qieangel2013 2019-08-23 17:02 评论0 收藏0
容器环境下的持续集成最佳实践：构建基于 Drone + GitFlow + K8s 的云原生语义化

摘要：集成测试完成后，由运维同学从发起一个到分支，此时会会运行单元测试，构建镜像，并发布到预发布环境测试人员在预发布环境下再次验证功能，团队做上线前的其他准备工作运维同学合并，将为本次发布的代码及镜像自动打上版本号并书写，同时发布到生产环境。云原生 (Cloud Native) 是伴随的容器技术发展出现的的一个词，最早出自 Pivotal 公司（即开发了 Spring 的公司）的一本技术小...

asoren 2019-06-28 17:10 评论0 收藏0