java 持续交付环境
重要要点
- 即使十年前Dave Farley和Jez Humble的经典著作《 持续交付 》问世，作者仍然看到许多组织都在为某些概念而苦苦挣扎。 事实是，实施持续交付（CD）很难。
- 作者参考Steve Smith的著作，认为CD主要是为客户提供价值，并且当稳定性和速度可以满足业务需求时，就可以实现持续交付。
- 通过专注于Java（作者日复一日使用的语言和平台），《 Continuous Delivery in Java》一书不仅涵盖了CD的目标，思维方式和实践，而且涵盖了实际的工具，库。 ，以及Java中的配置。
- 实施CD时，在实施CD时，请从Accelerate（由Nicole Forsgren等人撰写）一书中监视高绩效团队的关键指标，这些指标包括交货时间，部署频率，平均恢复时间（MTTR）和更改失败百分比。
- Java开发人员显然需要参与CD管道的设置和运行。 但是，期望开发团队控制交付管道的各个方面可能是压倒性的。
丹尼尔·布莱恩特（Daniel Bryant）和亚伯拉罕·马林·佩雷斯（AbrahamMarínPérez）撰写的《 Java的持续交付》一书于2018年底发行，距Dave Farley和Jez Humble最初的《持续交付》一书已经过去了十年，距Java首次公开发行也已有20多年了。
InfoQ与作者联系，以从他们的经验中更好地理解为什么需要一本专门针对Java和JVM生态系统的持续交付书。
InfoQ：《持续交付》一书问世近十年后，您为什么觉得有必要专门针对Java进行持续交付？
丹尼尔·布莱恩特（Daniel Bryant）和亚伯拉罕·马林·佩雷斯（AbrahamMarínPérez） ：尽管戴夫·法利（Dave Farley）和杰兹·汉布尔（Jez Humble）的经典《 持续交付》书是十年前问世的，但从我们的咨询经验来看，人们仍在为某些概念而苦苦挣扎。 事实是，连续交付很难。 但是，即使人们最终了解了这种做法的含义，我们仍然认为许多开发人员仍对如何最好地实施这种做法感到怀疑。 换句话说，我们注意到理论与实践之间存在差距。 我们渴望“站在巨人的肩膀上”，并在这一领域分享我们的实践经验。
通过关注编程人群的特定子集（Java开发人员），我们能够以更实际的方式谈论连续交付：使用实际的工具，库和设置。 诚然，我们选择的选项并不是唯一可能的选择，但是通过精心策划这一特殊的设置，我们可以帮助读者在着手持续交付的过程中一臂之力。
InfoQ：您希望读者从书中带走的主要收获是什么？
Bryant＆MarínPérez ：我们一直非常谨慎地传达的一个重要信息是，没有正确或错误的决定，只有或多或少的合适选择。 每个组织都是不同的，针对不同的需求会有不同的解决方案。 我们还渴望使可能不熟悉交付软件的配置或操作方面的Java开发人员能够识别关键指标，识别重要决策点，并了解在采用连续交付方式时如何进行最佳权衡。
在我们的书中，我们试图描述连续交付的一般做法是什么，主要挑战是什么以及可以采取的应对措施。 参照史蒂夫·史密斯的出色工作，我们认为持续交付主要是为客户提供价值，而稳定和速度可以满足业务需求就可以实现持续交付。 我们指出了许多有用的指标，可以跟踪这些指标，以使开发人员说服潜在问题和瓶颈的管理，并在采用我们推荐的某些做法时展示出改进之处。
如上所述，我们也希望读者也从书中走出来，并获得一系列Java特定技术或工具，他们可以在实现连续交付实践时进行试验。 我们经常收到电子邮件或Twitter DM要求我们提供技术建议，因此我们在这里捕获了所有我们喜欢的工具。
如果您正在寻找整体外卖，那么总结信息是，持续交付是一种内省和反复的练习：在一天结束时，您必须分析自己的做法，找出痛点，并反复进行以改善流程。 持续交付意味着持续改进。
InfoQ：在书中，您将讨论Java的发展。 您能否简要总结一下过去十年的主要变化，以及如何影响（或不影响）如何考虑使用Java进行持续交付？
Bryant＆MarínPérez ：持续交付的主要好处之一是缩短了上市时间：通过建立可以有效地持续引入稳定变化的组织，我们可以使组织对变化做出更快的响应。 一直以来，对Java的传统抱怨之一是它的冗长性，而抛弃Java的批评者通常这样做是倾向于使用更具表现力的语言，因为它们认为它们可以提高生产力。 近年来，Java的发展已大部分用于解决这些问题。 诸如lambda，局部变量推断或模式匹配之类的功能已经在其他语言中使用了很多年，并且现在正慢慢地进入Java。
对语言功能的关注意味着Java在相当长的一段时间内都缺少与现代软件的打包和运行时相关的一些重要更改。 例如，仅通过JDK 9中引入的模块化工作才使开发人员希望最大程度地减少部署工件的大小成为可能，而采用它仍然是一个正在进行的项目。 再举一个例子，JVM仅在大约两年前在Java 10中在容器中运行时才完全认可资源限制（并且所需的修补程序已反向移植到JDK 8u131）。 此类示例的结果意味着，Java在某些较新的云和容器平台上的采用或使用某些创新交付管道技术的能力已被延迟。 现在有很多相关的工具可以打包，测试和优化运行时，我们已经尝试指出它们。
还值得注意的是，最近切换到每六个月发布一次新的主要Java版本（与之前的两到三年节奏相反），也是为了更频繁地进行更改。 毕竟，Java的使用者本身就是用户，他们也希望从持续交付中受益，他们正在尽一切努力使Java朝这个方向发展，同时又保持了使其在企业中成名的稳定性。 如果开发人员确实希望Swift采用每个Java新版本中提供的性能提升或新功能（即使他们仅采用LTS版本），那么具有自动测试您的应用程序的交付管道将非常有用。
InfoQ：Jez Humble在一次演讲中说，没有模块化系统架构，“您将无处可去”。 根据您作为从业者的经验，分离的架构对于有效的持续交付有多重要？
Bryant＆MarínPérez ：这绝对是关键。 能够在大型系统的模块或组件中独立部署新功能，为提高速度和稳定性提供了更多选择。 持续交付意味着不断变化，而每次变化总是存在错误的可能性。 我们也正在越来越多地构建复杂的（自适应）分布式系统，这很难理解，而且不会确定性地失败。 当您在复杂的系统中运行或更改率很高时，故障不是“如果”问题，而是“何时”问题。 一旦接受失败的确定性，就可以开始计划缓解措施。 这就是解耦的关键所在：通过在系统各部分之间创建清晰的边界，可以创建可以限制错误影响的防火墙。
在我们的书中，出于这个原因，我们决定也专注于微服务架构范例：如果您拥有一个结构良好的模块化整体组件，则可以获得连续交付的许多好处，但是这不会给您带来隔离边界。部署点。 微服务的设计和实现很难正确实现，但是它们可以为您提供模块化的系统，在编译时和运行时都具有隔离性。
InfoQ：接下来，您是否会说微服务架构总是最适合连续交付？
科比（Bryant＆MarínPérez） ：我们宁愿对这样的“绝对”声明保持谨慎。 微服务架构带来了很多好处，但是也有很多缺点。 整体程序的运行极其简单，这不是我们应该如此Swift忽略的事情：简单性也有其价值。
当我们编写代码时，我们通常不希望过分过时地验证实现，而是按照我们认为合适的方式进行重构。 我们也喜欢将此哲学应用于建筑。 也许从一个整体开始就很简单，然后根据您的需要将整体转变为微服务。 换句话说，微服务架构可能并不总是一开始就最好的架构，但它往往是发展的最佳选择。 对于想要了解更多信息的读者，我们绝对推荐Sam Newman的新书Monolith to Microservices 。
InfoQ：哪些关键非技术方面因素可以使成功采用或破坏连续交付成功？
Bryant＆MarínPérez ：根据我们与客户的咨询经验，主要的非技术优势是企业参与不断交付的实践。 传统方法通常将IT视为成本中心，而业务通常不参与其中。 他们管理“项目”和“程序”中的软件，假设它们是有时限的活动，并且在其结尾处有一个特定的交付物。 持续交付意味着采用一种持续参与的整体方法，而企业无法承受仅仅将其“交给技术人员”的负担。
没有非技术人员的参与，连续交付将无法进行。
InfoQ：您是否为团队和组织推荐任何衡量指标或指标，以衡量其持续交付计划的进度？
Bryant＆MarínPérez ：这是一个非常有趣的领域，随着我们对连续交付的含义的理解加深，这一领域将继续发展。 这个领域的开创性参考是Nicole Forsgren，Jez Humble和Gene Kim所著的Accelerate ，与绩效卓越的团队相关的四个关键指标是：交付时间，部署频率，平均恢复时间（MTTR）和更改失败百分比。 您绝对不会通过跟踪这些指标来浪费时间。
史蒂夫·史密斯（Steve Smith）也提出了一些非常有趣的建议，他的《 衡量持续交付》一书帮助发展了我们围绕该主题的思考。 在这里，他主要关注诸如部署，构建吞吐量和稳定性之类的主题。 与此相关的是，亚伯拉罕（Abraham）在如何测量自动构建管道的有效性，测量平均，最大和加权构建时间方面做了一些工作。
最终，最佳业务指标将取决于组织的实际需求：持续交付专注于更快地交付价值，这意味着组织需要确定其（或客户）价值，然后定义衡量价值多少的指标。随着时间的推移进行了交付并进行了跟踪。
InfoQ：Java开发团队应该在交付系统上拥有多少自治权？ 他们是否只需要担心实际的管道定义和执行？ 还是积极参与设置和运行管道工具和基础架构？
Bryant＆MarínPérez ：这可能是一个有争议的话题。 Java开发人员需要参与管道的设置和运行，因为他们显然对此很感兴趣。 例如，他们希望能够轻松地更新JRE，也许是通过使用Docker容器并保持对Dockerfile定义的控制。 但是，期望Java开发人员控制交付管道的各个方面，无论是在必要的技能还是照顾管道所需的时间上，都可能是压倒性的。
在另一个极端，我们有组织创建专门的平台/ DevOps / SRE团队来管理管道设置的各个方面。 这为您提供了一个由专业的，熟练的专业人员组成的团队，并且使您可以在团队之间分担负担（有时整个公司可以共享相同的基础结构），但是要冒这样的风险。 最有效的地方可能是中间的某个位置：团队中的DevOps工程师或与团队非常接近的工程师，但是是跨团队“行会”（使用Spotify术语）的一部分，他们可以在其中共同努力并分享经验。 如果您想了解有关团队设计的更多信息及其对软件交付的影响，那么我们推荐Matthew Skelton和Manuel Pais撰写的新书《 Team Topologies》 。
InfoQ：在本书中，您将介绍有关基础CI / CD平台的不同方法，从内部部署到云IaaS，PaaS，Kubernetes甚至是无服务器。 团队在选择自己的平台时应考虑哪些关键因素？
Bryant＆MarínPérez ：我们看到的影响这一决定的主要因素是对供应商锁定的需求以及建立和管理平台专家团队的相关愿望。
一方面，本地部署是最难（可能也是最昂贵）的实现方式，但它为您提供了最大的自由度：您可以选择从硬件和操作系统到操作系统的所有内容。编排平台。 但是，您通常需要一大批专家来运行此程序。
另一方面，现代的“无服务器”和功能即服务（FaaS）平台为您提供了最少的选择，使迁移变得更加困难，但是这些平台提供了许多“现成的”核心功能，使您可以专注于您的业务而不必担心脚手架。
随着组织的成熟和需求的发展，组织在此问题上改变立场的情况并不少见。 对于大型组织来说，运行混合平台也越来越成为现实。
InfoQ：当2010年“连续交付”一书问世时，自动化部署还不是常态。 您觉得可观察性也处于早期采用阶段吗？ 在实际部署应用程序之前，从应用程序管道的角度实现可观察性意味着什么？
Bryant＆MarínPérez ：我们的确看到越来越多的组织意识到可观察性的重要性，但是作为早期采用者，它们中的许多人并没有从中获得尽可能多的收益（至今）。
可观察性正变得越来越重要，因为它是提高弹性的基本步骤之一，而这反过来又越来越成为现代经济的基本需求。 用户期望在问题变得明显之前就Swift解决问题，为此，您需要对系统有深入的实时了解。 可观察性为您提供了这一点。
我们看到的公司在尝试在连续交付管道中实现可观察性时面临的主要挑战是，在遇到现场问题之前，他们常常不知道哪种操作指标与他们的特定案例相关，因此，在其中存在很多猜测地点。 这不一定是一个不好的起点，但是它需要一个连续的审查过程来确保所选择的指标是相关的。
InfoQ：最后，您如何看待Java世界中Continuous Delivery的发展，以及您希望组织将今天的实践状态与今天进行比较？
Bryant＆MarínPérez ：我们相信，我们将看到的主要变化将围绕企业对软件开发的看法而发生。 持续交付将使诸如“修补程序”或“项目与BAU”二分法的概念过时。 变革将成为规范，企业将开始接受它而不是抵制它。
关于Java，我们可能会看到的微妙变化是组织将更快地采用Java的新版本（传统上采用Java的致命弱点是采用较新的版本）。 较新版本的更快采用以及我们已经看到的较短的发布周期，有望创造出一系列创新，将Java推向新的高度。 预见所有由此产生的新想法是一项挑战，但我们真的很期待。
java 持续交付环境
102
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
