使用 TeamCity 实现持续集成(CI)

原文同步至 https://waylau.com/continuous-integration-with-teamcity/

持续集成(Continuous Integration),也就是我们经常说的 CI,是现代软件开发技术的基础。本文论述了如何使用 TeamCity 持续集成工具来实现项目的持续集成。

为我们什么需要 CI

目前,CI 已在当前业界被许多软件开发团队所采用,是一种在整个软件开发生命周期内保证代码质量的常见做法。它是一种开发实践,旨在帮助开发团队应对软件开发过程中的如下挑战:

  • 自动检查 :当软件开发团队在周期性的新增或修改后的代码后,CI 服务器能持续地获取新增或修改后签入的源代码,并可以对这些变更的代码进行质量或者编码规范的检查。常用的工具有 PMD、SonarQube、CheckStyle、FindBugs等。
  • 自动构建 :CI 系统会依照预先制定的配置计划,或某一特定事件,自动检出代码,并对目标软件进行构建。这里的计划,可以是周期性的时间点,比如10分钟或者1小时构建一次,也可以根据特定事件来触发构建,比如用户主动发出构建命令,或者根据代码的变更来触发构建。构建工具可以选择 Maven 或者 Ant 等。
  • 自动测试 :构建检查完成后,可以执行预先制定的一套测试规则,也可以在执行构建的过程中进行测试用例的测试,前提是项目团队采用了测试驱动开发(Test-Driven Development,TDD)。常用的测试工具,有 JUnit、JWebUnit、Selenium 等。
  • 自动部署 :当自动化检查和测试成功完成,将打包软件、构件部署到一个运行环境或者软件仓库。这样,构件才能更迅速地提供给用户使用。
  • 及时提醒:当上面定义的任何一个阶段进行过程中发现出错或者预设事件得到触发,都能够及时通知给相应的项目干系人来进行处理。比如,在构建过程发生了错误,CI 服务器可以邮件通知开发人员来进行修复;自动化部署完成了,CI 服务器通知会测试人员可以进行测试了,等待。除了邮件,提醒的方式可以是短信、桌面通知器,也可以是音响大喇叭。

简言之,CI 是在敏捷开发过程中,实现速度、效率、质量的软件开发实践,可以持续为用户交付可用的软件产品。更多详情可以参考《为什么我们迫切需要持续集成(Continuous Integration)》

TeamCity 简介

正如 TeamCity 官网的自我介绍的那样,TeamCity 是一款强大的开箱机用 CI 工具(“Powerful Continuous Integration out of the box”)。其特性包括:

  • Technology Awareness
  • Key Integrations
  • Cloud Integrations
  • Continuous Integration
  • Configuration
  • Build History
  • Build Infrastructure
  • Code Quality Tracking
  • VCS Interoperability
  • Extensibility and Customization
  • System Maintenance
  • User Management
  • Pre-Tested Commit

TeamCity 分免费专业版授权(Professional Server License)和收费企业版授权(Enterprise Server License)。两者在功能上完全一致,只是在使用的数量上会有限制,其中,免费版授权包含20 个 build configuration 以及 3 个 build agent。可以单独购买构建代理授权( Build Agent License),含1个 build agent以及10个build configuration,费用是 299美元。企业版授权在build configuration 上是无限的,可以购买3 到 100 不等的 build agent,费用大概在1999至21999美元之间。

对于试用用户或者小团队而言,Professional Server License 足够了。

使用 TeamCity 实现 CI

下面介绍下 TeamCity 的常见用法。本例使用版本为 TeamCity Professional 10.0.4。

创建项目,关联源码

在创建一个项目(Project)后,可以将项目与相应的源码进行关联。源码管理工具支持 Git、CVS、Subversion 等。本例使用的项目是 necc_country,使用的源码管理工具为 Subversion。

在 VCS Roots 下,添加一个源码关联的地址: svn://10.30.22.18:32881/unengli/biz/gov/necc/branches/country

创建构建配置

构建配置(Build Configurations),是指项目构建过程中,一些列的步骤计划。比如,可以是代码质量检查、Maven 构建、发布等等步骤。

我们选择点击“Edit”按钮,在“Build Steps”中来设置一些构建计划。

1. 代码质量检查

使用 SonarQube 来进行代码质量检查。

其中,

  • SonarQube Runner Parameters:是 SonarQube 的一些配置参数,包括 SonarQube 服务器的IP等。
  • Sources location:项目源码的位置。
  • Modules:需要检查的模块。

2. Maven 构建项目

使用 Maven 来项目的构建。可以自定义 Maven 的 Goals,比如:

clean install -Dmaven.test.skip=true

或者

clean package

等。如果是采用 TDD 的开发方式,建议不要使用-Dmaven.test.skip=true来过滤掉测试步骤。

3. 部署项目

可以使用 FTP Upload 或者 SSH Upload 等方式将发布包发布到部署环境中。在本例,由于 CI 和部署的环境是在同一台主机上,使用 FTP Upload 即可。

其中,

  • Deployment Credentials:部署主机的用户名和密码。
  • Target host:是目标部署环境的位置,这里的位置是指 用户的相对路径位置,比如设置位置为10.30.22.18:/necc_simulation/gov-tomcat-necc/webapps/gov,使用的用户为dev,那么,最终部署到主机的绝对路径为/home/dev/necc_simulation/gov-tomcat-necc/webapps/gov
  • Paths to sources:待部署发布包的位置,这里 %teamcity.build.workingDir%/web/gov/target/gov中的 %teamcity.build.workingDir%是 TeamCity 构建的工作区间。

4. 重启 Web 容器

在本例中,我们将项目部署到了 Tomcat 容器中,部署完之后,需要重启 Tomcat。这里,我们使用 SSH Exec 来执行一段重启服 Tomcat 的脚本。

其中,

  • Deployment Target:Tomcat 容器所在的主机。
  • Deployment Credentials:部署主机的用户名和密码。
  • SSH Commands:在主机上执行的脚本。
# 切换到 Tomcat 安装目录的 bin 目录下
cd /home/dev/necc_simulation/gov-tomcat-necc/bin
# 是打印当前的工作目录
pwd
# 杀掉使用特定端口的 Tomcat 进程,即关闭当前程序
/sbin/fuser -k -n tcp 6060
# 给脚本赋予可以执行的权限
chmod 775 startup.sh
# 删除旧的日志
rm -rf ../logs/*
# 查看 Java 版本
java -version
# 启动
./startup.sh

触发构建

可以采用自动触发,或者手动触发来执行构建。

点击右上角的“Run”即可手动触发来执行构建。

在将项目与相应的源码进行关联后,默认会生成一个“VCS Trigger”,即,只要有变更提交到代码管理服务器上,就会自动触发构建。当然,也可以自行添加多种触发器。

报告

可以查看整个构建过程的情况,包括构建花费的时间等。

[11:50:33]Finalize build settings
[11:50:38]The build is removed from the queue to be prepared for the start
[11:50:38]Collecting changes in 1 VCS root
[11:50:38]Starting the build on the agent Default Agent
[11:50:38]Clearing temporary directory: /home/unengli/TeamCity/buildAgent/temp/buildTmp
[11:50:38]Publishing internal artifacts
[11:50:38]Using vcs information from agent file: a774be4779f9ea86.xml
[11:50:38]Clean build enabled: removing old files from /home/unengli/TeamCity/buildAgent/work/a774be4779f9ea86
[11:50:38]Checkout directory: /home/unengli/TeamCity/buildAgent/work/a774be4779f9ea86
[11:50:38]Updating sources: server side checkout (3m:08s)
[11:53:47]Step 1/5: maven build (Maven) (3m:33s)
[11:57:21]Step 2/5: deploy gov、ent to 18 test server (SSH Upload)
[11:57:21]Step 3/5: deploy ent to 40 (SSH Upload)
[11:57:21]Step 4/5: deploy to tomcat 7 gov (FTP Upload) (39s)
[11:58:00]Step 5/5: restart tomcat (SSH Exec)
[11:58:00]Publishing internal artifacts
[11:58:01]Build finished

参考资料

时间: 2024-11-10 08:30:46

使用 TeamCity 实现持续集成(CI)的相关文章

基于Docker容器的,Jenkins、GitLab构建持续集成CI

** 开发者将代码提交(push)到GitLab后,GitLab通过Hook通知jenkins,jenkins自动从GitLab中获取项目最新的源码进行集成和发布. 基于Docker,创建一个私有GitLab的容器,创建一个jenkins的容器** 1. 构建私有的GitLab容器 https://about.gitlab.com/installation/#centos-7,直接安装gitlab,不借助docker 通过docker-compose的方式安装gitlab,docker-comp

持续集成(CI)工具------Hudson/Jenkins(Continuous Integration)安装与配置详解

本文允许转载,但请标明出处:http://blog.csdn.net/wanghantong/article/40985653/, 版权所有 文章概述: 一. 描述了持续集成工具Hudson的安装与配置 二. 描述了Git .Maven环境的安装与配置 三. 描述了扩展邮件通知及其配置方法 四. 描述了jira的配置 一.Hudson简介 Hudson是Jenkins的前身,是基于Java开发的一种持续集成工具,用于监控持续的软件版本发布/测试项目 下载地址:http://eclipse.org

Linux下EclipseCDT工程和TFS的持续集成CI实践

在Linux下使用TFS自动构建,需要自动执行连接tfs服务器的操作,命令行文件包TEE-CLC-10.1.0.2011121402.zip,下载地址:http://www.microsoft.com/en-us/download/details.aspx?id=25125 下文是定制TFS的工作流程的方法进行定制 How to Build Linux Code with TFS 2010 Team Build http://www.richard-banks.org/2010/11/how-t

以review 系统为核心的新一代持续集成

传统的持续集成(CI)系统被设计成作业的流水线.你可以有一个同行评审,然后开始构建作业,然后是单元测试作业,然后是集成测试作业,然后是性能测试作业,诸如此类. 每个作业都是由前一个作业的成功完成事件触发的,而第一个作业则是由版本控制系统中源代码文件的变更事件来触发的.当然,如果你的目标是多个二进制平台,或者如果你正在构建的是一组组件,以此来测试整个的应用程序,那么它还会更加的复杂. 那么如果有任务失败了会怎样?Jez Humble 和 David Farley 在持续交付中认为,你首先需要遵循这

持续集成(CI)- TeamCity实战概览

之所以选择TeamCity,有以下几个原因: Ø 这个软件对于小团队可以免费使用 Ø 安装配置比较简单,系统的要求不是很高(相比VS 2010 TFS) Ø 使用和配置比Cc.net简单一些 Ø 包含了重复代码的检测和分析工具 一.SVN安装 SVN服务安装 http://www.visualsvn.com/files/VisualSVN-Server-2.1.7.msi SVN客户端 TortoiseSVN VisualSVN-2.0.5.msi 二.TeamCity安装 http://www

持续集成(CI)- 各种工具的资料总结

为了实施CI,必须使用工作的支持,以使整个过程的自动化进行,以下把该过程涉及的各种工具汇集一下 必须的工具和功能 源代码控制系统 微软的工具: Microsoft Team Foundation Server (TFS) 或VSS 开源工具:          服务端: Subversion:http://subversion.apache.org/ AnkhSVN (http://ankhsvn.open.collab.net/) Visual SVN Server: http://www.v

Android项目持续集成实践之Gitlab CI

简介 持续集成(Continuous integration)是一种软件开发实践,即团队开发成员经常集成它们的工作,通过每个成员每天至少集成一次,也就意味着每天可能会发生多次集成.每次集成都通过自动化的构建(包括编译,发布,自动化测试)来验证,从而尽早地发现集成错误. 入门 下面我们来简单介绍,如果通过Gitlab CI来对Android项目持续集成. 一言不合,先甩给你一个项目链接:https://gitlab.com/snowdream/Citest 项目很简单,就是一个默认创建的Andro

Android项目持续集成实践之Gitlab CI(Docker版本)

接上一篇 Android项目持续集成实践之Gitlab CI. 在我看来,.gitlab-ci.yml 配置还是有些复杂,写的脚本还是有点多,有没有办法更精简一点呢? 有,那就是Android环境Docker化.(注:对Docker感兴趣的同学,请参考这本书<Docker -- 从入门到实践>). 我在这本书的指导下封装了一个包含Android开发环境的Docker镜像. 1. https://github.com/snowdream/docker-android 1. https://hub

GitLab-CI持续集成(CI)的介绍与运行机制

 GitLab持续集成(CI)的介绍与运行机制 GitLab-CI GitLab-CI就是一套配合GitLab使用的持续集成系统(当然,还有其它的持续集成系统,同样可以配合GitLab使用,比如Jenkins).而且GitLab8.0以后的版本是默认集成了GitLab-CI并且默认启用的. 首先要明白它的组成. 它有两个东西来支撑: gitlab-ci server gitlab-ci-runner gitlab-ci server负责调度.触发Runner,以及获取返回结果. 而gitlab-