兑现CI / CD的承诺

曾几何时，有一艘大而可怕的海盗船，尽管有点漏水，但它统治了公海。在暴风雨或战斗之后，船员常常不得不将海水泵出下层甲板。有一天，在一场特别恶性的战斗之后，他们意识到炮弹已经突破了水线以下的船体。他们不确定如何在没有工具或木匠的情况下进行修复。因此，他们只是将泵连接起来，使其日夜不停地运转。一段时间以来，这种步伐保持了一定的步伐，但很快他们不得不购买两倍数量的水泵，并在其他人航行时请更多的水手为这些水泵配备人员。不久之后，他们有更多的水手驾驶水泵，而不是实际航行或劫掠。这不是他们签约的目的，这使每个人都很怪异。不久之后，他们成为了与从船上抽水有关的一切事情的专家，但他们的其他航行，抢劫和掠夺技能却受挫，他们最好的人感到沮丧。在一年结束之前，他们的船沉没了。

这个故事的寓意是，不要对待症状：对待原因。

CI / CD（持续集成和持续交付/部署）是我们​​生活的一部分。我们参加有关CI / CD的会议，我们撰写有关CI / CD的文章和博客，我们在LinkedIn页面上列出CI / CD。甚至没有人争论这是否正确。我们都在同一页上。对？

除了……如果您仔细听别人说的话，他们根本不是在谈论CI / CD，他们可能会说“ CI / CD”，但他们只是在谈论持续集成。没有人在谈论（或练习）持续部署。完全没有。就像我们都忘记了它的存在一样。

不要误会我的意思，过去十年我们在CI方面取得了进步，这真是太好了。但这还不够。甚至还没有成功。持续集成的目的是永远不要对我们软件的语法和逻辑集成的正确性感到自满，尽管这是一个不错的收获。 CI的目的是清除路径并为连续交付做好准备，因为CD确实可以节省您的资金。

就像在那艘海盗船上一样，您需要处理原因，而不是追逐症状。在我们的（海盗！）生产海盗船上，那些泄漏和孔洞的主要来源是什么？这是在您编写代码的那一刻到代码生效之间所发生的一切：您的代码消化系统太长，漏水，膨胀，膨胀，肿胀，集总，烧毁。

好问题。很高兴你问。 CI / CD是一种过程和方法，旨在通过对其进行测试和部署来确保您合并到main的所有代码均可在任何时候部署。自动。每次比较之后。

CI / CD的目标是将软件更改的前置时间缩短到足够短的时间间隔，以使我们的人类学习系统（肾上腺素，多巴胺等）可以映射到编写和发布代码的反馈循环。

如果您的团队中的任何工程师可以合并一组主要变更，请确保在15分钟后他们的变更将被测试并部署到生产中，而无需人工操作或手动干预，那么恭喜您！您正在做CI / CD。

实际上很少有团队练习CI / CD，但几乎所有团队都应该这样做。这是基本的软件卫生。

在书写和运输之间经过的时间是室温培养皿，其中病理症状繁殖并滚雪球。较长的交货时间导致更大的代码差异和更慢的代码评论。这意味着任何审查或修改这些噩梦差异的人，无论何时从编写代码到审查再返回，都必须在脑海中暂停和交换整个上下文。

因此，随着人们花费越来越多的时间在彼此之间等待（例如审阅，评论，部署，进行请求的更改）以及越来越多的分页状态，开发周期的弹性反馈循环开始越来越长。进出他们的大脑，并试图记住他们在哪里以及他们想做什么。

但情况变得更糟。大多数部署都是手动执行的，而不是由编写代码的人手动执行，而是在编写代码后的某个不确定的时间间隔内进行，最糟糕的是，许多开发人员的更改被立即批处理。最重要的是，这使工程师摆脱了工作的影响，并使他们无法在代码的整个生命周期中实践负责任的所有权。

汇总变更意味着您无法练习可观察性驱动的开发；您不能指望工程师看着他们的代码散发出来，并确保它在生产中正常工作。您不知道代码何时发布，也不知道是谁负责生产行为的更改；因此，您没有责任心或自治权，也无法对自己的代码实行软件所有权。最终，您的工程师将花费更多的时间等待，摸索或处理技术债务，而不会使业务向前发展。

由于您现有的工程师如此之多，您将需要雇用更多的工程师，这会带来更高的协调成本。很快，您将需要专门的角色，例如SRE，ops，QA，建筑工程师等，以帮助您独立应对各种症状。然后，您将需要更多的经理和TPM，等等。你猜怎么了！现在您是一家大型且昂贵的公司，而且您像恐龙一样笨拙。

它变得越来越慢，因此变得越来越难，也越来越复杂，因此您需要更多的资源来管理复杂性并应对副作用，从而带来更大的复杂性和表面积。这是软件开发的死亡螺旋。但是还有另一种方式。您可以从源头上解决问题，方法是不懈地专注于编写代码行与将代码完全部署到生产之间的时间长度。固定该时间间隔，自动执行该时间间隔，跟踪该时间间隔，将实际的工程资源专用于随时间缩小。

直到该时间间隔短到足以成为功能反馈循环为止，您所要做的只是管理功能障碍的症状。延迟时间越长，这些症状就会越多，并且您的团队将花费更多的时间来解决泄密问题。

多短？ 15分钟很棒，一个小时以下可能很好。可预测性与长度一样重要，这就是人为因素不合格的原因。但是，如果您当前的时间间隔大约是15天，请放心-缩短此时间间隔所做的任何工作都会有回报。任何改善都会带来红利。

这是很多人看起来可疑的地方。他们可能会说：“我不确定我的团队可以解决这个问题”。 “对于Facebook或Google来说，这一切都很好，而且很好，但我们不是。”

这可能会让您感到惊讶，但是连续部署是在生产中编写，发布和运行代码的最简单方法。这是关于软件的违反直觉的事实：快速进行许多小的更改比缓慢进行一些大的更改绝对容易。

这样想吧。您会更容易发现，理解，复制和修复以下哪些错误：您今天早些时候编写的代码中的错误或去年团队中某人可能编写的代码中的错误？

还差得远！您将永远不会再像现在一样调试或理解此代码，因为您的初衷在您的脑海中荡漾，您对问题及其解决方案的了解又丰富又新鲜。

在编写代码时，应该从现在起半小时内对未来的自我进行测试：“如何分辨代码是否在执行您想要的工作？”您编写代码，合并到main，等待几分钟，然后拉起可观察性工具以通过仪器的角度查看生产。问问自己，“它在做什么吗？”和“还有其他东西看起来……很奇怪吗？”

降低这种节奏的团队通常会在那时和那里找到所有错误的80％以上。它让人耳目一新，可以随时准备寻找合适的东西，可以现场进行检测。如果出现任何问题或看起来不太正确，则可以当场解决另一个问题。

相反，没有快速部署实践并且不习惯观察生产变化的团队，那么，他们找不到这些错误。 （他们的客户这样做。）

顺便说一句，是的，要每月交付一个应用程序并使其每天发送十次并不是一件容易的事。但是从一开始就以连续交付的方式启动应用程序并保持这种状态非常容易，而且绝对不要让它滑过15分钟的交付时间。就像亚历山大大帝每天早晨在早餐前上马一样，这几乎没有工作的感觉。

因此，如果现在将旧版应用程序转移到CD上感觉负担太重，您是否至少可以从头开始使用CD来启动任何新的存储库或服务或应用程序？任何CD总比没有CD要好。更改后甚至自动部署某些代码将在团队中强制执行许多良好的模式，例如保留版本之间的向后兼容性。

为什么这么少的团队将连续交付作为优先事项？交货时间短和反馈回路紧密的优点是如此引人注目，广为人知且易于理解，以至于我从未理解过。但是现在我想我愿意。

问题是，这听起来像是人的问题，而不是技术的问题。因此，这被归类为管理问题。经理习惯于使用管理工具来解决管理问题，例如要求增加员工人数。

对高层管理人员来说，这也可能是一件很难的事。您要他们在短期内接受功能路线图上的延迟，并可能在不确定的时间内接受较低的可靠性，以便实施与我们的基本人类本能完全相反的功能，这告诉我们放慢速度以增加速度安全。

总的来说，工程师似乎意识到连续交付的价值，并且许多人迫切希望与CI / CD一起尽可能快速，充满信心地工作。如果您想雇用更多的工程师，那将是招募猫薄荷的绝佳之选。更重要的是，它使您的团队可以更有效地利用现有的工程周期。

最后，我呼吁世界各地的工程经理和主管。您是否希望您的团队充满激情和投入，全力以赴，以最大的产能输出，花最少的时间进行消防工作或倾向于逾期偿还技术债务或等待对方的审查？

您想让您的团队成员回顾并怀念您，因为他们改变了他们对软件开发方式的看法-永远让他们望而却步的人吗？我们的命运掌握在您手中。

取得CI / CD的团队之所以没有这样做，是因为他们比我们其他团队更优秀。我答应你。他们是比我们其他人更关注流程的团队。优秀的团队可以培养出色的工程师，反之亦然。

持续交付可帮助您的工程师在生产中拥有自己的代码，但它还有许多其他好处。它迫使您做所有正确的事情-编写较小的差异，快速查看代码，像注释代码一样使用原始意图，使用功能标志，分离部署和发布等。

您可以花费很多时间来烦扰人们清理代码并分别遵循所有最佳实践，或者您可以专注于缩短反馈循环并看着其他一切独立完成。 难吗？ 是的，很难。 但我希望我已经说服您，值得这样做。 它正在改变生活。 它是我们通往明天的社会技术系统的桥梁，我们中的更多人需要实现这一飞跃。 您在2021年实现CI / CD的计划是什么？ 标签：CD / CD，持续部署，持续集成