十诫诗串词_持续交付的十诫

十诫诗串词

每个人都希望实现持续交付。 毕竟，好处太大了，不容忽视。 提高交付速度，提高质量，降低成本，使人们有更多时间来投入带来价值的事情，等等。 对于任何决策者而言，这些改进就像音乐。 特别是如果该人具有业务背景。 如果一个技术怪人可以清楚地说明连续交付带来的好处，当他向业务代表索要预算时，答复几乎总是“是的！ 做吧。”

一个连续的交付项目将开始。 测试将被编写。 构建将被脚本化。 部署将自动进行。 一切都将被绑定到一个自动化管道中，并在每次提交时触发。 完成所有操作后，每个人都将进入必杀技的状态。 将会有一个巨大的就职典礼，一个副总裁荣幸地成为第一个按下该按钮的人，该按钮会将第一个发行版部署到生产中。 这不是每个人都应该引以为荣的光荣计划吗？

该项目开始，不久之后，您遇到了第一个障碍。 但是，由于您很勇敢，并且不轻易放弃，所以您通过了。 然后，不久之后，又出现了另一个障碍。 然后是另一个。 并持续下去。 半年后，您感到自己距离不远。 您花费了预算。 即使您看不到隧道尽头的光线，也需要显示结果。 CTO要求结果。 企业想要投资的价值。 您决定做唯一明智的事情，并声明项目已完成。 即使没有连续交付也没有交付，您仍获得了连续交付认证 。 持续交付与其他被认为是成功的失败项目一起。 不仅您在做敏捷，而且还在练习CD。 韦尼，维迪，比奇 您加入了光荣失败的俱乐部。 做得好！

为什么您实施连续交付的尝试失败了？ 不可能有一个适合所有情况的答案。 但是，几乎在所有情况下都应采取一些先决条件和步骤。 您很可能错过了一些（如果不是全部）接下来的诫命。

你要敏捷

在开始实现持续交付之前，您的组织必须敏捷。

我与之合作的所有非敏捷组织都是孤立地组织的，以防止持续流动。 料仓引发切换。 业务分析师将需求传递给开发人员。 开发人员将候选发布者提供给测试人员。 测试人员会将其发回给开发人员，直到他们对该版本感到满意为止。 从那里去运营部门。 等等等等。 移交会阻止事物连续进行，因为它们会导致事物处于等待状态发生的混乱状态。 它们通常与仅使单个部门而不是整个项目受益的目标联系在一起。 这些目标不仅阻止了持续不断的流动，而且经常相互冲突。 给开发人员的目标可以使他们避免在完成后立即将其代码提供给测试人员。 测试人员的目标可能会阻止他们从一开始就尝试提高质量，并专注于发现的错误数量。 如果没有发布（即系统最稳定的情况），则运营目标通常会给出最佳的激励措施。 最重要的是，筒仓可以防止团队彼此感到痛苦。 如果不真正理解其他人面临的挑战，您的解决方案最多将是次优的。

实现连续交付的唯一方法是消除这些孤岛。 将切换转换为连续的字节流，流向生产环境（它们的最终目的地）。 只有当整个组织致力于消除障碍并使所有事物（信息，人员和思想）不断流动时，我们才可以开始考虑需要解决的技术方面。 敏捷是关键。

您可能会说：“但是我很敏捷”。 也许你是，可能不是。 大多数组织都不敏捷，因此您可能都不是。 现在，这句话听起来有些夸张。 这些天，几乎不是每个人都敏捷吗？

不久前出现了“敏捷疯狂”。 每个人都在谈论它，它变得如此之大，以至于您的CTO都无法忽略它。 我们知道这是真的，因为甚至Gartner在其年度会议上（那些让CTO感到自豪的邀请）都说：“现在是时候了，敏捷起来。” 因此，首席技术官回到了他们的公司，并向他们的下属说了两个历史句子。 “我做了一个决定。 我们将变得敏捷。” 问题在于，在大多数情况下，这意味着每个CTO至少低5级的人都应该变得敏捷。 那样行不通。 整个组织要么敏捷，要么没人。 否则，迟早您会跌入高潮，这将阻止您执行需要做的事情。 当发生这种情况时，将所有经理重命名为Scrum Master以及您的业务分析师现在是产品所有者都没关系。 每天站起来不会使组织变得敏捷。 改变整个公司的文化确实可以，但事实并非如此。 因此，您最终从金字塔的顶部开始采用瀑布方法，仅在最底部将其自身转换为“敏捷”。 这就像打着伞，朝尼亚加拉大瀑布的底部走，喃喃自语。 我只需要继续一会儿。” 这会给你带来沉重打击。

为了在您的PMI证书旁边再贴一张标签而做敏捷不是走的路。 您需要真正采用它。

你应该重构

您准备好重构代码了吗？ 如果您不是，则连续交付将无法工作。 您将花费大量时间来尝试自动化对非可测试应用程序的测试。 然后，一旦最终完成，您将发现测试不稳定并且由于随机原因而失败。 您还会发现测试执行持续数小时而不是数分钟。 如果应用程序每次有人提交时都要通过连续交付管道，则在设计该应用程序时必须考虑到这一点。

然后，您将开始怀疑为什么尚未重构应用程序。 为什么让它腐烂了这么久？ 虽然您可能不知道，但答案很简单。 测试覆盖率不高的应用程序重构成本太高。 当对代码的任何更改都可能带来无法预料的后果时，风险就太高了。 根据定义，没有测试的应用程序是遗留应用程序。 缺乏测试使我们无法改善应用程序，它们很快就成为传统。 除非添加新功能，否则它们将成为不应该被触摸的东西。

即使您确实鼓起勇气为应用程序编写测试并在此过程中重构代码，您很快也会发现这样做是不值得的。 你父母不是教你不要碰烂食物吗？ 对于应用程序也可以这样说。 保留它们或重写它们。 让旧事物表现得像旧事物一样浪费时间。 那就像在我祖母身上涂口红一样。 您可能会稍微改善她的容貌，但不会让她再次年轻。

从一开始，您应该做的就是采用连续重构。 我们不能让自己花费大部分时间来添加新功能。 无论有多少企业喜欢获得新功能，这种方法都会导致无法维护的代码，这将导致开发某些产品的成本和时间不断增加。

我要说的是，如果您不花费至少三分之一的编码时间进行重构，则说明您做得不好。

你应该教育所有人

您决定创建一个连续交付部门。 我可以透过窗户看到烟火，并听到您庆祝这个决定。 该部门将做什么？ 创建CD管道供所有团队使用？ 创建一个可以与您公司中的任何项目一起使用的Uber管道？ 让开发人员不必学习Jenkins的工作原理吗？ 作为一项出色的运动，您应该获得一枚奖牌。 您正在帮助其他人，使他们从学习如何做的事情中解放出来，让他们继续编写应用程序。

即使后面的句子在政治上听起来不正确（您甚至可以说是冒犯性的），但我还是要说出来。 连续交付部门的存在是令人憎恶的，除非其目标是创建概念证明并教育他人。 其他任何事情充其量都是误会。

让其他人来照顾您的连续交付流程是错误的。 他们不知道您在开发什么。 你做。 更重要的是，如果您不能自己编写传送管道，则将无法以CD友好的方式设计应用程序。 如果您负责应用程序的代码，则还应该负责编写CD管道。 它和其他代码一样，属于负责应用程序的团队。

不要花时间来培训您所在的组织，而要创建Uber渠道。不要给他们鱼。 教他们如何钓鱼。

你要小

大团队没有连续性。 希望您能够持续交付由许多人维护的代码是最乐观的。 无法完成。 您必须有一个小团队。 这就是微服务如此受欢迎的原因之一。 一个大团队会产生大量代码库。 许多人坐在大型应用程序的顶部相当于一艘巨大的集装箱船。 它漂浮着，经过足够的时间，它到达了目的地。 但是，我们没有时间。 我们希望尽快交付。 达到这一速度的唯一合理方法是组建一支完全负责一项或多项服务的小团队。 只有这样，我们才能达到目标。 每个团队都可以在完成功能后立即交付功能，而无需等待公司的其他部门醒来。 这些团队是垂直的。 它们不是由一个部门（例如测试人员）组成，而是由一起拥有为生产提供服务并确保其始终运行的所有技能的人员组成。

一个团队应该有多大？ 它取决于用例，但根据经验，不少于四个，最多不超过十个人。 除此之外，这不是软件开发团队，而是学校聚会。

你应该练习TDD

我什至不会讨论是否应该进行任何手动测试。 除探索性测试外，如果您要应用连续交付，则必须自动进行所有操作。 如果您进行手动测试也可以（实际上不是，但我会假装是这样）。 问题是，在这种情况下，您需要停止假装可以进行连续部署。 你不能 因此，我假设您所有的测试都是自动化的（探索性测试除外）。

您编写了许多测试，并设法使它们始终有效。 您的覆盖率很高，并且没有易碎的测试。 它们很强大，您可以依靠它们。 你是我的英雄，这就是为什么我很难说它不能连续交付。 令人钦佩的是，您设法将旧应用程序转换为可测试的并可重构的程序（测试消除了我们更改某些程序时会发生的恐惧）。 但是，您需要走得更远。

现在，您需要在代码之前开始编写测试。 如果提交时还没有测试，则CD管道的执行将（几乎）总是成功的。 毕竟，如果没有对所做更改的验证，那么除非您设法弄乱了旧功能，否则几乎不会出错。

如果测试需要作为提交的一部分，那么问题是您何时编写它们。 一旦完成代码并在提交之前？ 如果那是您的工作，那么测试将毫无价值。 他们可能会复制您编写的代码。 相反，测试应该驱动您的开发。 它们应作为您编写代码的要求以及对实现的验证。

采用测试驱动的开发！

一开始很难。 首先，您会认为它不能应用于您现有的代码，并且您是对的。 然后，您将开始更好地设计代码，事情将变得更加容易。 一段时间后，您将可以进行TDD，但是成本太高。 您会发现使用TDD的速度要比不使用TDD的速度慢得多。 不要绝望。 它变得更容易，并且变得更快。 如果有足够的练习，那么使用TDD会比不使用TDD更快。 快多了。 您将有信心重构您的代码。 知道您的测试涵盖了大多数（并非全部）副作用，您将可以专注于手头的任务。 您将开始想知道，如果没有TDD，您是如何开发某些东西的。 唯一的问题是掌握它需要时间。 好消息是，在彩虹的尽头有一个金壶。 您只需要坚持不懈。

关于TDD的重要理解是，主要目标不是测试，而是设计软件的方法。 测试是该过程的宝贵副产品。

您可能不同意TDD的价值。 没关系。 我不会发动战争。 但是，无论采用哪种方法，除非重构代码，否则测试都必须是每次提交的一部分。 在这种情况下，您的服务不会更改功能，因此现有的测试可能就是您所需要的。

您应将CD管道定义为代码

只需单击几下并通过将值设置为几个字段即可在Jenkins中创建新作业，这是否方便？ 也许不是很多，但是还是值得的。 它允许您创建CD管道，而无需学习如何编码。 那不是很好吗？

不是！

软件行业放弃了针对开发人员的单击单击单击单击类型的工具。 允许您通过UI指定所有内容的框架是失败的。 ESB（至少是基于UI的ESB）不见了。 允许您拖放自动变成HTML的元素的编辑器消失了。 通过UI进行集群管理已成为过去。 代码是唯一留下的东西。 UI适用于用户，代码适用于开发人员。

我将借此机会告诉你一个秘密。 你的专业是什么都没关系。 如果您从事软件工作，那么您就是编码员。 或者，至少应该如此。 如果您是测试人员，则应编写测试代码。 如果您是操作员，则应编写操作代码。 如果您负责CD管道（忽略这样的角色不应该存在的事实），则应将它们编写为代码。

使用CD工具可以看到一切如代码的趋势。 大多数（至少是那些值得使用的）或者围绕定义为代码的管道构建，或者在以后添加它们。 如果您是Jenkins用户，请使用Jenkins Pipeline。 忘记FreeStyle作业曾经存在过。 如果您更喜欢其他工具，则建议是相同的。 CD管道应定义为代码。

您可能会问自己“我们为什么要将CD管道定义为代码？” 答案在于我们采用的开发实践。 代码易于版本化，易于放入Git（或可能不幸使用的任何VCS），可以轻松进行检查，部署等。 最重要的是，定义为代码的管道可以与测试，构建和部署的其余代码一起驻留。 它应该在同一个存储库中。 如果您没有看到版本控制，代码审查，提取请求和开发人员使用的其他便利的价值，那么您会遇到大问题。 您从事的行业不对。 您不属于软件公司。 他们说，换专业永远不会太晚。 您可以成为医生或律师。 你说什么？ 为时已晚？ 成为医生或律师需要太多时间？ 确实如此。 优秀的软件工程师也是如此。 因此，请抓紧自己并学习编码。

您应该有一条快速的管道

CD管道必须快速。 您可能会问。 好吧，这取决于开发人员需要花多长时间从椅子上出来，去厨房，喝咖啡，再回到办公桌上来开始一项新功能。 他可能会在路上遇到某人并进行简短的聊天。 或者，也许，您办公室里没有咖啡机，而他需要去最近的酒吧才能得到。 如您所见，时间因情况而异。 我估计平均大约需要15分钟。 那就是您的管道应该有多快。

您想专注于手头的任务。 该任务只有在真正完成后才能完成，并且包括通过CD管道进行的验证。 仅当完成一项任务后，您才可以移至下一项。 否则，您可能需要进行很多上下文切换。 开始使用一项新功能，收到有关构建失败的通知，在开始新功能之前返回您使用过的功能，尝试记住所做的工作，对其进行修复，推送更改，然后返回到新功能，需要一段时间，接收另一个失败通知，尝试找出问题出在哪里，依此类推。 那不是生产的方法。 我们的工作需要专心，如果由于构建失败的通知而被打扰，我们将无法专注于手头的任务。

您可能会说：“我们无法使CD管道在15分钟内运行。” 首先，我需要澄清的是，获取咖啡的时间是大多数管道应运行的时间。 负载测试是一个例外。 光是拿咖啡的时间就不够了。 将其放在管道的末端或并行运行。 其他一切都应该很快。 我们需要尽快获得反馈。

回到抱怨您的CD管道执行时间长于获取咖啡时间的情况……如果是这种情况，请重新阅读Thou Shalt Refactor命令。 了解如何设计可测试的应用程序。 了解如何编写模拟和存根。 使用Docker加快部署速度。 并行运行管道步骤。 我从未说过这会很容易。 我说你会失败的。 如果您走到了这一步，就有希望。 现在不要放弃。

您应考虑将故障管道修复作为最高优先级

CD管道失败时会发生什么？ 如果速度较慢（请参阅“您应该有快速管道指令”），您可能会尝试保持专注并继续使用该新功能。 该问题将在以后修复。 如果是这样，让我告诉您您的行为是不可接受的。 除了修复失败的CD管道外，没有什么比这更重要了。 一些明显的例外情况是疏散人员以防您的办公室开始着火，还有您的妈妈打来的电话，她想告诉您她正在观看的肥皂剧的最新进展。 在所有其他情况下，您需要停止做您正在做的事情并解决问题。 它不会消失，因此最好还是在您脑海中浮现。 您会很快发现问题。 毕竟，发现几分钟前刚刚推送到存储库的根本原因是多么困难。 这就是管道必须快速的原因。 在完成之前，您不应该从事其他任何工作（不包括负载测试）。

您可能会在此诫命中遇到的问题之一是您的测试可能不稳定。 它们可能由于代码错误之外的原因而失败。 我看过很多次了。 测试失败，而您经过测试只是发现它在大多数时间都可以工作，而不是错误的迹象。 第三次发生，您可能会忽略它。 “哦，又是一次考验。 只需重新运行管道，它就会起作用。” 一段时间后，您甚至会停止重新运行管道，而只是忽略失败通知。 发生这种情况时，对系统的信任就会丢失，您也可以卸载Jenkins实例并释放其资源以获取更多有用的东西。

无论是否需要修改被测代码或测试本身，都必须修复失败的测试。 就这么简单（解释，不一定要做）。

您应在本地运行CD管道

提交不可能工作的代码没有任何借口。 CD流水线是最后一道防线，而不是允许您推送不确定的代码的系统。 您的CD流水线正在某些服务器上运行的事实并不意味着您在提交代码之前不应该在本地执行部分CD流水线。 我不建议您在笔记本电脑上运行性能测试，也不建议您手动部署到生产环境。 你不应该 但是您应该做的是在提交代码之前在本地运行大多数管道。 执行单元测试，构建工件，运行（部分）集成测试。 我们拥有做到这一点的技术，并且，如果您按照诫命执行，流水线将非常快，因此您不会浪费太多时间。

提交不太可能起作用的代码是对同事的不尊重。 他们可能会拉出该代码并在其之上工作。 如果您使用了避免的拉取请求，但是却在浪费时间，其他人则需要花一些时间来检查无效的代码。

您只应提交给主分支（或使用短期功能分支）

你走了 你很敏捷。 您对代码进行了重构，使其可测试，并且采用了连续重构作为一种方法，以防止您的服务成为传统的I，无法再使用这种类型的代码。 每个人都接受了持续交付的好处的教育，每个人都采用了它的做法。 您的团队很小，每个人都在使用TDD原理进行开发。 您的CD管道被定义为代码，并且闪电般快速。 当管道发生故障时，修复是最高优先级。

还应该做什么？ 当然，您竭尽所能成为连续交付的光辉典范。

您的团队正在与分支机构合作，完成一项功能后，该功能将合并到master并交付到生产环境。 一切都是桃子。 唯一的问题是您不连续。 您采用了一些最佳实践，但是您仍然仅在CD的交付部分进行操作。

CD（以及CI）背后的主要思想之一是不断验证我们的代码是否按预期工作。 如果您正在使用分支，并且将它们合并到master频率比每天一次少，那么您将推迟CD。 您也可以称其为最终交付 。 您合并分支所花费的时间越多，您在黑暗中的时间就越多。 请记住，这不仅涉及验证您编写的代码，还涉及验证其是否与其他人正在处理的代码集成。 这种集成通常是一些最有问题的错误的原因。

理想情况下，您甚至没有分支，但直接提交给master 。 如果您的CD流水线是值得信赖的，那么使用这种方法的风险确实很小，而且收益很大。

我可以想象，此时此刻，您在自言自语，例如“做不到”或“风险太大”。 当然可以做到这一点，而且它是由许多先进的软件公司完成的。 风险是否太大取决于您真正采用CD方法进行软件开发的能力。 您可能必须使用功能切换开关，团队中的每个成员都必须对其所做的事情负责。

您可能仍然认为，提交到master分支对您来说是一个很大的负担。 没关系。 您可以使用分支。 您不能做的就是等太久，然后再将它们合并回master 。 每天一次（如果不是更频繁的话）应该是极限。 花费六个小时的编码，将其合并到master分支，然后等待几分钟，以防管道失败。 如果是这样，您仍然有两个小时的时间来解决问题，然后再离开办公室。 鉴于所有其他诫命都得到了履行，这应该是小菜一碟。 问题更多的是精神上的调整。 我们已经习惯了长期存在的分支机构，以至于这似乎是唯一的工作方式。

现在怎么办？

如果您能遵循所有十诫，就应该感到骄傲。 尽管大多数公司声称他们正在进行连续交付，但事实是大多数公司都在伪造它。 像任何其他流行的做法一样，公司会跳进去，尝试应用它，否则就做不到，最后，改变规则和目标，以便他们可以贴上标签并通知CTO已经完成。 如果您确实做到了，您可以说您是一个很小的独家俱乐部的成员。 欢迎使用高级软件开发。

只缺少一件事。 删除将您的服务部署到生产的按钮。 删除流程中剩下的唯一手动操作，并将管道从持续交付转换为持续部署到生产。 过程是相同的。 唯一的区别是单个按钮。

翻译自: https://www.javacodegeeks.com/2017/03/ten-commandments-continuous-delivery.html

十诫诗串词