互联网敏捷DevOps和自动化之5.SCM和持续集成

持续集成的价值是什么？对于开发和测试人员又意味着什么呢？

1.1 持续集成介绍文章源自玩技e族-https://www.playezu.com/194448.html

使用持续集成和测试驱动开发的敏捷实践
文章源自玩技e族-https://www.playezu.com/194448.html

<img data-cke-saved-src="https://www.playezu.com/wp-content/uploads/2022/08/20180728095507120.png" src="https://www.playezu.com/wp-content/uploads/2022/08/20180728095507120.png" "="">文章源自玩技e族-https://www.playezu.com/194448.html

说到持续集成，我们就不得不提到源代码管理，尤其是互联网得今天源代码得管理至关重要，分之策略和代码合并，代码review都是整个软件生命周期得关键点，那么下面我就对常用得代码管理svn和git进行详细介绍和阐述文章源自玩技e族-https://www.playezu.com/194448.html

About Git and Git flow文章源自玩技e族-https://www.playezu.com/194448.html

Subversion有一个很标准的目录结构，是这样的。比如项目是proj，svn地址为svn://proj/，那么标准的svn布局是文章源自玩技e族-https://www.playezu.com/194448.html

svn://proj/|+-trunk+-branches+-tags文章源自玩技e族-https://www.playezu.com/194448.html

这是一个标准的布局，trunk为主开发目录，branches为分支开发目录，tags为tag存档目录（不允许修改）。但是具体这几个目录应该如何使用，svn并没有明确的规范，更多的还是用户自己的习惯。对于这几个开发目录，一般的使用方法有两种。我更多的是从软件产品的角度出发（比如freebsd），因为互联网的开发模式是完全不一样的。第一种方法，使用trunk作为主要的开发目录。一般的，我们的所有的开发都是基于trunk进行开发，当一个版本/release开发告一段落（开发、测试、文档、制作安装程序、打包等）结束后，代码处于冻结状态（人为规定，可以通过hook来进行管理）。此时应该基于当前冻结的代码库，打tag。当下一个版本/阶段的开发任务开始，继续在trunk进行开发。此时，如果发现了上一个已发行版本（Released Version）有一些bug，或者一些很急迫的功能要求，而正在开发的版本（Developing Version）无法满足时间要求，这时候就需要在上一个版本上进行修改了。应该基于发行版对应的tag，做相应的分支（branch）进行开发。例如，刚刚发布1.0，正在开发2.0，此时要在1.0的基础上进行bug修正。按照时间的顺序

1.1.0开发完毕，代码冻结

2.基于已经冻结的trunk，为release1.0打tag此时的目录结构为svn://proj/ +trunk/ (freeze) +branches/ +tags/ +tag_release_1.0　(copy from trunk)

3.2.0开始开发，trunk此时为2.0的开发版

4.发现1.0有bug，需要修改，基于1.0的tag做branch此时的目录结构为svn://proj/ +trunk/ ( dev 2.0 ) +branches/ +dev_1.0_bugfix (copy from tag/release_1.0) +tags/ +release_1.0　(copy from trunk)

5.在1.0 bugfix branch进行1.0 bugfix开发，在trunk进行2.0开发

6.在1.0 bugfix 完成之后，基于dev_1.0_bugfix的branch做release等

7.根据需要选择性的把dev_1.0_bugfix这个分支merge回trunk（什么时候进行这步操作，要根据具体情况）

8.这是一种很标准的开发模式，很多的公司都是采用这种模式进行开发的。trunk永远是开发的主要目录。

第二种方法，在每一个release的branch中进行各自的开发，trunk只做发布使用。这种开发模式当中，trunk是不承担具体开发任务的，一个版本/阶段的开发任务在开始的时候，根据已经release的版本做新的开发分支，并且基于这个分支进行开发。还是举上面的例子，这里面的时序关系是。

1.1.0开发，做dev1.0的branch此时的目录结构svn://proj/ +trunk/ (不担负开发任务 ) +branches/ +dev_1.0 (copy from trunk) +tags/

2.1.0开发完成，merge dev1.0到trunk此时的目录结构svn://proj/ +trunk/ (merge from branch dev_1.0) +branches/ +dev_1.0 (开发任务结束，freeze) +tags/

3.根据trunk做1.0的tag此时的目录结构svn://proj/ +trunk/ (merge from branch dev_1.0) +branches/ +dev_1.0 (开发任务结束，freeze) +tags/ +tag_release_1.0 (copy from trunk)

4.1.0开发，做dev2.0分支此时的目录结构svn://proj/ +trunk/ +branches/ +dev_1.0 (开发任务结束，freeze) +dev_2.0 （进行2.0开发） +tags/ +tag_release_1.0 (copy from trunk)

5.1.0有bug，直接在dev1.0的分支上修复此时的目录结构svn://proj/ +trunk/ +branches/ +dev_1.0 (1.0bugfix) +dev_2.0 （进行2.0开发） +tags/ +tag_release_1.0 (copy from trunk)

选择性的进行代码merge

这其实是一种分散式的开发，当各个部分相对独立一些（功能性的），可以开多个dev的分支进行开发，这样各人/组都不会相互影响。比如dev_2.0_search和dev_2.0_cache等。但是这样merge起来就是一个很痛苦的事情。这里要注意一下的，第六步进行选择性的merge，是可以当2.0开发结束后一起把dev_1.0（bugfix用）和dev_2.0（新版本开发用）merge回trunk。或者先把dev_1.0 merge到dev_2.0，进行测试等之后再merge回trunk。这两种方法各有利弊，第一种方法是可以得到一个比较纯的dev_2.0的开发分支，而第二种方法则更加的保险，因为要测试嘛。以上呢，就是我说的两种开发模式了，具体哪种好，并没有定论。这里大致的说一下各自的优缺点第一种开发模式（trunk进行主要开发，集中式）：优点：管理简单缺点：当开发的模块比较多，开发人数/小团队比较多的时候，很容易产生冲突而影响对方的开发。因为所有的改动都有可能触碰对方的改动第二种开发模式（分支进行主要开发，分散式）：优点：各自开发独立，不容易相互影响。缺点：管理复杂，merge的时候很麻烦，容易死人

1.2 持续集成概念

“持续集成”一词来源与极限编程（Extreme Programming）,作为它的12个实践原则之一出现。ThoughtWorks首席科学家、软件开发领域大事Martin Fowler对持续集成是这样定义的：持续集成是一种软件开发实践，即团队开发成员经常集成他们的工作，通常每个成员每天至少集成一次，也就意味置顶每天可能发生多次集成。每次集成都是通过自动化的构建（包括编译、发布、自动化测试）来验证，从而尽快地发现集成错误。许多团队发现这个过程可以大大的减少集成的问题，让团队能够更快的开发内聚的软件。从上面的定义可以看出，一个典型的持续集成周期包括以下几个步骤：

1.版本控制服务器上有最新的代码

2.持续集成服务器从版本控制服务器下载最新的代码

3.等代码完全更新以后，调用自动化编译脚本，进行代码编译

4.运行所有的自动化测试（单元测试、接口测试、系统级别的UI自动化测试等）

5.将结果写入报告文件中，反馈给团队成员

6.如果构建失败，必须尽快修改确保下次构建成功

7.产生可执行的软件版本，提供给测试人员进行测试持续集成框架是由代码提交活定时来触发的（项目级别的持续集成可以由开发每次代码提交触发，而产品级别的持续集成可以由定时来触发），每次提交到版本控制服务器上的代码都要经过自动化构建，确保每次的代码变更都不会导致持续集成失败。

1.3 持续集成目的和价值

持续集成的目的不是减少build失败的次数，而是尽早发现问题，在最短的时间内解决问题，减少风险和浪费。从而让产品开发流程更加敏捷，缩短产品开发周期，在产品上线后，让用户用得更加顺畅。在没有应用持续集成之前，传统的开发模式是项目一开始就划分模块，每个开发人员分别负责一个模块，等所有的代码都开发完成之后再集成到一起提交给测试人员，随着软件技术队的发展，软件已经不能简单地通过划分模块的方式来开发，需要项目内部相互协作，划分模块这种传统的模式的弊端也越来越明显。由于很多bug在项目早期的设计、编码阶段就引入，到最后集成测试时才发现问题，开发人员需要花费大量的时间来定位bug，加上软件的复杂性，bug的定位就更难了，甚至出现不得不调整底层架构的情况。这种情况的发生不仅仅对测试进度造成影响，而且会拖长整个项目周期。而持续集成可以有效解决软件开发过程中的许多问题，在集成测试阶段之前就帮助开发人员发现问题，从而可以有效的确保软件质量，减小项目的风险，使软件开发团队从容的面对各种变化。持续集成报告中可以体现目前项目进度，哪部分需要已经实现，哪些代码已经通过自动化测试，代码质量如何，让开发团队和项目组了解项目的真实状况。持续集成的价值有：1易于定位错误。某一次集成失败了，说明新加的代码或修改的代码引起了错误，很容易就可以知道谁负责的代码出了问题，可以直接找相关人员来进行讨论，分析。2及早在项目里取得系统级成果。每次集成产生的版本都是一个可用的版本。3改善对进度的控制。每次持续集成报告中可以体现目前项目进度，哪部分需求已实现，哪些还没实现。4改善客户关系。可以非常明确的给演示项目进度（理由如上）5更加充分地测试系统中的各个单元。每日构建和测试相结合带来的好处6能在更短的时间里构建整个系统7有助于项目的开发数据的收集8与其他工具结合的持续代码质量改进。如与checkstyle，PMD、Findbugs等9与测试工具或框架结合的持续测试。如LoadRunner等10便于code review。每个build与前一个build之间有什么改动，针对这些改动可以有效的实现code review

1.4 持续集成流程图

持续集成（Continuous Integration，CI）是一个长期而又敏捷的过程，在核心的CI可以分为两大类，一类是产品级别的持续集成，产品级别的持续集成在发布日做到日构建。另一类也就是本文需重要描述的项目级别的持续集成。项目级别CI贯穿整个项目周期，从项目的FRD到发布后的跟进。下图是项目级别的持续集成的流程图，主要介绍项目使用CI的流程。

CI的介入是从立项的时候开始，前期是沟通和方案的定制，然后就是具体策略的执行，这里需要说明一下，CI不是独立存在的个体，他会与测试范围界定、缺陷分析等紧紧结合。当拿到一个项目时，应该怎么做，在流程图中已经说明了一切，首先是要做项目评估，如果项目适合做CI，然后就可以和项目组沟通，达成一直需指定方案计划和资源评估方案，最后进行具体方案的实施。

图中节点说明：

项目评估：

当我们参与一个项目的时候，需要评估下该项目是否适合做项目级别的持续集成，不是什么项目都可以做持续集成的。根据业界的经验，如何项目周期短，迭代次数少，这类的项目就不适合做持续集成，但还是要根据项目的特点进行评估。

沟通：

这是非常重要的一点，只有团队达成一致，才能将CI持续下去，我们在达成一直的基础上做约定和计划，如果在沟通的过程中无法达成一致，那么个人建议不要进行CI，当然也要去分析为什么没有达成一致。

计划约定与资源评估：

在沟通达成一致的基础上做出计划约定和资源评估。

持续集成实施：

在沟通、计划、约定的基础上我们就可以运用工具和策略对起进行实施，具体的工具和实施在后面的章节会做说明。

2 持续集成方案与策略

在前面介绍了项目级别持续集成的流程，四个节点（项目评估、沟通、计划与方案定制、持续集成实施）都非常的重要，项目评估、沟通、计划与方案定制属于前期的过程，也是基础。本章重点介绍持续集成实施中持续集成的方案与策略、量化标准以及数据的采集。

2.1 持续集成策略

持续集成的实施肯定缺少不了策略，但我们应该使用什么样的集成策略呢？如下图所示：

Jenkins + Pipeline 构建流水线发布

利用Jenkins的Pipeline配置发布流水线

参考： https://jenkins.io/doc/pipeline/tour/deployment/

新建一个名为pipeline-loop的 pipeline项目，然后配置，关键配置如下：

生成pipeline可以用的git连接（通过此链接，从私有gitlab拉取代码）

Pipeline生成： https://jenkins.aniu.so/view/Pipeline/job/pipeline-loop/pipeline-syntax/

pipeline-syntax

生成的pipeline代码如下，后面配置会用到：

配置pipeline-loop项目

配置完成保存，然后build此项目，查看结果如下：

持续集成的策略是采用技术手段为CI提供技术依据，做一个好的持续的项目最核心的是良好的单元测试编码，集成测试编码、系统测试编码、web ui层自动化等不同level的自动化能力，安装核心系统目前的情况来讲，有些条件并不成熟。但我们可以反其道而行之，以项目持续集成为基础，来推动某些条件（如单元测试、代码规范）的良性循环，形成量的积累，使得持续集成条件逐步走上正轨。

2.2 单元测试集成

单元测试是持续集成中非常重要的组成部分。目前我们软件质量部产品线的单元测试可以说是几乎处于无的状态。目的与价值单元测试（模块测试）是开发者编写的一小段代码，用于检验被测代码是否正确。通常而言，一个单元测试是用于判断某个特定条件或场景下某个函数的行为是否按照预期结果进行。单元测试与其他测试不同，单元测试可看作是编码工作的一部分，应该由程序员完成（TDD），也就是说，经过了单元测试的代码才是已完成的代码，提交产品代码时也要同时提交测试代码。持续集成中集成单元测试，每次迭代提交都保证单元测试的质量，那么产品的质量在一定程度上都得以保证。所以单元测试在持续集成过程中是测试件中非常重要的组成部分。不可缺少，这也是CI过程要单元测试集成的目的和意义。

2.3 单元测试策略

集成测试项目中对单元测试策略采用如下：1参与单元测试case设计开发人员或测试人员进行单元测试编码，测试设计人员参与case设计，因为我们设计case的角度和开发人员是不一样的，测试人员的设计会更加全面。2单元测试case的review要进行单元测试case的review，如果发现不合适的case则要进行修订。以保证单元测试的质量。3单元测试的用例评审（单元测试完成阶段）与项目组成员或资深人员一起参与单元测试用例的评审，对不合适的用例需进行修改。在持续集成过程中，如果发现单元测试的failed趋势上升或failed达到某一标准时，需和开发人员沟通并修订bug，从而保证每次迭代产品的质量。

2.4 适用范围和阶段

单元测试适合在开发人员进行单元测试编码阶段，一旦单元测试编码完成，上述单元测试的测试都可以适用，贯穿于整个项目周期。

2.5 工具

既然有持续集成，那我们就需要用到一些持续集成的工具和平台去分析每次的构建结果，在持续集成平台（hudson）中集成了单元测试覆盖率统计工具。参考后续内容。

2.6 量化指标

使用单元测试策略中我们会采集到一些数据指标，

3 接口测试集成

接口测试类似于单元测试，是分层自动化的重要组成部分，介于黑盒测试与白盒测试之间，在了解系统设计与接口定义对前提下，就可以在适当的时候运用mock来进行接口测试。

3.1 目的与价值

接口测试是质量的保证和效能的提升，所谓质量保证，就是深入到代码的底层，可以对接口进行直接的参数注入，查看其返回结果，让我们知道底层到底发生了什么。所谓效能的提升，就是程序的速度远比手工的速度快，几分钟就可以跑完上百个用例。接口测试不但可以提高测试效率，也不需要投入过多的精力去熟悉代码逻辑，而且可以借助单元测试技术实现持续集成和每日构建。

3.2 接口测试策略

本文采用的接口测试主要是对系统提供的服务接口进行所有接口的覆盖和集成，在覆盖的过程中进行以业务为导向的codeReview。在持续集成运行的过程中发现bug，需与开发人员沟通后修订bug，从而保证产品的质量。起测试方案如下：1新增的接口进行case覆盖和集成2修改的接口进行case覆盖和集成3保证已有接口的正确

3.3 适用范围和阶段

接口测试和单元测试一样，贯穿整个项目的周期。1需求了解阶段：了解项目中接口的功能，接口的输入输出参数及返回值，根据项目的情况决定是否做接口测试2设计阶段：了解接口的实现，并与开发沟通确定接口以怎么样的形式进行暴露，从少先队哪一层暴露。3编码阶段：脚本编写、数据准备、调试4测试阶段：-接口参数完成和提交测试前，主要个工作就是：运行接口测试脚本进行测试，根据测试的结果与开发逐一过用例，以确定是代码问题还是数据问题，直至所有的case均跑通。-测试阶段和分支回归阶段，利用集成测试平台完成该接口的测试和部分的分支回归工作，检查测试结果-发布回归，利用持续集成平台检查测试结果

4 发布会

接口参数若有变化应及时维护脚本和数据

持续集成保证底层的质量3.4 工具

接口测试涉及的工具主要是接口测试的开发和持续集成平台。

开发工具例如eclipse

持续集成测试平台hudson的配置和运行4 UI 测试集成

4.1 目的和价值

UI自动化测试是通过直接操作指定的浏览器，对浏览器中的页面对象、元素进行操作，完全模拟手工测试过程。项目中运行UI自动化测试的一个目的就是期望能利用自动化替代手工测试提升测试效率，通常在分支回归阶段使用，减少回归投入时间；另一个目的是为了产品级UI自动化测试做基础建设。产品级UI自动化测试在每日发布的回归测试中使用，不仅能扩大回归范围，而且能帮我杜绝重要故障，保证产品重要业务流程的正确性。2 UI测试集成策略集成测试项目中对UI测试的策略采用如下：1可行性分析及需求提取：测试负责人评估项目是否适合UI自动化覆盖，并确认UI自动化覆盖范围。2计划安排：测试负责人平台自动化脚本开发工作量，并且在测试计划中加入

软件开发周期中需要一些可以帮助开发者提升速度的自动化工具。其中工具最重要的目的是促进软件项目的持续集成与交付。通过CI/CD工具，开发团队可以保持软件更新并将其迅速的投入实践中。

Jenkins是最著名的CI/CD系统工具，且能迅速的成为开发引擎，管理开发方面。Jenkins为插件开发提供便利，为扩展版本控制系统提供功能且为IBM提供支持。 由Sun Microsystems分离出来的Hudson项目首次推出Jenkins，其最新版本为2，提高可用性与安全性。

但是当涉及持续集成与持续交付时，Jenkins并不是唯一的选择。 CircleCI,、GitLab和 JetBrains 等公司也为开发者提供可用的CI/CD工具。

Atlassian Bamboo

Atlassian Bamboo提供丰富的功能，从构建与部署Docker Container在Amazon Web Services运行应用程序。专门的代理可被用于热修复和关键构建。可扩展性一直被视为Jenkins的眼中钉，在这里，Appfire的CEO Randall Ward，Atlassian商业合作伙伴提供附件组件和服务，提高Bamboo优势。

Atlassian确实提出了可扩展性，同时Jenkins用户曾发现Jenkins工具有“主要性能障碍”。Bamboo通过轮询代理和扩展代理功能。Appfire使用Bamboo作为瑞士军刀，与第三方附加组件集成测试，以及部署代码。

Bamboo功能代码显而易见，确保用户从之前最新的部署中查看完整的代码更改。它集成其他的Atlassian产品，包括Bitbucket Git代码管理解决方案、Jira项目管理解决方案和HipChat团队聊天应用程序。

CircleCI

CircleCI也强调了扩展性，除了它能测试一切，对移动应用程序进行Jasmin单元测试。CircleCI帮助开发者带来Docker文件到产品中。

CircleCI提供了一个编排层和一个工作流工具，可自动化代码更改且将代码推到数据中心。始于2011年，CircleCI开始作为多组织Saas选择。它是Jenkins的替代，用户无须管理自己的服务器，Ruby、Python和AJAX应用程序是它的强项。它现在可以在防火墙外部署，与Jenkins相反，它是开源的且是一个企业解决方案。CircleCI可扩展超出Jenkins所能处理的，其配置是在代码中编写的而不是在服务器中完成的。

Eclipse Hudson

Jenkins的前身，在Oracle移交项目的五年前Hudson是Eclipse Foundation管理的。Oracle继承了Hudson当其在2010年收购了Sun Microsystems，但Jenkins开发者并未在Oracle项目方向上取得一致。最新的更新是在2月，Hudson是用Java编写且运行在servlet容器上如Apache Tomcat。它可以使用版本控制工具如Git和Subversion。

“在Hudson团队中我们致力于加强Hudson在一个已开始的基础上，重点创建Hudson一个合适的平台为持续交付以及持续集成,“Eclipse的一位代表说。”因此,您将看到工具的新功能，特别涉及大型企业在规模和复杂的构建管道使用需求Hudson。”

根据Eclipse的一个案例研究显示，Hudson用户Cleo提供了业务集成软件和服务，评估Jenkins代替Hudson因为Jenkins维护大多数Hudson插件。“我们放弃了这个想法后，Jenkins的核心功能是比Hudson的更加不可靠,”Cleo发布工程师Stuart Lorber表示。

GitLab CI

在可用的SaaS或防火墙外，开源GitLab CI可以在任何平台上执行且支持语言，包括Unix、Windows,OS x。用户可以自动向上和向下扩展虚拟机进行即时处理和最小化。其他功能包括多语言支持、实时记录、每阶段管道定义多个作业和Docker支持，用于测试和构建Docker图像。另外可扩展性也是一个优势。

GitLab CI是GitLab code-hosting平台的一部分，旨在为持续集成提供简单的设置。设置CI曾经是乏味的,我们想让它非常简单。GitLab CI并不需要大量的管理，测试被执行在GitLab Runner中，用Go编写且提供多平台、多语言功能。

因为GitLab CI与GitLab集成，用户不需要建立新的项目。用户添加一个文件来描述你想要如何测试库。

JetBrains TeamCity

JetBrains TeamCity CI/CD服务器集成工具如Apache Maven创建管理和JetBrain自己的YouTrack问题追踪工具。我们提供完整的体验与内置的功能插件。

TeamCity 不是开源的，有一个Web界面和管理功能。

该平台有IDE插件适用于Eclipse、Microsoft Visual Studio、和 JetBrains IntelliJ。还提供动态测试报告。TeamCity是一个产品且已存在10年。由JetBrains衍生出并进化为很成熟的产品。

ThoughtWorks GoCD

ThoughtWorks GoCD是一个开源的持续交付系统，它提供了一个“材料清单”部署。代理网格同时通过管道和版本提供并行处理，模板允许重用配置管道。它支持CD，开箱即用，无须安装其他的插件。

GoCD与Jenkins不同之处在于它是部署管道以及简化持续交付，GoCD可被安装或建立在云上。

ThoughtWorks Snap

ThoughtWorks Snap提供基于云的持续集成和交付的功能。Snap在云计算中完全是人来操作的，它是面向用户“无须任何基础设施”。托管部署可以被设置在云平台中，包括GitHub、Amzaon Web Services、DigitalOcean和Heroku。合并请求被测试以确保其完全合并。

Snap在GitHub上是免费使用公共存储，其中有一个负载使用私有存储。近期，Docker支持增加到Snap，Docker的图片通过软件交付和部署可被使用。

Jenkins是一个流行的持续集成框架，可以在我们提交项目的时候自动测试、运行和部署项目。虽然Jenkins使用Java编写，但是由于Jenkins支持多种语言的项目，所以现在很多公司都是用Jenkins来进行项目的持续集成。

下载和安装

Linux安装

首先第一步就是下载和安装Jenkins，我们可以到官网的下载页面来下载。该页面列出了常见的Linux系统、MacOS和Windows的安装包。当然其实如果是Linux的话，不一定必须从官网下载，如果Linux软件仓库中有Jenkins的软件包，也可以直接用对应的包管理工具安装。

例如，对于ArchLinux系统来说，可以用下面的命令安装Jenkins。

pacman -S jenkins

安装完成之后，使用systemd启动Jenkins。启动之后，可以访问浏览器的localhost:8090

来访问Jenkins。

启动Jenkinssudo systemctl start jenkins# 让Jenkins开机自启sudo systemctl start jenkins

对于其他Linux系统，参考相关文档来了解如何安装。

Windows安装

Jenkins也支持Windows操作系统，直接在上面的官网下载链接中找到Windows系统对应的项目即可。这是一个MSI安装包，我们可以和普通程序一样安装。安装完成之后会自动打开浏览器的localhost:8080

页面进入Jenkins。

Jenkins会以服务的方式运行在Windows系统中，不需要的时候可以关闭Jenkins服务。

Docker安装

Docker作为一种非常方便的部署项目的方式，Jenkins自然也支持了。使用下面的命令就可以获取Jenkins。

docker pull jenkins

下载完成之后，使用下面的命令启动Jenkins镜像。

docker run -p 8080:8080 -p 50000:50000 jenkins

然后就可以在浏览器的localhost:8080

端口访问了。

使用Jenkins

初始化

第一次打开Jenkins的时候需要输入Jenkins的安全密码。在网页上会给出改密码的位置，如果是Windows系统，应该在类似D:\Program Files (x86)\Jenkins\secrets\initialAdminPassword

的路径下。

Linux

然后需要安装Jenkins插件，可以直接安装推荐的插件，也可以自己手动选择要安装的插件。

安装插件

然后就是创建用户了。这一步我没有截图。

新建项目

创建完用户之后，就可以新建项目了。一般情况下，选择第一种自由风格的项目即可。

新建项目

之后输入各种项目信息就行了，其中比较注意的一点就是源代码管理这里了。Jenkins需要一个项目地址来拉取项目代码。

配置项目

配置完毕之后就可以构建项目了。详细的配置和使用可以参考相应文档。