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

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

原文同步至 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

参考资料

目录
相关文章
|
3月前
|
JavaScript 前端开发 持续交付
Prettier 高级应用:集成 CI/CD 流水线与插件开发
【10月更文挑战第18天】Prettier 是一款流行的代码格式化工具,它能够自动将代码格式化成一致的风格,从而提高代码的可读性和维护性。对于希望进一步发挥 Prettier 潜力的高级用户而言,将 Prettier 集成到持续集成(CI)和持续部署(CD)流程中,确保每次提交的代码都符合团队标准,是非常重要的。此外,通过开发自定义插件来支持更多语言或扩展 Prettier 的功能也是值得探索的方向。本文将详细介绍这两方面的内容。
63 2
|
1月前
|
存储 测试技术 持续交付
Docker与CI/CD的集成策略及其对软件开发效率和质量的提升作用
本文探讨了Docker与CI/CD的集成策略及其对软件开发效率和质量的提升作用。首先介绍了CI/CD的基本概念,接着阐述了Docker在环境一致性、快速部署、资源隔离和轻量化方面的优势。文章还详细讨论了构建、测试和部署阶段的具体集成方法,以及集成后带来的效率提升、可靠性增强、加速交付和易于管理等好处。最后,通过案例分析展示了集成的实际效果,强调了Docker与CI/CD结合的重要性和未来前景。
48 2
|
2月前
|
存储 监控 Devops
DevOps实践:持续集成/持续部署(CI/CD)的实战指南
DevOps实践:持续集成/持续部署(CI/CD)的实战指南
|
2月前
|
jenkins Java 持续交付
软件开发自动化程度的不断提高,持续集成(CI)和持续部署(CD)成为现代软件开发的重要组成部分
随着软件开发自动化程度的不断提高,持续集成(CI)和持续部署(CD)成为现代软件开发的重要组成部分。本文以电商公司为例,介绍如何使用 Jenkins 自动发布 Java 代码,包括安装配置、构建脚本编写及自动化部署等步骤,帮助团队实现高效稳定的软件交付。
45 3
|
3月前
|
缓存 监控 测试技术
掌握容器化持续集成/持续部署(CI/CD)的最佳实践
【10月更文挑战第8天】本文介绍了容器化持续集成/持续部署(CI/CD)的最佳实践,涵盖容器化CI/CD的概念、优势和实施步骤。通过使用容器技术,可以实现环境一致性、快速迭代和易于扩展,提高软件开发的效率和可靠性。文章还详细讨论了编写高效的Dockerfile、自动化测试、安全性、监控和日志管理等方面的最佳实践。
|
3月前
|
Devops jenkins 测试技术
DevOps实践:持续集成与持续部署(CI/CD)的实现之路
【9月更文挑战第33天】在软件开发的海洋中,DevOps是一艘能够加速航行、提升航程质量的巨轮。本文将作为你的航海图,指引你理解并实现DevOps文化中的核心环节——持续集成(CI)与持续部署(CD)。我们将从基础概念出发,逐步深入到实际操作,带你领略代码到部署的全过程。准备好扬帆起航,让我们共同探索如何通过自动化工具和流程优化,让软件交付变得既高效又可靠。
|
3月前
|
jenkins Shell 持续交付
Jenkins持续集成GitLab项目 GitLab提交分支后触发Jenkis任务 持续集成 CI/CD 超级详细 超多图(二)
Jenkins持续集成GitLab项目 GitLab提交分支后触发Jenkis任务 持续集成 CI/CD 超级详细 超多图(二)
85 0
|
2月前
|
运维 安全 Devops
DevOps实践:持续集成与持续部署(CI/CD)的自动化之路
【10月更文挑战第22天】在软件交付的快速迭代中,DevOps文化和实践成为企业加速产品上市、保证质量和提升客户满意度的关键。本文将通过一个实际案例,深入探讨如何利用持续集成(Continuous Integration, CI)和持续部署(Continuous Deployment, CD)实现软件开发流程的高效自动化,包括工具选择、流程设计以及问题解决策略。我们将一起探索代码从编写到部署的全自动化旅程,揭示其对企业运维效率和产品质量所带来的深远影响。
|
4月前
|
Kubernetes Go 持续交付
一个基于Go程序的持续集成/持续部署(CI/CD)
本教程通过一个简单的Go程序示例,展示了如何使用GitHub Actions实现从代码提交到Kubernetes部署的CI/CD流程。首先创建并版本控制Go项目,接着编写Dockerfile构建镜像,再配置CI/CD流程自动化构建、推送Docker镜像及部署应用。此流程基于GitHub仓库,适用于快速迭代开发。
89 3
|
4月前
|
Kubernetes 持续交付 Go
创建一个基于Go程序的持续集成/持续部署(CI/CD)流水线
创建一个基于Go程序的持续集成/持续部署(CI/CD)流水线

热门文章

最新文章