经过 20 天的练习,我们已经大致掌握了 TeamCity 的基本功能,刚好是一个很好的机会来回顾一下这一段时间我们学习到的观念、流程、动作以及接触到的技术名词。读者可以透过这份技术名词清单来复习一下目前用过的 TeamCity 功能,为接下来的 10 天做准备。
如同之前提到的,TeamCity 是一个 Server(+Database)+ Agent 的组合,了解 Server 及 Agent 各自的责任、分工及合作模式,会有助於我们了解 TeamCity 整体运作流程。我们以下面这张运行周期流程图来说明:
复习完 TeamCity 的工作流程後,我们来详细解释以上流程里提到的技术名词。
在 TeamCity 的整体架构里,主机(Server)本身并不会执行建置或测试的工作。其工作是去监控所有连线到的建置代理,依照建置代理的环境(也可以把环境类比成能力)分配序列(Queue)里的建置工作并回报结果。所有建置结果的资讯(包括建置历史以及除了 Artifact 和 Log 外所有跟建置有关的资料)、程序码储存库里的变更、建置代理、建置序列、使用者帐号及权限等,都是存在资料库里。
在这边额外提一下,虽然把主机、资料库和建置代理都安装在一台电脑上是可行的,在这份系列教学文里也是这麽做,但这通常仅是在测试情境这样用。在 Production 环境上,还是建议把这 3 种元件都分别安装在不同的机器上,可以大大增进整体效能,也能提升可用性、降低单点故障的风险。
建置代理是实际执行建置任务的程序,它需要在 TeamCity 主机之外独立安装和设定。为了测试专案是否能在不同组合下成功建置,我们通常会将建置代理安装在不同平台、不同作业系统、搭配不同运行环境以取得最多的测试面向,让开发者能够即早发现有问题的来源、开发更可靠的软件。
在 TeamCity 上的专案意思指的是一个软件专案或特定的软件发行版本。每个专案都可以包含多个建置设定。
一组定义建置程序的设定组合,这些设定包括版本储存库源头、建置步骤、触发器…等。
简单来说就是版本控制设定的集合(来源位置、帐号、密码、提取模式等设定),TeamCity 会用这些资讯与版本管理系统沟通来监看变更并用这个源头来建立建置任务。
实际会被执行的任务。每一个建置步骤会由一个建置执行器以特定的建置工具(比方说 Ant、Gradle、MSBuild)、测试框架(比方说 NUnit) 或程序码分析引擎运行。因此在一个建置任务里,您可以设计一系列的步骤来执行测试、取得覆盖率报告、建置您的专案…等。
触发器就是在某个事件发生时会触发建置任务的规则。比方说,当 VCS 触发器发现版本储存库里有新的变更时,就会自动触发新的建置任务。TeamCity 支援数种触发器,像是我们也可以使用计时器触发器(Timer Trigger)来定期的执行特定建置任务。
所谓变更就是任何您在原始码里做的任何改变。每当我们完成一件工作,把程序码提交到版本管理系统但还没有被 TeamCity 建立一个建置任务时,这样就算是有一个新的变更,TeamCity 发现有新的变更後,就会将它依照建置设定排进待完成的任务清单里。
在 TeamCity 里提到建置可以指两件事:编译一个应用程序的实际过程以及最後产生出的结果本身。当一个建置工作被触发後,它就会被放进建置序列等待闲置的建置代理拿去执行。而当建置工作完成时,建置代理会把建置成品送回主机。
一个已被触发、正在等待执行的建置清单。TeamCity 会将这些工作分配给符合运行条件且闲置的建置代理执行。要注意一点,这些建置工作都是在建置代理可以开始工作的当下才被指派,并不是在序列里就被预先指派的。
建置工作完成後产生的档案,比方说,Installer、WAR 档、报表、Log,这些档案我们统称为「成品」。TeamCity 会将这些档案储存起来,我们可以依照需求下载使用。
看完这份技术名词清单,相信您对 TeamCity、建置流程等环境有更深入的认识,应该也能厘清一些误解。每一个名词笔者都有附上英文原文方便对照,希望能帮助您在看原文文件时可以更容易对应。
>>: [Day11] SSTI (Server Side Template Injection)
前言 今日的程序码 => GITHUB 灵感来自於我在使用某某知名外送平台的时候,突然在想有这...
在接收到讯息的时候,我们可以得知该使用者在此 line bot 的 user id,如果想要知道更详...
Chatbot integration- 韩文翻译机器人 这篇会针对韩文翻译机器人的功能,整合 Az...
做好学习程序语言这件事,可以说已经成为了全民运动。在人类的历史中,我们总是尽了一切努力想搞懂学习程序...
今天要来实作的快速排序法Quick Sort,虽然不是最佳的(以前学习的时候看到他的名字以为它会是最...