詹金斯搭建_詹金斯用户大会巴黎

詹金斯搭建

我很荣幸能协助2012年巴黎詹金斯用户大会，以下是我从不同的谈话中获得的一些笔记。 考虑到我是法语，不习惯于听很多英语

川口浩辅的欢迎辞。

首先介绍一下历史。 詹金斯（Jenkins）无辜地开始了，因为Kohsuke破坏了一个建筑太多。 在2004年，为了监视其构建的成功/失败，他创建了两个小shell脚本。 这个想法诞生了，很快，他使用JavaEE堆栈构建了即将成为现实的Jenkins（以前称为Hudson）。 自成立以来，Jenkins一直沿用至今的一些文化原则：每周发布周期，基于插件的体系结构，低障碍入门和向后兼容策略。

从使用角度来看，有很多大公司都在使用Jenkins，而且奇怪的是，欧洲是一个庞大的用户群。 如今，有535个可用的插件，并且增长很快。 跟踪错误和错误修正的演变，并不断发展（对哈德森的嘲讽也是如此，后者的身影在叉子之后就断裂了）。

最后，对我而言，最重要的部分是新功能。 大多数都集中在UI和可用性上（直率地说，还有改进的空间）：

• 现在，您无需重新启动即可安装。 无需等待所有工作完成即可获得新功能！
• 保存按钮位于页面底部。 当您安装了许多功能后，该页面很长一段时间才能滚动到该死的按钮...
• 现在，保存本身由AJAX处理，并在顶部显示一条消息：您留在页面上
• 您会在每个页面的顶部看到一个面包屑
• 从这个breacrumb（以及从其他地方），您可以获得上下文菜单。 此菜单提供了一种导航到作业配置页面各部分的方法（并且您安装的插件越多，则存在的部分就越多）
• 最后，用户界面现在使用Twitter Bootstrap和某些客户端JavaScript库的更高版本，这些新功能为表带来了一些新增的可用性功能（例如，将鼠标悬停在“删除”按钮上时，可以显示将删除哪个块的功能）

Nicolas de Loof和Matthieu Ancelin的相约

詹金斯（Jenkins）是类固醇激素

现在，詹金斯（Jenkins）被用来做所有连续的事情：集成，交付（可以部署到生产中）和部署（部署到生产中）。 为了使生产自动化，需要从SCM到生产的开发流程。 幼稚地进行此过程可能需要数小时或数天：您必须重新考虑管道以使其简化：

• 将二进制文件从一个作业传递到另一个作业（无需在每个步骤中重建软件包）
• 并行任务
• 发生故障时进行清理
• 在不可用时管理资源

如果您想在Jenkins中做到这一点，可以使用一些Jenkins功能和插件（Naginator，Promotion等）。 如果您要管理数十个项目构建，显然这不是可行的方法，因为您会及早忘记正在做的事情。 由于没有工作流构建过程的集中定义，因此无法简单概述每个管道。 此外，所有插件和作业之间可能会产生副作用，并且交互更糟。

这些问题的答案是专用流程插件Build Flow。 Build Flow提供了一种新型的工作，让我们描述DSL中的工作链（ build ， guard ， rescue ， retry ， parallel等）。 控制台输出显示作业的工作流程。 奇怪的是，该演示工作正常🙂最重要的是，尝试提供有序的已运行作业显示，将较旧的作业放在顶部，将并行的作业放在同一水平线上。 坦率地说，在这方面需要做很多改进，但是谈话后的讨论使我确信它正在发展。

尼古拉斯当然知道如何吸引观众！ 否则，当您在工作之间有很多联系时，我不知道该考虑什么插件。

使用JenkinsCI在构建到开发流程中建立信任

声明：JFrog为所有Jenkins工件提供了一个存储库管理器，现在用于快照，即将发布。

发言人来自JFrog：该示例未使用Maven，但使用了Gradle（叹息）。 有趣的一点是，使用Graven插件，您可以覆盖Gradle脚本内部内容的配置，包括部署存储库，以便您可以在构建环境中而不是脚本内部管理此配置。 我认为这是改进阶梯的一个不错的步骤。

注意事项：

• Artifactory插件的一个很好的方面是您可以检查依赖项的许可证，以在发生不良情况时（例如，当GPL依赖项蔓延到您的内部版本中时）提醒您。
• Maven逐个模块地部署模块，Gradle也是如此，而Artifactory确实如此，它仅在所有模块构建成功后才发布。
• 当工件被部署在其中时，Artifactory会计算所有工件的元数据：它会忽略Maven发送的元数据（它存在信任问题）。 此外，还有关于Nexus文件系统策略的评论（而Artifactory使用数据库-Jackrabbit，如果我记得很好的话）。 例如，当从文件系统复制到文件系统时，面对Gb规模时，它的性能可能确实很差。

发言者的意见是：

发布不是关于重新编译，而是关于重命名，更改元数据和更改依赖关系。

我不确定我是否同意。

坦白说，最后，我并没有引起太多关注，关于Artifactory本身的讨论很多，而关于Jenkins Artifactory集成的讨论还不够。 我想这就是让JFrog成为赞助商的代价。 这并不是说我对Artifactory有所反对（这是我的第一台存储服务器，当时的UI提前了数年），只是我希望有其他事情。

Jenkins在Olivier Lamy的Apache软件基金会中

Apache Foundation有大约100个顶级项目和2500个提交者，因此CI非常重要。 使用了Continum，BuildBot和Jenkins，但使用最多的是Jenkins。 有两个构建实例，一个用于常规构建，另一个用于Sonar构建，出于安全原因。

第一个在群集于20个节点上的Apache Tomcat 6上运行，并托管约750个作业。 构建某些项目需要几个小时（例如Lucene和Hadoop）。 直接在这里检查。

午餐

是的，怪胎在吃东西...

• Scripter插件
• 关于使用Groovy管理Jenkins的有无建议的反馈。 完整的帖子可以在这里找到 。
• 企业模板

感谢所有勇敢的演讲者，他们在我们吃午饭时试图引起我们的注意。

Benoit Moussaud与Jenkins进行的高级连续部署

会话首先提醒什么是CI：编译，测试和打包。 通常，我们会喜欢部署，以便测试部署过程并在目标平台上测试已部署的应用程序。 这就是“持续部署”是什么：将部署包含在构建本身中。

这将允许我们以升序通过：

• 烟雾测试
• 功能测试
• 性能测试

这个想法是在开发周期上同步部署周期。 开发人员必须满足的两个要求是：

对于该应用程序的每个版本，我将提供一个包含所有工件和资源定义的单个包定义。 程序包应独立于目标环境。

这本质上意味着一件事： 出厂的工件应该是自给自足的 ， 例如 JDBC驱动程序，数据源等。 有许多挑战需要克服：应用程序服务器的详细信息，安全的凭证管理等。XebiaLabs提供了一个名为DeployIt的解决方案。 当然，Jenkins有一个插件可以实现这一目标。

在Jenkins中，您组装构成软件包的内容（Web应用程序，数据源，SQL脚本，测试软件包等），然后选择要部署到的环境。 詹金斯负责调度和启动。 最后，部署本身由DeployIt管理：它是通过插件完成的，每个插件专用于一个任务（部署，复制，传递SQL等）。

对于访问控制，凭据安全地存储在DeployIt内部，因此无需在每个平台上进行身份管理。

最后，DeployIt从JavaEE环境开始，但现在包括PHP和.Net。

总而言之，这是一次非常有趣的演讲，引发了许多问题，例如如何在某些客户中获得产品，但是值得研究那些胸襟开阔或敏捷的客户。

詹金斯（Jenkins）在Sfeir by Bruno Guedes

Bruno提供以下案例研究：为了从头开始实现软件伪造，决定在8月底做出，服务应在9月1日开放。 成功解决方案的组成部分是什么？ 关键是云，它带来以下好处/关键点：

效益	临界点
No need to order the machines	Service-Level agreeement
Skip the time to setup	Extensibility
Cost reduction	Location which should be as near as possible to avoid network latency
Instant development	Security providers
Quick shipping
And still evolutive
No need to order the machines

在给定现有项目的情况下，遵循CloudBees平台使用的演示。 CloudBees提供了一个“云化的”伪造（通过Jenkins）和一个“云化的”应用程序服务器（通过Tomcat或JBoss）。

尽管没有太多的演示效果，并且最终将应用程序部署到云中并可以在云中使用，但奇怪的是，我仍然对模型不满意。 也许我头脑太狭（（或年龄太大）？ 只有未来会证明...

Jenkins入门，Harpreet Singh，Nicolas De Loof和Stephen Connolly

我不想在竞争性会议上听到有关ClearCase的消息，所以我更喜欢听到有关基础知识的信息，以确保不会错过任何内容。 我实际了解到的一些事实：

• Jenkins具有内置的群集管理。 优良作法是使用主节点管理配置，但委派从属节点上的构建
• 默认情况下，执行程序的数量应设置为CPU内核的数量
• 项目的描述字段接受HTML
• CVS提交单位是文件（不是一堆文件），因此您最好配置作业的静默期，否则将在可怜的詹金斯身上发起一次提交风暴
• 某些插件（包括Maven插件）与Jenkins版本绑定在一起。 不要更新它们，否则您将（非常）抱歉。

有几个最佳做法需要提及：

• 使用可记住的网址
• 与其他应用程序共享端口80
• 使用虚拟主机来区分多个应用程序，而不是上下文路径：万一必须更改基础架构，它会变得更加灵活
• 为磁盘使用量增长做准备，或者您以后会后悔：针对最坏的情况（或最好的情况，根据您的观点进行规划-这意味着Jenkins将成为您企业文化的一部分）

由于我无法创建Cloudbees帐户，剩下的课程对我来说都是lost。🙁最糟糕的演示效果：对不起，伙计们。

Sebastian Bergmann将PHP项目与Jenkins集成

也许很奇怪，但是我的兴趣在于更好的构建，并且由于我目前的公司正在开发PHP应用程序，所以我认为这次演讲可能很有趣。

会议以关于PHP世界中CI的简短故事开始。 它与Java相似，带有CruiseControl。 CruiseControl的最大问题是它非常单一：您必须获取源代码，对其进行hack和构建。 最终，PHP世界中的这种方法被phpUnderControl使用。 而且，似乎CruiseControl社区对PHP开发人员并不那么友好。

Hudson建立在插件架构之上，因此扩展起来要容易得多（社区更好...）。 有许多工具可用于控制PHP的质量。 与Jenkins插件相关联，他们就可以完成工作。

• PHP_CodeSniffer是用于PHP，JavaScript和CSS文件的静态代码分析工具，并输出Checkstyle XML文件
• Checkstyle插件可报告以前的结果
• 三叶草PHP
• PHPUnit
• PHPCPD
• PHP_Depend是JDepend的端口，并输出JDepend XML文件
• JDepend插件报告以前的结果
• PHP Mess Detector（PHPPMD）是PHPDepend的衍生产品，旨在成为PHP世界的PMD
• PMD插件可报告以前的结果
• 违规插件用于集中汇总CodeSniffer，CPD和PMD的结果
• PHP_CodeBrowser生成可浏览PHP代码表示，突出显示CodeSniffer或PMD发现的违规
• PHPLOC，一种用于测量项目中简单指标（代码行，类等）的工具
• 绘制Jenkins插件以按以前的插件绘制指标
• Jenkins PHP提供了Ant脚本模板和PHP项目的Jenkins工作

当时我不得不走了。 由于没有PHP项目的实际经验，因此该材料可以使我工作几个月。

结论

2012年巴黎詹金斯会议取得了巨大的成功，我发现大多数会议都非常有趣。

翻译自: https://blog.frankel.ch/jenkins-users-conference-paris/

詹金斯搭建