詹金斯搭建
我很荣幸能协助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/
詹金斯搭建