云上持续交付实践系列1 --- java 篇

本文会演示如何在CRP上编译并部署一个Java Web应用。

我的应用

技术栈

我的应用是一个简单的在线购书的网站。因为是示例,所以代码就只有简单的一个登陆界面和登陆以后的书目列表界面。代码库在https://code.aliyun.com/blade_1986/bookstore。 使用的技术栈如下:

  1. Gradle作为构建工具
  2. Spring作为IOC容器及MVC框架
  3. JUnit作为测试框架
  4. Spring Test作为集成测试框架
  5. Selenium作为功能测试工具

有兴趣的同学可以先把这个代码下载下来按照README.md现在本地跑起来。

部署环境

我有两台ECS的机器,都有公网IP,并且开放了22端口。我选择其中的一台做我的预发环境,另一台做我的正式环境,它们是:

  • 预发环境:120.xx.xx.103
  • 正式环境:120.xx.xx.137

在CRP上编译该项目的预备工作

使用gradle wrapper及CRP下载源

该项目使用的是gradle的官方推荐用法:gradle wrapper。使用这种方式,第一次运行./gradlew命令时,会下载相应版本的gradle发行版本下来,然后执行接下来的命令。直接从gradle官方下载gradle发行版本会比较慢,所以我按照这篇文章的引导修改了下载源,运行起./gradlew来速度杠杠的。

使用maven.aliyun.com

直接使用maven的库速度会有些慢,所以可以将依赖库的地址配置到我们的maven.aliyun.com来加速编译。该库代理了maven的官方库。但如果某个你访问的库在maven.aliyun.com中不存在的话,则第一次编译可能会超时失败,但第二次就可以成功了。修改方式是在build.gradle中添加如下配置:

repositories {
    maven{ url 'http://maven.aliyun.com/nexus/content/groups/public'}
}

开始进行配置

在CRP中创建了项目之后,可以选择新建工作流,默认会提示从模板创建,我选择了“JAVA工程标准模板”,输入项目名称“bookstore”,然后点击确认,就会看到这样的页面:

关联代码库并配置触发器

看到上面大大的“点我配置触发器”,于是就点了一下,然后尝试去选择代码仓库和侦听分支,发现什么都没有。那是因为没有将该代码库与该项目进行关联。需要点击侧边栏的“代码管理”,然后在关联代码库的输入框内输入“bookstore”,然后CRP就可以自动提输出该代码库的全名,然后点击添加就可以把该代码库关联到这个项目了。然后再回到工作流配置界面,点击触发器按钮,去配置代码库及侦听分支。如果你想尝试这个步骤,需要先把上述的代码库fork一份出来到你的code.aliyun.com的账户下,因为非代码库成员的CRP账户无法关联该代码库。

完成代码库配置后我们来看看这个模板都包含了什么。

持续集成的配置

第一个阶段叫做代码检出-单元测试,其中自动加入了两个任务,我们只需要关注"编译/测试"这个任务即可。这个任务的目标是对代码进行验证,并打一个war包出来,以供后续的部署之用。该任务的默认配置如下图所示:

可以看到默认命令使用的是maven。而我使用的是gradle,所以需要做相应变化。我会使用下面的命令来运行单元测试和集成测试:

./gradlew test integrationTest
./gradlew war

运行完之后生成的war包会在build/libs/bookstore.war。所以修改完的配置如下所示:

到此为止我们就配置好了测试,点击右上角的生效后,再点击右上角的触发,工作流就开始运行了。点击控制台输出可以看到任务运行的日志。

发布的配置

预发环境

接下来我想要把代码部署到预发环境了,但是模板只给了我一个“正式部署”。没关系,这只是个名字而已,点击这个活动把名字改了就好:

上面是默认配置,下面解释一下每个配置的含义:

  • 目标机器就应该是我预发机器的IP:120.xx.xx.103
  • 部署路径:CRP会把我生成的bookstore.war这个文件再压缩成为一个package.tgz文件。当部署任务运行时,CRP会把这个package.tgz拷贝到我指定的“部署路径”中。我直接将其指定到了/root下。
  • 部署命令:这个就是当拷贝完成之后用来部署的脚本。那我的脚本要做什么呢?很简单,停止tomcat,把war包拷贝到tomcat的webapps目录下,然后再启动tomcat,that's it!

所以最后我的配置是这样的:

CRP会默认在登录用户的home目录下执行这些命令。由于我用root账户登录,而该用户的home目录就是/root,所以可以直接开始执行解压的命令。如果你拷贝的位置不是登录用户的home目录,则需要先cd过去。

哦对了,CRP如何才能访问你的机器?需要点击配置框右下角的“机器授权”来完成这件事情。

正式环境

配置好了预发环境,接下来要配置正式环境了。聪明的你可能已经想到了,配置方面除了“目标机器”的IP不同之外,其它的所有配置都跟预发环境是一模一样的(不要忘记再次配置机器授权!)。

一些细节的配置

我希望自动化测试和打包这件事情在每次提交代码之后自动发生,但是我希望经过手工批准才能进行两个配置任务。所以三个活动中,第一个活动是自动触发的,后面两个都需要手动批准。这个配置是通过活动信息的“自动触发”和“自动完成”两个选项生效的:

单元测试活动两个都勾选了;两个部署活动只勾选了自动完成。

当然我还希望单元测试出错时候能够通过邮件提示我,所以我还选中上图中的“异常通知”来。而部署的操作肯定是在页面上进行的,所以如果出错立马就能看到,所以这个就不需要配置邮件通知了。

运行完第一个活动后:

点击三角符号才会触发预发环境的部署。运行结束后你会看到:

再次点击那个按钮之后就可以触发生产环境的配置。运行结束后你会看到:

配置精简

作为一个视重复为万恶之源的程序员,我发现了“预发部署”的配置和“产品部署”的配置在“部署命令”这个输入框中的内容是一模一样的!所以我需要像个办法来精简一下。做法很简单,那就是把这些命令放到deploy.sh这个部署脚本中,然后把bookstore.wardeploy.sh这两个文件达成一个压缩包,名为bookstore.zip。然后CRP会把bookstore.zip再打成package.tgz。所以我们的CRP中的配置脚本就可以简化为:

  1. 解压package.tgz
  2. 解压bookstore.zip
  3. 运行deploy.sh来进行部署

为了做到这一点,首先第一个活动的配置需要改为:

然后两个部署的配置均可改为:

tar -xvf package.tgz
rm -rf bookstore
unzip bookstore.zip -d bookstore
cd bookstore
sh deploy.sh

当然现在看起来还是有些不可避免的冗余,CRP后续会再对此再作一些优化。

更多

在上述的例子中,你已经学会了如何把对你的应用做持续集成,并把它部署到预发和产品环境。但这并不是全部。你可能还会关心下面的几个话题。

多机部署

这个例子在一个环境中只部署了一台机器,显然这无法满足无感知发布的需求。后续我会写一篇结合阿里云SLB进行无感知发布的文章。

数据库

简单起见,本示例没有连接数据库。如果需要在测试中使用数据库的话,需要自行安装数据库,具体的安装方法请参看这里。

功能测试

如你所见,示例项目中其实有使用selenium编写的功能测试,但并没有配置到CRP的工作流中。我会在后续的文章中详细描述这部分内容。

时间: 2024-09-18 00:29:17

云上持续交付实践系列1 --- java 篇的相关文章

云上持续交付实践系列5 --- Ruby 篇

本文会演示如何在CRP上编译并部署一个Ruby应用. 相关技术栈和用到的网站 本文将以ruby-china为例,使用CRP平台实现该项目的编译.测试和最终部署. 1. Rails作为Web框架 2. Postgres作为数据库存储 3. Memcached作为分布式内存对象缓存系统 4. Redis作为Key-Value数据库 5. Elasticsearch则作为一个简单的搜索引擎 本次实践中为了更好地使用代码库服务,我们将ruby-china的代码迁移到了阿里云Code中,在Gemfile里

云上持续交付实践系列3 --- Python 篇

云上持续交付实践系列3 --- Python 篇 阿里云持续交付平台CRP(Continuous Release Platform)作为一款开发人员手里的居家旅行,杀人越货的利器,必然有其广泛的应用场景.本文将会演示如何在如何使用阿里云持续交付平台部署一个Python应用.Python作为一种脚本语言,经常与多种语言一起配合完成某些复杂的功能,与此同时,其强大的第三方库又进一步拓展了Python的应用领域. 应用概述 本文涉及两个项目,分别为基于Python的在线爬虫以及基于node.js的we

云上持续交付实践系列4 --- node 篇

本文会演示如何在CRP上编译并部署一个Node应用. 相关的技术和网站 阿里云持续交付平台 https://crp.aliyun.com 阿里云Code https://code.aliyun.com crp提供的编译能力 现在crp平台已经支持node0.12,node4.4.x, node5.9.x 版本的项目编译/测试 常用的node编译指令和环境 1.常用的node相关的指令 npm install //安装依赖 npm list //列举已经安装的依赖 npm test //执行测试

云上持续交付实践系列2--- go篇

go 作为一门google 开发的语言最近是越来越火了,其具备清晰.并行.安全等优点.当下非常流行的docker就是用go 语言的编写的.阿里云持续交付平台最近推出了多语言编译的支持,其中就包括go.本文就拿github 上开源的纯go 语言项目gogits/gogs 来小尝牛刀. 项目介绍 gogs 是github 上开源的用go 编写的轻量级的git 服务器.相比于现有开源的gitlab, 它更加的灵活.轻量.跨平台,很适合小型的开发团队.项目主页的地址:https://gogs.io/ 准

打造云上代码交付链,CodePipeline实践分享

在2017在线技术峰会--首届阿里巴巴研发效能嘉年华上,来自阿里云飞天研发部的工程师莫源分享了<打造云上代码交付链,CodePipeline实践分享>.他在云计算和云平台.持续集成流程.DevOps的基础上,详细分享了Alibaba Cloud CodePipeline优于Jenkins的性能和实践. 以下内容根据直播视频整理而成. 直播视频:https://yq.aliyun.com/edu/lesson/549 PDF下载:https://yq.aliyun.com/attachment/

云效平台:企业级互联网架构下的持续集成与持续交付实践

摘要:本文的整理自2017云栖大会-南京峰会上阿里云高级技术专家鲁小川的分享讲义,讲义主要分享了阿里云云效平台对于企业级互联网架构下的持续集成与持续交付的实践经验,首先介绍了阿里云云效平台的起源,之后对于企业并发研发项目交付流程存在痛点进行了介绍,并介绍了云效平台针对业务痛点所能够提供的服务和能力,并且结合实际案例分享了云效平台持续集成和持续交付实践. 在2017云栖大会-南京峰会上,阿里云高级技术专家鲁小川做了题为<企业级互联网架构下CI/CD实践>的精彩分享.所谓CI/CD也就是持续集成与

服务化架构下企业的业务持续交付——云效平台持续交付实践

摘要:本文的整理自2017云栖大会-南京峰会上阿里云资深开发工程师苗欣的分享讲义,讲义主要分享了阿里巴巴的持续交付之路,云效平台所提供一整套的持续部署.持续交付和持续验证的解决方案,以及实际效果,并且与大家分享了业务持续交付的相关客户案例. 在2017云栖大会-南京峰会上,阿里云资深开发工程师苗欣做了题为<服务化架构下企业的业务持续交付--云效平台持续交付实践>的分享.对于企业的业务而言,由于业务非常复杂,所以即便是小业务改动需要大应用发布,无法实现轻快交付.而即便是将应用进行服务化之后,也会

云端基于Docker的微服务与持续交付实践

云端基于Docker的微服务与持续交付实践笔记,是基于易立老师在阿里巴巴首届在线技术峰会上<云端基于Docker的微服务与持续交付实践>总结而出的. 本次主要讲了什么? Docker Swarm Docker Swarm mode 微服务支持(Docker集群架构体系) Docker的发展趋势和前沿成果 在Docker技术方面还是很佩服大牛的,所以赶紧写下笔记,追随大神的脚步. 阿里云资深专家易立,技术就不说了,他比其他直播间硬生生多讲了半个多点,于情于理还是万分感谢本次分享的(可惜devOp

产品迭代发布如何更快速?阿里持续集成与持续交付实践之路全解析

2017年5月9日,云效平台资深研发工程师向禹通过直播分享了<持续集成与持续交付实践之路>.他从云效背景.云效方案.云效价值三个方面进行了分享.他主要分享了持续集成持续交付的解决方案和案例,并且对大型系统如何实现持续集成.持续交付.进行产品迭代发布进行了详细介绍. 以下内容根据直播视频整理而成. 云效背景--阿里巴巴<持续交付>之路 大应用下的交付 在七八年之前,阿里巴巴的B2B一直沿用瀑布的模式来进行项目管理,当时已经感觉到瀑布模式对应用持续快速的发展产生了很大的影响.并且当时很