全部产品
研发协同 RDC

(待迁移)应用构建与发布

更新时间:2017-09-16 14:08:04   分享:   

创建个人开发分支

企业中的开发者,需要开发新需求时,可申请新分支开发,在RDC称之为“申请变更”(change request)。入口:应用-“新建变更”
申请变更

在变更新建的页面,输入本次开发的原因,可以选择使用代码库中已有分支或者创建新分支,如选择新分支,可以输入自定义的名称,系统根据输入的名称自动从应用关联的代码库中master创建新分支:
申请变更详情页

构建打包配置

RDC目前支持JavaNode,及其它脚本语言的构建。下面会讲解构建环境和构建行为,及如何进行定制化配置。

基础环境

操作系统

基于centos 5

自定义软件

您可以在构建环境中运行任意命令安装您需要的软件。但目前不支持安装rpm包。

自定义构建脚本

您需要在代码库中放置一个文件:<应用名>.release(如果在创建应用时,选择新建代码库,则RDC会帮您生成这个文件,并提交到代码库中)。该文件以键值对的形式描述构建行为。

您可以在release文件中通过build.command指定任意构建命令,比如build.command=sh build.sh,所以如果需要安装软件,或者执行复杂的命令,都可以通过这种方式实现。

环境变量

ENV_TYPE

RDC默认创建了三个环境:日常,预发,正式。在进行三个环境的构建时,ENV_TYPE的值分别为testingstagingproduction。因此可以使用这个环境变量区分不同环境的编译。

使用场景一:使用ENV_TYPE作为maven构建的profile。在release文件中配置build.command=mvn clean install -P$ENV_TYPE。并且在您的pom文件中设置testingstagingproduction这三种profile,在其中定义不同环境的不同行为。

使用场景二:设置build.command=sh build.sh,然后在build.sh中使用ENV_TYPE的值来进行判断,并执行不同的操作。

一个具体的例子:我想在不同环境中构建时,使用不同的数据库配置。假设程序运行时从application.properties中读取数据库配置,则可以在代码库中放置三个配置文件:application.properties.testingapplication.properties.stagingapplication.properties.production。然后在build.sh中包含这么一行,将属于相应环境的配置文件覆盖到程序读取的文件,也就是application.properteis

  1. cp application.properties.$ENV_TYPE application.properteis

注意:上面只是一个例子,具体的配置文件的路径以你的项目的实际情况为准。

APP_NAME

应用名。

其它的环境变量,可以从构建日志中查看。

各个语言构建行为

Java构建

使用Java构建,release文件需要按如下形式编写:

  1. # 必填,表示是Java构建
  2. code.language=java
  3. # 选填,取值可以是jdk-1.6,jdk-1.7,jdk-1.8,默认值为jdk-1.7
  4. baseline.jdk=jdk-1.7.0_51
  5. # 选填,取值可以是maven2.2.1,maven3.2.5,默认值为maven3.2.5
  6. build.tools.maven=maven2.2.1
  7. # 选填,取值可以是gradle-2.10,gradle-4.0,默认值为gradle-2.10
  8. build.tools.gradle=gradle-2.10

Java的默认构建命令为:mvn -U clean package -Dappname=$APP_NAME -P$ENV_TYPE,您可以通过build.command进行覆盖。

默认的maven settings会把所有的repository都镜像到maven.aliyun.com下载依赖,如果您需要不同的配置,只需要在代码根目录放置您的settings.xml,RDC会使用该文作为构建的settings.xml

如果需要使用私有maven仓库下载依赖或上传二方库,具体做法详见私有仓库配置

构建完成之后,需要通过配置告诉RDC您希望把什么文件作为构建的产物,详见打包配置

Node构建

使用Nodejs构建,release文件需要按如下形式编写:

  1. # 必填,表示是Node构建
  2. code.language=nodejs

Node构建通过engines的方式来获得特定的版本,具体方式是在package.json中添加如下片段:

  1. ...
  2. "engines": {
  3. "node": ">=5.1.0"
  4. },
  5. ...

则RDC会根据使用您指定的版本。该机制背后使用的是nvm,所以只要是nvm支持的版本,都可以填写。

Node的默认构建命令为:npm --python=/usr/alibaba/install/python-3.5.0/bin/python3 --registry=https://registry.npm.taobao.org install --production。其中的--python部分是为了进行包含本地扩展的node模块的编译,详见:https://github.com/nodejs/node-gyp

您可以通过build.command进行覆盖。

构建完成之后,需要通过配置告诉RDC您希望把什么文件作为构建的产物,详见打包配置

scripts构建

使用scripts构建,release文件需要按如下形式编写:

  1. # 必填,表示是scripts构建
  2. code.language=scripts

构建完成之后,需要通过配置告诉RDC您希望把什么文件作为构建的产物,详见打包配置

RDC把不需要进行编译的语言,比如php,python等,都归为此类。这类语言,不做任何构建,只进行打包。

不同环境使用不同的构建配置

RDC支持在不同的环境中使用不同的构建配置。

一个可能的场景是,日常环境使用阿里云容器服务,所以需要进行Docker镜像构建,但在生产环境希望使用ECS部署,不需要进行镜像构建。

对于这个场景,可以使用下面的写法。

  1. code.language=java
  2. baseline.jdk=jdk-1.7.0_51
  3. build.tools.maven=maven2.2.1
  4. # 使用`ENV_TYPE`的前缀(testing, staging, production)的键值,只会在相应环境的构建中生效
  5. testing.docker.file=Dockerfile
  6. testing.docker.repo=registry.cn-hangzhou.aliyuncs.com/mynamespace/container-app
  7. testing.docker.tag=${TIMESTAMP}

ENV_TYPEtesting时候,RDC会寻找所有不带前缀的键值,并与带testing前缀的键值,进行合并。带前缀的键值拥有更高的优先级。也就是说下面的例子中,docker.file最终的值是Dockerfile_test

  1. docker.file=Dockerfile
  2. testing.docker.file=Dockerfile_test

一般来讲,修改构建配置,也需要相应的修改部署配置

打包

release文件中指定build.output,内容可以是一个文件或者文件夹的相对路径。比如target/myproject.jartarget/myproject.war等。RDC会将指定的文件打成压缩包,保存下来。

对于scriptsnodejs来说,如果不给出build.output,则会打包整个目录。

目前不提供压缩包的下载,该压缩包会在进行部署时候,直接传到指定机器上。详见部署配置

私密配置项

在应用构建中,通常会需要一些配置项,如:

  1. 功能开关
  2. 依赖系统的URL
  3. 数据库链接用户名密码

对于前两项,RDC没有提供额外的支持,推荐您直接在代码中保存不同的配置文件,然后在构建时根据ENV_TYPE的环境变量,选取正确的配置文件。

第三项中的配置项会涉及一些私密信息,不适合放在代码库中。RDC提供了私密配置项的保存功能。您可以在应用的私密配置项页面(https://rdc.aliyun.com/ec/app/xxx/securityConfig) 添加和配置应用级别的私密配置项,比如:

normal

如果您需要在多个环境都使用私密配置项,则可以使用如下的方式:

multi-env

配置好这些私密配置项之后,在进行构建时,RDC会把这些配置项转换成为一个明文的文件,并将其放置在根目录下的rdc_security_config.properties中,比如:

rdc_security_config.properties:

  1. db_password=somepasswd

您可以在自己的构建脚本中读取该文件,并按照您自己的方式进行使用。

开发完成,开始发布

在我的变更详情页面,点击“提交待发布”按钮,则进入了该应用的“发布”页面,
发布页面

发布页面,默认提供了3个发布区“日常环境部署”-“预发环境部署”-“正式环境部署”;(正式环境指线上环境)。

提示:

  • 日常环境:各个需求分支集成发布环境,主要用于集成后的功能验证,和回归测试。
  • 预发环境:类线上环境,用于发布线上前的回归测试、性能测试等;通常使用线上的数据库,在真实环境中验证;
  • 正式环境:线上环境,经过一系列验证通过后,正式提供给外部用户使用的环境;

首先进行日常环境部署(如没有,可以直接进入预发环境部署),勾选需要发布的变更分支,点击“提交发布”,则自动进入发布区,开始以下过程:

  1. 自动代码分支合并:系统从主干代码自动创建release分支,自动将变更分支mergerelease分支。如出现冲突,将提示冲突解决路径;
  2. 编译release分支代码;不同语言默认编译脚本,如需修改构建脚本,请到app.release文件中配置;
  3. 开始部署环境,根据应用测试环境“版本内容”中的版本配置,执行部署命令;[部署配置](https://help.aliyun.com/document_detail/52085.html "部署配置")
  4. 人工验证

不同环境不同的部署方式

RDC提供了三种部署方式:

  1. 自定义脚本部署(也就是本文描述的部署方式)
  2. EDAS部署
  3. 容器部署

与前面提到的不同环境使用不同的构建配置类似的,RDC也支持不同环境进行不同的部署配置。您可以在部署配置的页面进行修改。

请注意,如果您修改了部署方式,请参看上面列出来的相应文档,保证您的release文件和部署方式是匹配的。

切换部署方式

预发发布

日常部署并验证完成后,点击“进入预发部署”将当前变更的内容提交到预发环境发布。过程同日常部署。

如曾经解决过冲突代码,会自动将解决过的内容带入预发部署区,无需重新解决。

注意:如在预发部署页面,直接勾选对应变更进入预发部署环境,开始部署。也可以直接运行预发部署,但是不会将日常部署曾经解决过的冲突代码带入预发。

正式上线

预发部署并验证完成后,点击“进入正式部署”将当前变更的内容提交到正式环境发布。过程同日常部署。

“进入预发部署”和“进入正式部署”的配置说明

注意:如没有“进入预发部署”、“进入正式部署”按钮,可在应用-流程配置 页面。中配置按钮;进入预发部署按钮配置

tryitnow
本文导读目录
本文导读目录
以上内容是否对您有帮助?