云开发系列课程 | 云开发平台的CI/CD能力

云开发平台系列课程之前一直是围绕网页端来进行分享的，也就是基于云开发平台的控制台。今天的内容是介绍如何通过云开发平台新开放的 Open API来实现一些更定制化、更丰富的CI/CD的功能。

之所以会开放Open API来实现这些功能，是因为有些团队在本地已经做好了工具，希望能够使用云开发平台的部署测试或是创建应用等模块化的能力，增强他们已经有的CI/CD能力。

大家在云开发平台帮助页面可以找到《与本地CI/CD hook集成》，会有详细的关于CI/CD的介绍。

阿里云Serverless云开发平台不仅支持在线CloudIDE开发、测试和CI/CD，同时也支持本地开发。在本地环境下，阿里云Serverless云开发平台在不影响原有开发流程的前提下，提供hook文件支撑项目本地CI/CD，可以让原有项目轻松升级到云原生Serverless架构。

Hook文件需要集成在代码托管平台的触发器逻辑中。以Gitlab举例，Gitlab提供两种钩子：WEB Hook和Custom Hook，Web Hook触发时调用提供HTTP/HTTPS接口，而Custom Hook则调用相关脚本，最终这两种Hooks都会调用或实现相关的CI/CD逻辑，实现项目自动化部署。

Hook是在对远端仓库做铺代码等基础操作的时候，Gitlab会对这些操作做一些捕获或拦截，然后通过这些捕获或拦截的动作，实现操作上的强化。

CI/CD流程是围绕WEB Hook的机制来实现的。CI/CD依赖4个环境变量： CI_WORKBENCH_ID（云开发平台创建的工程ID），CI_ACCESS_KEY（阿里云账号的Access key）、CI_ACCESS_SECRETE（阿里云账号对应的Accesskey Secrete）、CI_GITFLOW_PATH（可选，指定gitflow文件路径）。

如何构建环境大家可以参考帮助文档的介绍，这里不做赘述。

（演示）我们登录一个虚拟机并用Docker的方式建设一个Gitlab的私人服务器。这就相当于一个团队几个队员想一起在某个代码仓库或多个代码仓库，实现协作工作，但是又不想把代码放到公有云上。这个Gitlab私人服务器就相当于在模拟使用云开发平台前已有的本地开发环境。

在Gitlab里创建的服务器跑起来之后，可以创建自己的工程，在这里我们创建一个CI/CD的工程来做演示。

如果想配置CI/CD，第一步就是要在Gitlab里开启这个工程对于CI/CD的支持，也就是让Gitlab在push代码仓库的时候，Gitlab会自动触发CI/CD的流程。

点开页面左侧最下面的设置键，会看到Variables，这是CI/CD过程中会用到的变量，也就是跟这个仓库本身有关的变量。

比如本地已经有个建好的仓库，若想把它部署到云开发平台上，那么需要在两者之间建立连接，而连接的方式就是通过云开发平台上的应用ID，让仓库对应到云开发平台上已经创建的应用上。那么当围绕所有的本地已有的工程做一些部署，例如设置环境变量或设置团队成员等操作，云开发平台就都会知道。

第一步，设置ID。在帮助文档中可以看到介绍，CI_WORKBENCH_ID是云开发平台创建的工程ID，与每个gitlab仓库相对应，因此需要针对CI_WORKBENCH_ID做单独的配置。通过设置键到Variables中进行设置。

第二步，配置自己的AccessKey ID和AccessKey Screte。阿里云提供了一套AccessKey ID和AccessKey Secret的认证机制，每个同学都可以在自己的阿里云首页右上角找到AccessKey管理，点开管理就可以配置自己的AccessKey ID和AccessKey Secret，AccessKey ID和AccessKey Secret是你访问阿里云所有公共开放API的密钥，只要有AccessKey ID和AccessKey Secret，就等价于有了用户名和密码，可以任意使用账号的云资源。因为本地仓库与阿里云的账户没有联系，不方便使用用户名和密码来让webhook使用阿里云的云资源进行部署，所以可以让webhook通过ID和Secret的这种方式调用阿里云的开放接口。

如果已经获取了AccessKey ID和AccessKey Secret，那么Gitlab就能知道它该用何种方式套用云平台的开放接口，实现加强CI/CD的能力的需求。如何配置，可以参考帮助文档中的说明。

配置好之后，脚本就会自动识别到AccessKey ID和AccessKey Secret，从而可以帮我们去用一些云开发平台提供的OpenAPI然后来加强本地Hook的能力。

操作演示

前提是需要有一个Gitlab私服，或者有自己本地的其它CI/CD工具。有了这个前提就可以接着往下操作了。

第一步，解压缩一个Hook。Hook可以用Java来写，也可以用js来写，它只是一个暴露的服务，通过一个预定义的端口来提供服务。然后在服务里想让它做什么都可以，比如想在脚本里执行一些记录日志、安全审核、发送警告等操作，都是可以的。我们就可以把执行开发部署指令写到Hook中。在帮助文档中有提供一个已经写好的JavaScript Hook。

（演示）我们将Gitlab里面的Hook端口设置为8080。写好之后往下拉，有个叫Trigger的触发器，勾选这个触发器下面的选项，那么就可以用选项对应的方式执行上面写的脚本的操作。比如选择push event。让仓库在发生push时自动调用Hook来引起CI/CD流程。

（演示）给大家看我已经写好的一个脚本，这个是用Node.js写的。它的核心逻辑是对3002端口提供了监听，而监听里面只需要填一个路径，就是Hook脚本暴露出来的路径。每次调CI的时候，它都会执行如下图表述的逻辑，一共两步：第一步去Gitlab仓库拉取代码（这步可有可无，你也可以自己添加一些其它业务逻辑），第二步调CI/CD流程。

从这个逻辑里可以看出，第二步调CI/CD流程时执行了workbench.cicd.js这个脚本。这个脚本会完成从云开发平台控制台里面点击部署，然后从部署到打包代码，再把代码部署到云开发平台的一系列流程。

在帮助文档中，我们可以看到上面演示的关于CI/CD集成的步骤，第一步下载CI/CD hook，它有两个文件：第一个是workbench.js脚本，第二个是package.json一个依赖。

 测试演示

首先在本地把js. sever脚本跑起来。这就是一个小型的服务器，它为本地开启这样一个端口，使得Web Hook执行push操作的时候可以通过这个端口调用服务。

然后点击push event，发起一次发布。那么可以看到脚本已经开始执行CI/CD的工作了，可以看到他自动执行，跟从控制台里去点部署后的操作是一样的。

当这个域名它绑到API网关的二级域名，就说明部署成功了。

最后简单介绍下CI/CD的一些除了帮助完成“部署”操作之外的其它能力，通过帮助文档中的介绍可以获得更详细的信息。CI/CD提供的大多是一些比较基础的功能，比如GetAppInfo，它可以让你在Hook脚本中随时获取到当前在云端正在部署应用的一些信息，比如应用名称、域名、来自哪个解决方案或产品等等信息；DeployApp，这是一个部署应用的操作，当你把它加到WebHook流程里后，再触发 CI/CD时，就也可以触发云开发平台的部署，也就是说push后，如果想把代码再部署上去，就可以在DeployApp接口中完成这个应用的部署操作。更多的功能大家可以去帮助文档看详细的介绍。