ci脚本
1. 基于K8s的CI/CD系统
基于k8s搭建的一套CI/CD系统，其目的是方便k8s和服务端相关技术的实践，在搭建过程中会涉及docker、dockerhub、k8s、github、jenkins、kubesphere
一台Mac物理机+3台Centos虚拟机
Docker是这个教程的基石，对Docker一点都不了解的同学，建议去B站看一下我发布的 Docker小白快速入门+实战 ，课程比较简洁，主要帮助不了解Docker的同学快速掌握并应用
安装命令如下
k8s是一个容器编排工具，可以轻松实现应用的扩/缩容、集群等，具体安装方式参考文档我的 k8s集群安装
这是k8s的一个web管理界面，用于简化k8s的操作。
在k8s继续的所有节点上都需要安装nfs-utils、rpcbind，搭建步骤参考我的 Centos7搭建NFS服务端
kubesphere明确说明基于k8s安装需要配置DefaultStorageclass，创建步骤参考我的 k8s基于NFS创建Storageclass
安装时间会有一点长，安装步骤参考我的 k8s集群安装Kubersphere
jenkins在这里是作为一个纽带的作用，因为jenkins在构建项目时可以执行shell脚本，因此通过shell脚本轻松的将github、docker注册服务器、k8s集群三者关联起来，从而简化jenkins的使用（就是一个偏运维的工具而已）
这里之所以使用Docker安装Jenkins，是因为我不想在物理机上安装jenkins（毕竟只是一个工具），而虚拟机已经启动了三台，再创建就会影响我的物理机性能，所以这里直接使用物理机的Docker跑Jenkins，用完就删了。
安装步骤参考我的 基于Docker安装Jenkins
免密访问k8s集群的master服务器
参考我的 Linux配置免密登录 ，这里需要进入jenkins容器内部进行操作
配置github的ssh key访问
在jenkins创建一个自由风格的软件->填写仓库地址->编写如下脚本
一个简单的CI/CD系统就搭建完成了，后面可以把更多的重心放在k8s资源文件的编写上，理解yaml中各节点的含义也是一项不小的工作量，搞清楚k8s的各个模块，对服务端的架构设计是有益的。
2. Gitlab-CI自动化打包之Runner配置和CI脚本说明
在gitlab上新建一个打包工程目录，比如auto_build_game_apk( https://gitlab.com/CocosTool/auto_build_game_apk )，必须获取工程的master权限。
示例Cocos Hello World工程: https://gitlab.com/CocosTool/cocos_example
新建脚本文件.gitlab-ci.yml:
3. 自动化测试如何和ci系统集成
CI和自动化先天是分不开的
一般的CI系统都会支持JOB，job一般都可以调用命令行、shell、脚本等等。自动化测试脚本通过job运行起来，再把测试结果按照CI系统的要求吐回测试报告（一般如Junit测试报告），则整个过程就集成了。自动化测试的job一般会再版本构建完成，测试环境初始化完成这些job完成后自动触发或定时触发
4. CI/CD的实践
阿里云的 Docker 镜像源添加
docker服务基本的操作
得到密钥后填入，继续
然后再点击去安装推荐插件
docker 的架构是 C/S 架构。在我们使用 docker 命令时，其实是命令使用 socket 与 docker 的守护进程进行通信，我们需要将jenkins添加到docker的用户组,才能正常执行 docker 命令
NODE
服务器上生成
把公钥添加在到git, 私钥添加到jenkins源码管理
本地文件添加DockerFile和nginx配置
构建脚本
然后构建生成一个新的镜像
镜像库就是集中存放镜像的一个文件服务。镜像库在 CI/CD 中，又称 制品库 。构建后的产物称为制品，制品则要放到制品库做中转和版本管理。常用平台有Nexus，Jfrog，Harbor或其他对象存储平台
5. 如何一步步实现AndroidCI
一步步实现Android CI
Android上的CI构建链与其它平台一致，依然包含Compilation, Testing, Inspection,
Deploying阶段，每一个阶段的Feedback的都保持对整个团队透明。
2、添加Function Test
Android为大家提供了一套集成测试框架Android integration testing
framework。但此框架未集成Cucumber，这导致每增加一个Function Test都需要较大的开发和维护工作。这样高成本的实现Function
Test将大大延缓开发进度，最终因为项目进度的原因导致Function Test被丢弃。产生这样的后果那必然是不愿意看到的。
目前Android平台下已经出现多种Functiong Testing测试工具，如Native Driver, Robotium,
Calabash等。在尝试对比后，最终选择了Calabash Android作为解决方案。Calabash
Android是Cucumber在Android平台的实现，使用Ruby书写Function Test，并提供了一组操作Anadroid App元素的API。
3、添加UI Test
Android在新近退出了UI测试工具UIAutomator。此工具仅支持Android4.1及以上平台，鉴于目前市场上2.3和4.0版本仍占主导的情况来看，目前还无法满足大家的需要。另外应用该工具实现UI测试的开发成本还较高，笔者暂不推荐使用此工具，但应该关注其发展。
另外基于录制回放机制的测试方法同样可以进行UI测试。但录制回放的方法在面对功能快速迭代时，维护工作会急剧增加，而这个维护成本可以说是很难承受的，所以在此也不会将这种测试方法集成至CI中。
目前来看Android中UI测试还无令人满意的方法。若对UI成功比较看重，可以投入精力应用UIAutomator进行UI测试。
Best Practice:
*
将测试按照单元测试，组件测试，功能测试和系统测试进行划分。单元测试应该在每次提交时触发执行，其它的测试根据运行时间长短和重要程度可以每次提交触发执行或者定时周期执行。
* 将运行较快的测试优先执行。
* 让功能测试能够重复执行。否则维护成本太高，会被舍弃。若是后台数据导致不可重复，可以将数据抽象成为数据集，在每次运行前进行重置。
* 书写测试时每一个assert只做一种判断，这样可以明确每次测试的目的，并且可以快速定位测试失败愿意。
步骤 3：持续检查持续检查是对于代码本身检测和反馈。检测主要通过对代码静态分析验证代码风格，编程规范，代码复用，代码语言中的Best Practice等多个维度的代码质量。
Sonar作为一个开源的代码质量检测工具，涵盖了7项代码质量检测方式。这充分满足Android平台下对于代码质量的检测分析。Sonar分为两部分一部分是代码分析工具，另一部分是数据分析展示的Server。
Best Practice:
* 将测试覆盖率，代码分析结果透明化
* 持续降低代码复杂度
* 持续的促进设计的演进
* 持续的维护代码结构
* 持续减少代码重复
步骤 4：持续部署
由于Android App采用用户手动从Appstore自行下载安装的方式发布，使得Android
App无法直接部署至用户手机中。另外Appstore需要对于上线的App进行审核，不能持续进行Release。因而Android中持续部署将以持续发布可安装包为目标。
在以上目的下，只需根据自身项目资源找到合适的安装包管理工具即可。如本文采用Dropbox来管理所有安装包。
Dropbox作为一个云存储平台，在Android终端设备上可以轻松下载存放在其中的文件，同时上传安装包也可以交由Dropbox自己完成。
步骤 5：持续反馈
反馈是所有改进的开始，必须要让所有人获取到他们所关心的反馈信息，才能实施改进。持续反馈的目的就是让所有人都掌握项目健康状况。项目所有人事实都是有意愿知道项目当前的健康状况的，那CI就应该将项目的情况做到透明，并将不同的反馈通知到各相关的成员。
CI不同阶段产生了不同维度的反馈，如单元测试报告，测试覆盖率等。本实践中将这些反馈都透明的展示在项目首页中。之所以没有将这些反馈再以邮件的方式通知所有人，是因为团队成员已经养成了查看CI的习惯。
如果说只给所有人发一封邮件说明项目状况，那必然是告诉所有人“CI所有步骤是否都返回正确？”。这样一个反馈，包含了编译正确，所有测试通过，安装包已经准备完毕等重要信息。有必要让所有人都知道这个信息，特别是在CI执行失败的时候。Jenkins自身已经提供一个简单有效的透明化方法，以项目为蓝色表示通过，红色表示有步骤失败。
反馈的通知方式有很多种，不一定要采用邮件通知的方式。可以寻找更加有趣的方式，如果播放音乐和设置警报灯。在每一次Build成功或失败后都播放一段有趣的音乐，打开不同颜色的警报灯，这两种方法都是是一种简单有效的方式，可以让项目所有人都获取到最为关键的信息。
6. CI中的脚本怎么在Linux下定时运行
Linux中，周期执行的任务一般由cron这个守护进程来处理 ps -ef | grep cron cron读取一个或多个配置文件，这些配置文件中包含了命令行及其调用时间。 cron的配置文件称为“crontab”，是“cron table”的简写。