集成ci jenkins_持续集成和Jenkins CI Server的关键准则

集成ci jenkins

This article was originally published on TestProject — Test Automation Blog.

本文最初发布在TestProject — Test Automation Blog上。

The following article provides a detailed introduction to Continuous Integration (CI), an imperative practice in software development and Jenkins, the industry standard open-source Continuous Integration tool. By implementing Continuous Integration and the Jenkins CI server, you will discover how Jenkins deployment can assist your development team to release a higher quality software and save precious time.

下一篇文章详细介绍了持续集成(CI)(一种在软件开发中的必要实践)和Jenkins (行业标准的开源持续集成工具)。通过实施持续集成和Jenkins CI服务器，您将发现Jenkins部署如何帮助您的开发团队发布更高质量的软件并节省宝贵的时间。

Looking for more on Jenkins and continuous integration? Check out these great links:

寻找有关Jenkins和持续集成的更多信息？ 查看以下重要链接：

Modern software development practices require deployment of a well functioning software in production as soon or often as possible. For example, agile methodologies directly enforce this behavior by having teams working on small increments and deploying to production after each sprint (read: Test Automation Strategy for Your Agile Project).

现代软件开发实践要求尽快或经常在生产中部署功能良好的软件。例如，敏捷方法通过让团队以较小的增量工作并在每次冲刺后部署到生产中来直接实施此行为(请参阅：《敏捷项目的测试自动化策略》 )。

Days when the development team would be developing a piece of software for months, then pass it to QA, UAT and all down the line to production, do not longer exist. These days, the emphasis is on having a well-functioning software and never allowing situations which could endanger software quality, such as when essential software changes are introduced at the end of the release cycle. This is where Continuous Integration comes into use.

开发团队花几个月的时间来开发一个软件，然后将其传递给QA，UAT以及整个生产过程的日子已经不复存在了。如今，重点是拥有功能良好的软件，决不允许出现可能危及软件质量的情况，例如在发布周期结束时引入必要的软件更改时。 这是持续集成开始使用的地方。

什么是CI？ (What is CI?)

CI is a practice which enforces frequent integration of tested code to the stable branch of your project.. I would especially emphasize “tested code”, since that means that a feature developed on a separate branch is also tested and as such, is integrated to the stable branch.

CI是一种强制将经过测试的代码频繁集成到项目的稳定分支中的实践。我特别强调“经测试的代码” ，因为这意味着还测试了在单独的分支上开发的功能，因此将其集成到稳定的分支。

谁在做CI？ (Who Is Doing CI?)

In general, DevOps engineers are usually assigned to setup the CI pipeline. Nowadays, the role of a DevOps engineer is very similar to a test engineer since both ensure process and software quality. I usually say that QA and production is the closest meeting point with the client. In that sense, CI provides very powerful tools for test engineers to enhance overall process and software quality by actively participating in the following areas:

通常，通常会指派DevOps工程师来设置CI管道。如今，DevOps工程师的角色与测试工程师非常相似，因为它们可以确保过程和软件质量。我通常会说质量保证和生产是与客户最接近的交汇点。从这个意义上讲，CI通过积极参与以下领域，为测试工程师提供了非常强大的工具，以提高整体流程和软件质量：

Test automation: A couple of years ago, there was a discussion about manual testing vs. automation testing. With CI, test automation becomes indispensable, this will eventually save a lot of precious time to focus on other testing tasks. It is also worth saying that manual testing and automation testing cannot be mutually exclusive.

测试自动化：几年前，关于手动测试与自动化测试的讨论。借助CI，测试自动化变得必不可少，这最终将节省大量宝贵的时间专注于其他测试任务。还值得一提的是，手动测试和自动化测试不能互斥。
Test report: For test reports in CI, we can use existing reporting solutions or build our own reporting module. In both cases, this gives a clear indication on the “health” of our application’s code with each build run. It is important that this information will be accessible to all members of the development team and constant efforts will be invested in order to upgrade code quality.

测试报告：对于CI中的测试报告，我们可以使用现有的报告解决方案或构建我们自己的报告模块。在这两种情况下，这都会清楚地表明每次构建运行时应用程序代码的“运行状况”。重要的是，开发团队的所有成员都可以访问此信息，并且将进行不断的努力以提高代码质量。
Deployment process: Test engineers are more involved in application’s deployment process, which yields additional information about the internal architecture of test automation tools or frameworks in use. This knowledge is of a great importance especially in order to identify “hidden” application issues.

部署过程：测试工程师会更多地参与应用程序的部署过程，这会产生有关所使用的测试自动化工具或框架的内部体系结构的其他信息。特别是对于识别“隐藏的”应用程序问题，这一知识非常重要。

CI的好处 (CI Benefits)

CI emphasizes test automation, allowing the test engineer to keep focus on exploratory testing, testing edge cases or even finding new approaches in testing.
CI强调测试自动化，允许测试工程师专注于探索性测试，测试边缘案例，甚至在测试中寻找新方法。
Quality of particular commit on specific branch is visible within minutes of developer’s commit.
在开发人员提交后的几分钟内，即可看到特定分支上特定提交的质量。
Integration to stable branch is done very carefully after the code has been tested on branch (CI process is supposed to run this). The deployment of an application is executed automatically once properly had been setup, and does not require repetitive commands.
在分支上测试了代码之后，要非常仔细地将其集成到稳定分支中(应该由CI进程来运行)。一旦正确设置了应用程序，就会自动执行应用程序的部署，并且不需要重复的命令。
From the team’s point of view, all these benefits multiply.
从团队的角度来看，所有这些好处都是成倍增加的。

典型的CI方案 (Typical CI Scenarios)

The development team has its own source version control repository where the project exists (nowadays that is usually Github). Stable branch (master) is usually considered as a working branch and development of new features is rarely done directly on the master. Instead, developers create their own branch where developing new features (branch A for feature A). When change is pushed to repository on that particular branch and developers make pull requests, some basic set of tests (smoke tests) should be executed against that branch. From the CI perspective, this usually means the following:

开发团队在项目所在的地方拥有自己的源代码版本控制存储库(现在通常是Github)。稳定分支(主机)通常被视为工作分支，很少有新功能的开发直接在主机上进行。而是，开发人员在开发新功能的地方创建自己的分支(功能A的分支A)。当将更改推送到该特定分支上的存储库，并且开发人员发出拉取请求时，应对该分支执行一些基本的测试集(烟雾测试)。从配置项的角度来看，这通常意味着：

When CI process is completed, from the perspective of test engineers and developers, there are few requirements:

从测试工程师和开发人员的角度来看，完成CI流程后，几乎没有要求：

Tester: re-test once again feature A on branch A

测试人员：再次测试分支A上的功能A
Developer: peer code review from another developer to make sure that code quality is good enough

开发人员：请其他开发人员进行对等代码审查，以确保代码质量足够好
Developer: manually merge code to master and resolve any merge conflicts (if arise).

开发人员：手动合并代码以掌握和解决任何合并冲突(如果出现)。

Smoke tests save considerable amount of time to both developers who will perform code review, as well as to test engineers who need to re-test feature A on pull request branch. If smoke tests fail on pull request, developers who worked on feature A are now responsible to fix smoke test feature and make new pull request (code with issue will not be merged to master until it is fixed).

冒烟测试为执行代码审查的开发人员以及需要在拉取请求分支上重新测试功能A的测试工程师节省了大量时间。如果冒烟测试在拉动请求上失败，则开发功能A的开发人员现在应负责修复冒烟测试功能并提出新的拉动请求(有问题的代码在修复后将不会合并到主服务器上)。

If this passes and new code for feature A is merged on master from CI perspective, the following occurs:

如果通过此操作，并且从CI角度将功能A的新代码合并到主服务器上，则会发生以下情况：

This indicates that the merge was successful, smoke test feature still works and it is now the responsibility of test engineers to re-test feature A once again on master branch (to make sure that the merge did not cause any side effect on feature A). Of course, over time it is a good practice to enhance your test automation suite so that most of the features are covered.

这表明合并成功，冒烟测试功能仍然有效，并且测试工程师现在有责任在主分支上再次重新测试功能A(以确保合并不会对功能A造成任何副作用) 。当然，随着时间的流逝，增强您的测试自动化套件是一个好习惯，以便涵盖大多数功能。

This becomes more and more important in later iterations in the project, when test engineers have more tasks (testing current features as well as all previous features). This is where regression testing becomes handy: from the CI perspective, the execution of regression tests usually happens either when the test engineer explicitly runs regression testing or by using a scheduler (for example: execute regression tests every night). It is a good practice to make this job customized so that we are able to specify against which branch this job will be executed (here you can read more on why and when to perform regression test automation). The procedure can look as follows:

当测试工程师承担更多任务(测试当前功能以及所有先前功能)时，这在项目的后续迭代中变得越来越重要。这就是回归测试变得很方便的地方：从CI角度来看，回归测试的执行通常在测试工程师明确运行回归测试或使用调度程序时进行(例如：每晚执行回归测试)。定制该作业是一个好习惯，这样我们就可以指定将针对哪个分支执行该作业(在这里您可以阅读有关为什么以及何时执行回归测试自动化的更多信息 )。该过程如下所示：

Jenkins工具简介 (Introduction to Jenkins Tool)

Jenkins CI服务器术语 (Jenkins CI server terminology)

Job: Most important “unit” in Jenkins terminology is the job. Job is a single execution unit in Jenkins CI server that must have some outcome (pass/fail). For example: a job can be a deployment job, smoke test job, regression test job, etc. Job consists of multiple areas that are executed in sequential fashion, which will be explained in the next paragraph: Anatomy of Jenkins job.

工作：詹金斯术语中最重要的“单元”是工作。 Job是Jenkins CI服务器中的单个执行单元，必须具有一定的结果(通过/失败)。例如：一个作业可以是部署作业，烟雾测试作业，回归测试作业等。该作业包含按顺序执行的多个区域，将在下一段中对其进行解释：Jenkins作业剖析。

Plugin: One of the major features of Jenkins test automation is the ability to customize it by either using existing plugins or creating your own. Everything in Jenkins tool, from job configuration parts to Jenkins configuration parts is actually plugin. Since Jenkins’ community is substantial, various Jenkins plugins already exist for the use of the most demanding CI workflow tasks. Meaning, it is very likely that you will encounter a helpful plugin instead of creating a custom solution.

插件： Jenkins测试自动化的主要功能之一是能够通过使用现有插件或创建自己的插件对其进行自定义。 Jenkins工具中的所有内容，从作业配置部分到Jenkins配置部分，实际上都是插件。由于Jenkins的社区很大，因此已经存在各种Jenkins插件，可以使用最苛刻的CI工作流程任务。这意味着，您很有可能会遇到有用的插件，而不是创建自定义解决方案。

Node: In the simplest setup, Jenkins instance will be running on one machine and all jobs will be executed there. For minor tests and small number of jobs, it makes sense. However, in practice, there are often cases when multiple teams use same Jenkins instance. Since they have large number of jobs, execution on one instance is considered as bad practice for number of reasons: security, disaster recovery, performance, scalability, etc.

节点：在最简单的设置中，Jenkins实例将在一台计算机上运行，所有作业将在该计算机上执行。对于较小的测试和少量的工作，这是有道理的。但是，实际上，经常有多个团队使用相同的Jenkins实例的情况。由于它们具有大量的作业，因此出于多种原因，在一个实例上执行被认为是不好的做法：安全性，灾难恢复，性能，可伸缩性等。

Enter master/slave nodes in Jenkins: Jenkins master is used only for job scheduling that will be executed on Jenkins slave machines. This way, Jenkins master machine is not heavily utilized and teams have their own slave machines with the size most suitable for their test automation project. Also, slave nodes are then configured to handle some number of parallel jobs that are executed (number of executors per each node). There is also a possibility to configure on-demand nodes from AWS. That would mean nodes will exist only when job needs to be executed on them. This is very useful, since we want larger machines that will be fully utilized only when regression tests are running. For this particular scenario, larger EC2 instance would be spun up on AWS, job will be executed on this instance and when completed (based on idle time configured), this instance would be alive for some time. After that, it would be determined which is more advantageous when using services paid per hour (e.g. AWS services).

在Jenkins中输入主/从节点： Jenkins主服务器仅用于将在Jenkins从计算机上执行的作业调度。这样，詹金斯(Jenkins)的主控机器就不会被大量利用，并且团队拥有自己的从属机器，其大小最适合其测试自动化项目。而且，从属节点随后被配置为处理一定数量的并行作业(每个节点的执行程序数量)。还可以从AWS配置按需节点。这意味着节点仅在需要在其上执行作业时才存在。这非常有用，因为我们希望只有在运行回归测试时才能充分利用大型计算机。对于此特定场景，将在AWS上启动较大的EC2实例，在该实例上执行作业，完成后(基于配置的空闲时间)，该实例将存活一段时间。之后，将确定使用每小时支付的服务(例如AWS服务)时哪个更有利。

詹金斯·乔布斯的解剖 (Anatomy of Jenkins Job)

In Jenkins CI server, each Jenkins job consists of multiple parts:

在Jenkins CI服务器中，每个Jenkins作业都包含多个部分：

General: This is where we specify project/job name/description, add parameters for jobs if needed, define job log rotation policy, etc. Next screens show how to configure log rotation (you can specify number of days to keep build logs or number of last build logs to keep), how to parameterize job (by adding string BUILD_ID which has default value 0.0.1 but, this value can be specified when job is started) and how to configure where this job will be executed (slave node name):

常规：这是我们在其中指定项目/作业名称/描述，在需要时添加作业参数，定义作业日志轮换策略等的地方。下一个屏幕显示如何配置日志轮换(您可以指定保留构建日志的天数或编号保留最后一个构建日志)，如何对作业进行参数化(通过添加字符串BUILD_ID(其默认值为0.0.1，但是可以在作业启动时指定此值))以及如何配置将在何处执行该作业(从属节点名称) )：
Jenkins Source Code Management: As the name suggests, this is where we define source code repository like GitHub or Subversion in Jenkins CI server:

Jenkins源代码管理：顾名思义，这是我们在Jenkins CI服务器中定义GitHub或Subversion之类的源代码存储库的地方：
Jenkins Build Triggers: Schedule the time a job will be executed (periodically, after some other job, when GitHub pull request happens, when change is pushed to GitHub, etc.

Jenkins构建触发器：计划执行作业的时间(定期执行其他作业之后，发生GitHub拉取请求时，何时将更改推送到GitHub等)。
Jenkins Build Environment: This is where we define options related to the environment in which build will be executed (remove workspace every time job is executed, abort job if hangs for some period of time … etc.)

Jenkins Build Environment：我们在此处定义与将要执行构建的环境相关的选项(每次执行作业时都删除工作空间，如果挂起一段时间则中止作业……等等)
Jenkins Build: In Jenkins CI server, this is the most important step of every job. The result of this step impacts the status of the job at the end of execution. Depending on the installed plugins, many options are available, the most used plugins are: Execute shell, Execute Groovy script, Invoke Ant/Maven/Gradle scripts, execute windows batch command, etc.

Jenkins构建：在Jenkins CI服务器中，这是每项工作中最重要的步骤。该步骤的结果会影响执行结束时作业的状态。根据安装的插件，有许多选项可用，最常用的插件是：执行外壳，执行Groovy脚本，调用Ant / Maven / Gradle脚本，执行Windows批处理命令等。

This is an example of frequently used “Execute shell” plugin which gives ability to either write your own shell script inline or execute existing one.

这是一个经常使用的“执行外壳”插件示例，该插件可以内联编写自己的外壳脚本或执行现有的外壳脚本。
Jenkins Post-build actions: This part of the job is used for reporting results of the job or invoking other jobs in Jenkins pipeline. In general, we can send an email with status of job execution, we can publish HTML reports, JUnit results, publish artifacts that were built in build phase to S3, etc.

Jenkins生成后操作：作业的这一部分用于报告作业结果或调用Jenkins管道中的其他作业。通常，我们可以发送一封具有作业执行状态的电子邮件，我们可以发布HTML报告，JUnit结果，将在构建阶段构建的工件发布到S3等。

Notice how $BUILD_ID is specified in email’s subject line. Since this job is parameterized, this value is specified when starting this job. This parameter can be used in both Jenkins Build and Post-build action parts of the job.

请注意如何在电子邮件的主题行中指定$ BUILD_ID。由于已对该作业进行了参数化，因此在启动该作业时会指定此值。此参数可以在作业的Jenkins构建和构建后操作部分中使用。

结论 (Conclusion)

By now, you are aware of the major advantages of Jenkins CI server and how CI itself adds to the software development process and to a test engineer as well. Same as with every other technology, it takes time to grasp the basics and experience the advantages. I highly recommend investing time into CI, it will definitely be worth it in the long run. Especially, once applying Jenkins CI server, many painful and repetitive procedures will be automated and suddenly you will have more time to focus on product improvements.

到目前为止，您已经了解了Jenkins CI服务器的主要优势，以及CI本身如何添加到软件开发过程以及测试工程师中。与其他所有技术一样，需要花费一些时间来掌握基础知识并体验其优势。我强烈建议您花时间在CI上，从长远来看，绝对值得。特别是，一旦应用了Jenkins CI服务器，许多痛苦且重复的过程将自动进行，突然间，您将有更多时间专注于产品改进。

Does your team implement Continuous Integration and Jenkins CI server as well? Feel free to share your team’s experiences and ask questions in the comments!

您的团队是否也实施了持续集成和Jenkins CI服务器？ 随时分享您的团队经验，并在评论中提出问题！