共计 3404 个字符，预计需要花费 9 分钟才能阅读完成。
1. 扭转 teamcity server 配置：
Administration (右上)| Global Settings(左中)
2. teamcity 配置(Global Settings 下的选项)：
database：构建的历史，用户及其用户数据以及其余内容存再 datebase 中。
Date Directory: 存配置文件，构建后果，和以后操作文件的目录。
装置服务的机器上的.BuildServer 也存有相干信息。点击 broser 能够看到很多配置相干的文件。<tc home>/TeamCity/conf/teamcity-startup.properties 中保留了 TeamCity 数据寄存目录。
Artifact directories:Build Artifact 是一个 build 产生的文件。此目录寄存 Build Artifact，build data，build logs。
3.Version Control Setting
Default VCS changes check interval: 默认的检测版本库是否产生扭转的工夫距离。默认 60s，能够通过设置 VCS root 进行设置。
Default VCS trigger quiet period：指明了上次 VCS 变变动到减少一个 build 到队列中这个时间段。这由 teamcity 保护。
Checkout directory:
4.Edit configuration Settings
首先选定我的项目，我的项目个别都有子项目。点击我的项目前的三角形就会列举进去。选中对应我的项目后，点击右上角的 build configuration home。能够看到以下几局部：
- General Settings：
- Agent requirement：
Dependencies
一个 build 配置能够依赖多个配置。能够设置两种类型的依赖：Snapshot Dependency 和 Artifact Dependency。Artifact Dependency 是获取其余 build 生成的产品。当没有相应的 Snapshot Dependency 设置时，它次要用于 build 的配置与源无关的状况。例如一个为其余 build 进步可重用组件 (文件，压缩包等) 的 build。
如何增加一个 artifact dependency?
Dependencies|Add new artifact dependency, 此时能够看到如下界面：
各项阐明如下：
| 选项 | 阐明 |
|---|---|
| Depend on | 为以后 build 配置指明一个要依赖的 buil 配置 |
| Get artifacts from | 指明 build 类型，将从这个 build 获取产品(压缩包，文件等)。类型有：last successful build(获取最近的且 build 胜利的产品), last pinned build(最近的固定依赖), last finished build(有 Snapshot Dependency 配置时，产品 build 和同源 build 获取), build from the same chain(有 Snapshot Dependency 配置才无效) |
| Build number | 抉择 last finished build with specified tag 才会用到 |
| Build branch filter | 此项只有当依赖中有一个在 VCS root settings 就指定的分支时才会失效。它容许设置一个分支过滤，从而限度源 build 只在匹配的分支中进行 |
| Artifacts Rules | 参考下文 |
| Clean destination paths before downloading artifacts | 在 copy 产品前，查看这个选项去删除目标目录的内容。它将利用到所有蕴含性规定中 |
Artifacts Rules
个别格局：[+:|-:]SourcePath[!ArchivePath][=>DestinationPath]
每条规定都指明了从源 build 要下载的文件。SourcePath指明了源 build 的产品的目录。它要么指明一个具体的文件或目录，要么用通配符匹配多个文件 (反对通配符：* 匹配任何文件名和目录名，但 / 和 \ 这两个目录分隔符除外。? 匹配除开目录分隔符外的任何一个字符。** 匹配任何符号，蕴含目录分隔符)。下载的内容会依据规定中的SourcePath 的第一个 * 或? 开始放弃目录构造。DestinationPath指明在 agent 上的目标目录(放文件的中央)。如果它是相对路径，build checkout directory 为当前目录。若指标门路不存在，会把文件下载到 checkout 根目录。举例：
源目录文件构造 a /b/c/file.txt。规定：a/b/**=>lib。则会目录会下载一个 lib/c/file.txt 的构造。
源目录文件构造 a /b/c/file.txt。规定：**/*.txt=>lib。则会目录会下载一个 lib/a/b/c/file.txt 的构造。ArchivePath用于下载压缩构造：zip,7zip,jar,tar 和 tar.gz。ArchivePath的匹配规定相似SourcePath。
举例
release-.zip!.dll=>dlls 会下载匹配 release-*.zip 的所有.dll 文件到 dlls 目录。
a.zip!**=>destination 会下载 a.zip 下的所有文件到 destination 目录
a.zip!a/b/c/**/*.dll=>dlls 会下载 a /b/ c 或它的子目录下的所有.dll 文件( 此处存疑)。+：和 -：是用来从要下载的内容中蕴含或排除指定的文件的。
举例:
*/.txt=>texts
-:bad/exclude.txt
以上两条规定会下载所有.txt 文件。但 bad 目录下的 exclude.txt 文件除外。
+:release-.zip!/.dll=>dlls
-:release-0.0.1.zip!Bad.dll
以上两条规定会从 release-.zip 文件中下载所有的 .dll 文件。到 release-0.0.1.zip 中的 Bad.dll 除外。
*/.*=>target
-:excl/*/.*
+:excl/must_have.txt=>target
以上三条规定会下载所有指标文件，但 excl 目录下的文件不会下载，但会下载 excl 下的 must_have.txt 文件会下载。
- Snapshot Dependency 设置的是 build 间源档次的依赖。目标是通过创立不同的 build 配置造成简单的 build 程序，而这些 build 配置用 Snapshot Dependency 关联起来。
Failure Conditions
通过设置失败条件，从而定义一个 build 怎么才算失败(默认状况下，很多出错 build 的后果都是 success)。- Common Failure Conditions(Fail build if:)
it runs longer than … minutes:build 运行工夫限度。以分钟为单位。设置为非零值时，会笼罩全局 (server 档次：Administration|Global settings) 设置。设置为 0，则是无工夫限度, 若有 server 档次的设置，则以它为准。
the build process exit code is not zero：有一个 build step 以非 0 完结，则整个 build 失败。
at least one test failed：有一个 build step 失败，则整个 build 失败。且后续的 build step 不会再运行。若为选中此此选项，即便有大量 build step 失败，后续 build step 仍会执行。
an error message is logged by build runner：build runner报告了错误信息，则认为 build 失败。
an out of memory or crash is detected (Java only): 检测到 JVM 的解体，或 Java 的内存不足问题。 - Additional Failure Conditions
1.Fail build on metric change
2.Fail build on specific text in build log
当 build 日志中呈现特定的文本时，能够定义 build 失败。TeamCity 会查看日志中的每一行。
留神：匹配时，日志前的工夫以及每个步骤开始前的步骤名称等会被疏忽。当然，也可反向定义，即日志未呈现某些文本时，认为 build 失败。
- Common Failure Conditions(Fail build if:)
