静态变量持续性_持续交付：静态分析

静态变量持续性

这是“连续交付”系列中的第三篇文章。 CI工具设置以Jenkins启动并运行结束&＃xff0c;等待我们使用它。 另一方面&＃xff0c;特拉维斯&＃xff08;Travis&＃xff09;被搁置一旁&＃xff0c;很快我们就会明白为什么。

在本文中&＃xff0c;我们将探讨静态分析&＃xff0c;这是我们在交付管道中应执行的第一类任务。 既然这是我们的出发点&＃xff0c;那么让我们简单地解释一下。

静态分析

静态程序分析是对没有实际执行程序的情况下执行的计算机软件的分析&＃xff08;对执行程序执行的分析称为动态分析&＃xff09;。

在我们的案例中&＃xff0c;我们将专注于Java和三种类型的分析&＃xff1a;

• Checkstyle &＃xff1a;查找违反编码约定的行为。
• Findbugs &＃xff1a;在已编译的Java代码中查找错误。
• PMD &＃xff1a;寻找Java源代码中的潜在问题。

即使我们在示例中使用Java&＃xff0c;同样的想法也适用于任何其他语言。 这三个工具都很有价值&＃xff0c;并且执行不同的功能&＃xff08;即使存在重叠的区域&＃xff09;。 组合并正确设置它们之后&＃xff0c;它们可以对代码提供良好的初始评估&＃xff0c;这些代码可用于确定是否值得继续进行其余的传递管道。 请记住&＃xff0c;我们失败的速度越快&＃xff0c;我们就会知道如何解决。 因此&＃xff0c;静态分析通常是第一道防线。 所有流行的IDE都支持静态分析&＃xff0c;因此在很多情况下&＃xff0c;甚至在进入Jenkins和Travis之类的工具之前&＃xff0c;都可以检测到问题。

在较大的项目中&＃xff0c;您可能需要使用SonarQube 。 出于本文的目的&＃xff0c;我们决定在没有Sonar的情况下寻求简单和极简的解决方案。

Checkstyle是一种开发工具&＃xff0c;旨在帮助程序员编写遵守编码准则的Java代码。

Checkstyle是高度可配置的&＃xff0c;并且可以使其支持几乎所有编码标准。 提供了一个示例配置文件&＃xff0c;该文件支持Sun Code Conventions。 同样&＃xff0c;还为其他众所周知的约定提供了其他示例配置文件。

我的经验是&＃xff0c;在大多数情况下&＃xff0c;需要自定义配置文件。 预先定义的规则通常是一个过分的杀伤力&＃xff0c;在某些情况下可能会导致生产力下降而没有任何实际收益。 但是&＃xff0c;一旦团队成立并开始使用最适合的&＃xff08;定制&＃xff09;样式&＃xff08;通常是对配置进行更改的反复试验类型的结果&＃xff09;&＃xff0c;则代码可读性明显提高。 关于编码标准&＃xff0c;位于“同一页上”使每个人在阅读和编写代码时都更加自在。

Findbugs尝试查找可能导致bug的“已知问题”。 与我学会了爱与恨的checkstyle不同&＃xff0c;如果有的话&＃xff0c;checkstyle需要很多摆弄&＃xff0c;而Findbugs产生的警告几乎总是可能的缺陷&＃xff0c;在某种程度上可能是有害的。 Findbugs的优点是它通常会发现真正的缺陷并且误报率很低。 不利的一面是&＃xff0c;它需要编译后的代码。 理想情况下&＃xff0c;应该在实际编译之前先进行静态分析&＃xff0c;并且Findbugs迫使我们创建类文件以运行它。

PMD在Java源代码中查找潜在的问题&＃xff0c;可能的错误&＃xff0c;未使用的和次优的代码以及过于复杂的表达式。 它发现的实际问题的数量通常比Findbugs的数量少。 另一方面&＃xff0c;它可以发现与最佳实施不当&＃xff08;或运气不佳&＃xff09;相关的问题。

詹金斯的职位设置

现在该开始在我们的交付管道中实施静态分析了。 本文中的示例将使用TechnologyConversationsCD存储库中的源代码。 Src目录包含从网球比赛kata复制的源代码。 为了使我们的Jenkins作业正常工作&＃xff0c;我们必须从存储库中提取代码&＃xff0c;运行静态分析并发布结果。

所有执行将由Gradle执行。 本文将不会详细介绍Gradle的工作原理&＃xff0c;也不会介绍为什么我们选择使用Ant&＃xff0c;Maven和其他构建工具。 有关更多详细信息&＃xff0c;请访问Gradle网站 。

让我们从安装缺少的程序和几个Jenkins插件开始。

上一篇文章CI Tools设置中创建的Dockerfile将需要进行修改。 我们将从在容器中添加GIT客户端和Gradle开始。

[Dockerfile]

# GIT
RUN apt-get install -q -y git# Gradle
ADD https://services.gradle.org/distributions/gradle-1.12-all.zip /opt/gradle-1.12-all.zip
RUN unzip /opt/gradle-1.12-all.zip -d /opt/
ENV GRADLE_HOME /opt/gradle-1.12
ENV PATH $PATH:$GRADLE_HOME/bin

完整的源代码可以在我们的GitHub存储库中的Dockerfile中找到。

一旦安装了所有软件&＃xff08;GIT&＃xff0c;Gradle&＃xff0c;Jenkins等&＃xff09;&＃xff0c;我们将需要添加缺少的插件。 到此时&＃xff0c;您应该已经熟悉Docker。

[Dockerfile]

# Jenkins: Plugins
ADD https://updates.jenkins-ci.org/latest/git.hpi /jenkins/plugins/git.hpi
ADD https://updates.jenkins-ci.org/latest/gradle.hpi /jenkins/plugins/gradle.hpi
ADD https://updates.jenkins-ci.org/latest/analysis-collector.hpi /jenkins/plugins/analysis-collector.hpi
ADD https://updates.jenkins-ci.org/latest/checkstyle.hpi /jenkins/plugins/checkstyle.hpi
ADD https://updates.jenkins-ci.org/latest/findbugs.hpi /jenkins/plugins/findbugs.hpi
ADD https://updates.jenkins-ci.org/latest/pmd.hpi /jenkins/plugins/pmd.hpi

完整的源代码可以在我们的GitHub存储库中的Dockerfile中找到。

为了简洁起见&＃xff0c;本文中未对Dockerfile进行其他一些小的更改。 请从仓库中获取完整副本。

将Dockerfile推送到GitHub并由Docker编译后&＃xff0c;我们的新容器就可以从Vagrantfile或手动运行中使用。

要重新加载我们的Vagrant VM&＃xff0c;请从Vagrantfile所在的目录中运行以下命令&＃xff1a;

[Vagrantfile]

vagrant reload --provision

您可以通过在喜欢的浏览器中打开http&＃xff1a;// localhost&＃xff1a;4567来查看Jenkins服务器。 我们已经下载并安装了插件&＃xff08;更多信息可以在http&＃xff1a;// localhost&＃xff1a;4567 / pluginManager / installed中找到 &＃xff09;。 与服务器上设置的GIT和Gradle一起&＃xff0c;我们准备开始创建我们的第一份工作。

工作

创建新的詹金斯工作很容易。 左侧菜单中的第一项是“新项”。 在“项目名称”中键入“ myFirstJob”&＃xff0c;选择“构建自由样式的软件项目”&＃xff0c;然后单击“确定”按钮。 在詹金斯&＃xff08;Jenkins&＃xff09;的工作中&＃xff0c;一个人可以完成的任务数量是巨大的。 但是&＃xff0c;我们将仅专注于代码分析。 我们将执行以下操作&＃xff1a;

• 拉码
• 运行分析
• 发布结果

拉码

选择“ GIT”作为“源代码管理”&＃xff0c;然后添加您的存储库。 出于本练习的目的&＃xff0c;您可以使用我们的仓库&＃xff1a; https : //github.com/vfarcic/TechnologyConversationsCD.git 。

接下来&＃xff0c;我们需要设置触发器&＃xff0c;使詹金斯提取代码。 通常&＃xff0c;您将创建一个GitHub钩子&＃xff0c;该仓库钩子会在存储库内容更改时通知您的Jenkins实例。 但是&＃xff0c;我们将采用不同的方法并定期提取代码。 这种做法背后的原因是因为我们当前正在localhost上运行。 在生产中&＃xff0c;请使用挂钩而不是如下所述进行拉动。

在“ Build Triggers”的“ Pool SCM”部分中设置“ * * * * *”。 5 * s表示每小时的每一分钟或一周中的每一天的每一天。 调度语法与Linux cron中使用的语法非常相似。 Jenkins提供的解释对于大多数用户来说通常就足够了。

现在&＃xff0c;Jenkins每分钟都会拉动GitHub。 如果这些拉出之一检测到代码更改&＃xff0c;则此作业会将代码拉到工作区。 接下来&＃xff0c;我们将使用此代码进行操作。

运行Gradle任务

由于Gradle是我们选择的武器&＃xff0c;因此我们将使用它来进行静态分析。 要启用Checkstyle&＃xff0c;Findbugs和PMD分析&＃xff0c;我们要做的就是添加插件。 这是位于源代码根目录下的build.gradle文件的摘录&＃xff1a;

apply plugin: &＃39;checkstyle&＃39;
apply plugin: &＃39;findbugs&＃39;
apply plugin: &＃39;pmd&＃39;

完整的源代码可以在我们的GitHub存储库中的build.groovy中找到。

而已。 这三行创建了新的Gradle任务&＃xff0c;例如&＃xff1a;checkstyleMain&＃xff0c;checkstyleTest&＃xff0c;findbugsMain等。我们感兴趣的是任务“ check”。 它将运行所有静态分析任务。 目前&＃xff0c;它们包括上述内容。 只需放置新插件即可添加更多内容。

要从Jenkins运行Gradle任务&＃xff0c;请从“构建”部分的“添加构建步骤”列表中选择“调用Gradle脚本”。 由于我们已经确定&＃xff0c;我们唯一需要的任务就是“检查”&＃xff0c;这正是应该在“任务”字段中输入的内容。

发布分析结果

我们快到了。 剩下的就是发布结果&＃xff0c;以便可以轻松获得它们。

要发布Checkstyle结果&＃xff0c;请从“添加构建后操作”列表中选择“发布Checkstyle分析结果”。 “ Checkstyle结果”字段应具有
值“ build / reports / findbugs / *。xml”。 对于Findbugs和PMD&＃xff0c;应重复相同的设置。 查看“高级”按钮后面隐藏的选项&＃xff0c;尤其是“状态阈值”。 “高级”部分中最重要的选项可能是“始终运行”复选框。 没有它&＃xff0c;发布者仅在没有静态分析警告的情况下运行。

运行工作

现在我们已完成所有设置&＃xff0c;唯一缺少的是运行作业。 我们已经将作业设置为只要GIT存储库发生更改就可以运行。 詹金斯的工作将在我们下一次推动后立即进行。 如果还不够快&＃xff0c;您可以通过导航到作业并单击屏幕左侧的“立即构建”链接来运行任何作业。 新版本将开始。 完成后&＃xff0c;Checkstyle&＃xff0c;Findbugs和PMD报告将位于构建结果内。

Jenkins职位设置摘要

乍一看&＃xff0c;所有这些步骤似乎令人生畏。 但是&＃xff0c;通过一些实践&＃xff0c;整个过程应该不会超过15分钟。 我们做了以下工作&＃xff1a;

• 修改了Dockerfile以包括安装Gradle和GIT的说明。
• 修改了Dockerfile以下载所需的Jenkins插件。
• 重新加载了我们的Vagrant VM
• 创建了一个新的Jenkins作业&＃xff0c;该作业将代码从GIT存储库中提取出来&＃xff0c;从Gradle构建脚本中运行“检查”任务&＃xff0c;最后发布结果。

这仅仅是开始。 在我们迈向持续交付的道路上&＃xff0c;还有许多其他步骤和概念需要探索。 其中一些将在下一篇文章中进行探讨。 现在&＃xff0c;我们将重点转移到Travis上&＃xff0c;看看如何使用云解决方案来做同样的事情。

特拉维斯

不久您将看到&＃xff0c;Travis&＃xff08;至少是云版本&＃xff09;需要的工作量比Jenkins的本地实例少得多。 通常&＃xff0c;要使用Travis&＃xff08;除了已注册&＃xff09;&＃xff0c;我们要做的就是&＃xff1a;

• 从GitHub存储库中启用构建
• 使用说明创建.travis.yml文件

从GITHub存储库中启用构建

Travis仅适用于GIT存储库。 您可以分叉我们在本文中一直使用的那个。 如果您从未分叉过GITHub仓库&＃xff0c;请按照以下说明进行操作&＃xff1a;

• 转到TechnologyConversationsCD
• 单击页面右上角的“叉子”图标。

假设您已经登录&＃xff0c;要启用某些GITHub存储库的构建过程&＃xff0c;请单击您名称下的“帐户”。 接下来的屏幕应列出您拥有的所有存储库&＃xff0c;如果您分叉了CD存储库&＃xff0c;则它应该是列出的存储库。 打开它。

分叉的存储库本身已经带有.travis.yml。 完整文件很短。

[.travis.yml]

language: javabefore_install:- chmod &＃43;x gradlewenv:- TERM&＃61;dumbnotifications:email:- viktor&＃64;farcic.com

完整的源代码可以在我们的GitHub存储库中的.travis.yml中找到&＃xff08;以及您刚刚创建的源代码&＃xff09;。

您可能会注意到的第一件事是&＃xff0c;与詹金斯不同&＃xff0c;我们不需要告诉特拉维斯该怎么办。 独自解决它是足够聪明的。 我们只需要指定一些东西&＃xff0c;例如将使用的通知电子邮件。 作为一般规则&＃xff0c;特拉维斯要求我们指定非标准的东西&＃xff0c;那些他自己无法弄清楚的东西。 如果一个项目是使用某种标准完成的&＃xff08;就像我们正在使用的示例代码一样&＃xff09;&＃xff0c;Travis完全有能力知道该做什么。 在这种情况下&＃xff0c;除其他外&＃xff0c;它将以与詹金斯相同的方式运行Gradle任务“检查”。 如果构建过程的任何部分失败&＃xff0c;Travis将停止执行并通过电子邮件&＃xff08;或我们指定的任何其他通信方式&＃xff09;通知我们。

而已。 对示例代码进行静态分析以使其在Travis中工作几乎没有什么可做的。 仅需要简单的.travis.yml文件。 一大优势是配置文件与我们其余的代码存储在一起。 这大大简化了存储和维护。

Travis的主要缺点是&＃xff0c;唯一的结果&＃xff08;不会导致某些“ hacks”&＃xff09;是日志输出。 没有詹金斯&＃xff08;Jenkins&＃xff09;制作的报道。 这不一定是坏事。 持续集成&＃xff0c;部署和交付的总体思想是&＃xff0c;没有新闻是好消息。 如果没有失败&＃xff0c;请忽略它。 另一个重要因素是周期很短。 同时应该只有很少的故障&＃xff0c;应该优先解决的问题是在团队继续工作之前。 在大多数情况下&＃xff0c;通过执行这两项操作&＃xff08;仅针对失败和较短的周期采取措施&＃xff09;&＃xff0c;就不需要“花哨的”报告了。 但是&＃xff0c;要达到这一点可能会花费很多时间&＃xff0c;许多组织将要求您采取中间步骤&＃xff0c;生成报告……如果是这样&＃xff0c;詹金斯可能是更好的选择。 就我而言&＃xff0c;我同时使用了两者&＃xff0c;但是如果我只选择一个&＃xff0c;那就是特拉维斯。

其他工具

传统表明&＃xff0c;这是一个比较详细地比较詹金斯和特拉维斯的好时机。 我将其留给读者。 本系列中即将发表的文章将继续使用两者&＃xff0c;并不断进行比较。 现在&＃xff0c;我想介绍一些其他工具。

Drone.io是一个有趣的工具。 在某些方面&＃xff0c;它类似于Travis。 在另一些方面&＃xff0c;它倾向于詹金斯。 最好的例子是配置。

• Travis依赖于一个简单的文件来进行所有配置&＃xff0c;并且该文件是代码的一部分。
• Jenkins通过其插件系统提供了无限的可能性。 为此付出的代价可能是增加设置和管理所需的时间。
• Drone.io都不是。 没有像Travis那样的配置文件&＃xff0c;也没有像Jenkins那样的无限可能。 使用Drone.io Web GUI完成配置。 使用“像向导一样”的界面很容易&＃xff0c;但仍有一些不足之处。

Travis和Jenkins都提供了非常强大而又不同的方式来配置作业。 Drone.io使用了一个有趣的概念&＃xff0c;它仍然需要完善才能使其成为CI / CD工具清单的主要竞争者。 例如&＃xff0c;没有明显的方法在Java项目中使用Gradle。 一旦将其设置为Groovy&＃xff0c;它就会起作用。

很高兴看到Drone.io在接下来的几个月中取得进展。

BuildHive是许多基于云的CI服务之一。 它建立在詹金斯&＃xff08;Jenkins&＃xff09;之上。 想法本身非常有趣。 可以将云上的Jenkins转换为功能&＃xff0c;而不必担心维护本地服务器。 但是&＃xff0c;BuildHive减少了所有功能。 用户没有得到最喜欢的关于Jenkins的东西&＃xff08;插件和无尽的可能性&＃xff09;&＃xff0c;而回报却很少。 也许除了眼神之外&＃xff0c;它还有更多&＃xff0c;但对我而言&＃xff0c;这是非常令人失望的经历。

Circle与Travis一样容易上手。 选择仓库&＃xff0c;仅此而已。 生成已执行&＃xff0c;没有任何问题。 与travis一样&＃xff0c;可以使用位于存储库根目录中的circle.yml文件进行其他配置。 请查看本文代码所使用的circle.yml 。 作为一个附加选项&＃xff0c;有一个Web界面&＃xff0c;可进行调整而无需创建circle.yml文件。

我在本文使用的存储库上运行Circle时注意到的第一件事就是速度。 它比Travis快得多。 但是&＃xff0c;这本身并不能说明太多&＃xff0c;因为代码仅由两个类组成&＃xff0c;很少依赖。 因此&＃xff0c;我尝试了一个更大的大型项目&＃xff08;Scala&＃xff0c;Play&＃xff0c;AngularJS&＃xff0c;还有更多依赖项...&＃xff09;。 结果令人失望。 第一次跑步比特拉维斯慢得多。 就像困惑依赖关系一样&＃xff0c;它重复了几次相同的长时间提取依赖关系的过程&＃xff0c;与Play和SBT测试相混淆&＃xff0c;并且两次运行相同的设置&＃xff0c;等等。这是非常痛苦的经历&＃xff0c;直到29岁之后分钟&＃xff0c;大约比Travis慢5-7倍&＃xff08;同一过程通常需要4-6分钟左右&＃xff09;。 我只能假设Scala / Play组合不是Circle喜欢的。 但是&＃xff0c;不久之后&＃xff0c;Circle与我联系&＃xff0c;对其进行了解释&＃xff0c;并Swift修复了该问题。 从那时起&＃xff0c;项目的执行时间从29分钟减少到2-3分钟&＃xff0c;大约是Travis的一半。

另一个缺点是&＃xff0c;除了14天的试用期外&＃xff0c;与Travis一样&＃xff0c;OSS项目没有免费服务。

对于那些愿意付款的人&＃xff0c;Circle是Travis的绝佳替代品。 它使用相同的原理&＃xff0c;速度更快&＃xff0c;并且拥有真正强大的客户支持。

摘要

我们在Jenkins和Travis上都设置了静态分析。 当詹金斯&＃xff08;Jenkins&＃xff09;的插件和Web UI大放异彩时&＃xff0c;事实证明Travis的设置要容易得多。 两种工具都提供了功能强大&＃xff08;但又非常不同&＃xff09;的自定义作业方式。

下一篇文章将在“持续集成和交付”流程中提供更多详细信息。 我们列表的下一个是测试和代码覆盖率。

我们将Circle添加到现有工具集。 所有示例都将使用Jenkins&＃xff08;本地服务器&＃xff09;&＃xff0c;Travis&＃xff08;云&＃xff09;和Circle&＃xff08;云&＃xff09;完成。 如果您认为探索更多工具是个好主意&＃xff0c;请告诉我。

翻译自: https://www.javacodegeeks.com/2014/05/continuous-delivery-static-analysis.html

静态变量持续性