Continuous Integration (CI) with TeamCity

The original text is synchronized to https://waylau.com/continuous-integration-with-teamcity/

Continuous Integration, also known as CI, is the foundation of modern software development techniques. This article discusses how to use the TeamCity continuous integration tool to achieve continuous integration of projects.

Why do we need CI

Currently, CI has been adopted by many software development teams in the current industry and is a common practice to ensure code quality throughout the software development life cycle. It is a development practice designed to help development teams address the following challenges in the software development process:

Automatic inspection: When the software development team adds or modifies the code periodically, the CI server can continuously obtain the source code that is added or modified and checked in, and can check the quality or coding standard of these changed codes. Inspection of. Commonly used tools are PMD, SonarQube , CheckStyle, FindBugs, etc.
Automatic build: The CI system will automatically check out the code and build the target software according to a pre-established configuration plan or a specific event. The plan here can be a periodic time point, such as a build every 10 minutes or an hour, or a build can be triggered based on a specific event, such as a user actively issuing a build command, or triggering a build based on code changes. The build tool can choose Maven or Ant and so on.
Automatic testing: After the build check is completed, a set of pre-established test rules can be executed, or test cases can be tested during the build process, provided that the project team adopts Test-Driven Development (TDD). Commonly used testing tools include JUnit, JWebUnit, Selenium, etc.
Automatic deployment: When automated checks and tests are successfully completed, the packaged software, artifacts are deployed to a runtime environment or software repository. In this way, components can be provided to users more quickly.
Timely reminder: When an error is found or a preset event is triggered during any of the above-defined stages, the corresponding project stakeholders can be notified in time for processing. For example, if an error occurs during the build process, the CI server can notify the developer by email to fix it; when the automated deployment is completed, the CI server informs the tester that the test can be performed, and wait. In addition to emails, reminders can be text messages, desktop notifiers, or loudspeakers.

In short, CI is a software development practice that achieves speed, efficiency, and quality in the agile development process, and can continuously deliver usable software products to users. For more details, please refer to "Why we urgently need continuous integration (Continuous Integration)" .

Introduction to TeamCity

As the TeamCity official website introduces itself, TeamCity is a powerful CI tool ("Powerful Continuous Integration out of the box"). Its features include:

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 is divided into free Professional Edition license (Professional Server License) and paid Enterprise Edition license (Enterprise Server License). The functions of the two are exactly the same, but there will be restrictions on the number of them. Among them, the free version license includes 20 build configurations and 3 build agents. A Build Agent License can be purchased separately, including 1 build agent and 10 build configurations, for $299. Enterprise licenses are unlimited in build configuration and can be purchased for anywhere from 3 to 100 build agents for approximately $1999 to $21999.

For trial users or small teams, the Professional Server License is sufficient.

Implementing CI with TeamCity

The following introduces the common usage of TeamCity. The version used in this example is TeamCity Professional 10.0.4.

Create a project and associate source code

After creating a project (Project), you can associate the project with the corresponding source code. The source code management tool supports Git, CVS, Subversion, etc. The project used in this example is necc_country, and the source code management tool used is Subversion.

Under VCS Roots, add a source code associated address: svn://10.30.22.18:32881/unengli/biz/gov/necc/branches/country.

Create a build configuration

Build Configurations (Build Configurations) refer to a series of step plans during the project build process. For example, it can be code quality check, Maven build, release, etc. steps.

We choose to click the "Edit" button and set up some build plans in the "Build Steps".

1. Code Quality Check

Use SonarQube for code quality checking.

in,

SonarQube Runner Parameters: are some configuration parameters of SonarQube, including the IP of the SonarQube server.
Sources location: The location of the project source code.
Modules: Modules that need to be checked.

2. Maven build the project

Use Maven to build the project. You can customize Maven's Goals, such as:

clean install -Dmaven.test.skip=true

clean package

Wait. If the development method is TDD, it is recommended not to use -Dmaven.test.skip=trueit to filter out test steps.

3. Deploy the project

You can use FTP Upload or SSH Upload to publish the release package to the deployment environment. In this example, since the CI and deployment environment are on the same host, FTP Upload can be used.

in,

Deployment Credentials: Username and password for the deployment host.
Target host: is the location of the target deployment environment. The location here refers to the relative path location of the user. For example, if the location is set to 10.30.22.18:/necc_simulation/gov-tomcat-necc/webapps/gov, and the user used is dev, then the absolute path of the final deployment to the host is /home/dev/necc_simulation/gov-tomcat-necc/webapps/gov.
Paths to sources: The location of the release package to be deployed, where %teamcity.build.workingDir%/web/gov/target/govin %teamcity.build.workingDir%is the workspace built by TeamCity.

4. Restart the web container

In this example, we deployed the project to the Tomcat container. After deployment, we need to restart Tomcat. Here, we use SSH Exec to execute a script that restarts Tomcat.

in,

Deployment Target: The host where the Tomcat container is located.
Deployment Credentials: Username and password for the deployment host.
SSH Commands: Scripts executed on the host.

# 切换到 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

trigger build

Builds can be executed with automatic triggering or manual triggering.

Click "Run" in the upper right corner to trigger the build manually.

After the project is associated with the corresponding source code, a "VCS Trigger" will be generated by default, that is, as long as a change is submitted to the code management server, the build will be automatically triggered. Of course, you can also add multiple triggers yourself.

Report

You can view the entire build process, including the time it took to build, etc.

[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