成都小程序开发的世界建立在由两个笨拙的隐喻组成的基础上。首先是建筑施工。小程序有“架构师”帮助设计代码的“蓝图”，然后将其交给“构建”它的小程序开发人员。第二个比喻是复杂制造。小程序开发具有在概念流水线中工作的高度专业化的阶段。设计师设计，然后交给开发人员开发，开发人员再交给测试人员进行测试。
然而，事实证明，这些对于创建小程序来说是非常糟糕的比喻。可以理解的是，早期的小程序开发人员会依赖与已知职业的相似之处。但还是。它不是很好用。
小程序开发看起来不像建筑。建筑物需要大量的前期规划，因为一旦奠定了基础，您就真的无法改变。但对于小程序来说，这根本不是真的。小程序开发看起来不像制造业。这是知识型工作，因此您不能将其分解为简单、重复的任务，由低技能的流水线工人执行。
小程序中一些最重要的巨变就是针对这些隐喻的。以敏捷运动为例。它针对的是过度的形式主义、流程和繁重的前期规划，以及建筑施工和复杂流水线的所有特征。与其将越来越多的精力投入到规划和锁定计划中，我们为什么不承认变化的必然性并善于应对变化呢？
敏捷小程序运动的核心是小程序的独特性和其他隐喻的不适用性。
敏捷摆脱了业务代表、开发人员和测试人员之间分阶段的、专门的交接。为什么这些人在真空中工作？成功的小程序开发需要所有这些人在整个小程序开发过程中进行协作。我们会让他们协作，然后尽早且经常地发货，这样我们就可以响应反馈和不断变化的需求。
但是一旦我们真正将小程序推向生产，那么我们就不会再担心了。然后是运营商的问题。
说这话时，我有点开玩笑——我认为敏捷的支持者在2000年代实际上不会这么说。但它确实强调了敏捷的早期是如何将小程序开发的所有各方都带到桌面上的，除了运营。这需要几年的时间和不同但相关的运动才能做到这一点。
这种新运动称为DevOps，它最终将运维人员带入了聚会。DevOps，就像之前的敏捷一样，已经成为一个流行语。但实际上，它的核心在于认识到，在开发和运营之间进行正式的、分阶段的交接与将小程序视为建筑或制造项目一样毫无意义。
结果？小程序开发工作已经开始在早期并经常在流程中包括操作专家。开发人员越来越自动化操作，包括部署、配置和监控。
我们将所有这些称为DevOps。它是新的，范围广泛，而且常常令人困惑。这意味着DevOps的采用伴随着潜在错误的雷区。让我们看看一些常见的问题以及如何避免它们。
我首先介绍了我所做的背景，因为了解我们去过的地方和我们要去的地方很重要。我们已经浪费了数十年和数以亿计的美元试图细分和专业化小程序开发，而不是拥有跨职能团队。敏捷和DevOps都引导我们远离那些过去的错误。
如果可以理解的话，这使得这里的第一个错误特别具有讽刺意味。假设一些企业程序或 IT 部门想要加入DevOps运动。那么，他们做什么？他们创建了一个DevOps部门。
这个新部门很可能包括前小程序开发人员和前 IT 运营和支持人员的一半和一半的混合体。“走出去，混合你的知识，坐在开发和运营之间，”管理层指示。他们可能会参加一些自我指导的培训和研讨会。
这从根本上没有抓住要点。如果你想避免从根本上忽略这一点，请考虑我对敏捷的描述。高功能的敏捷团队将业务分析师和测试人员带入开发领域，将他们视为团队的一流成员。您可以通过对IT运营和支持做同样的事情来实现DevOps。让他们成为他们支持的团队的一部分——不要在你已经拥有的两个脱节的部门之上创建第三个部门。
一旦您避开了“DevOps部门”的陷阱，您就会面临新的基础性挑战。具有运营专业知识的人员已准备好与团队打成一片，自动化部署、配置和监控。但是您的开发文化是否已为这种混合做好准备？
敏捷早期最大的错误之一就是没有改变技术实践。习惯于每年发布小程序的小程序组正面临严重的文化冲击。敏捷方法通常要求您每隔几周发布一次。这导致了很多尴尬、停顿和失败的敏捷采用，其中团队只是结束了略有不同的会议。
您在DevOps方面面临同样的概念问题。总的来说，作为一个行业，我们已经自动化了复杂的部署管道，允许脚本化、按需配置环境，并将监控技术归结为一门科学。但要利用所有这些，您需要以永久可部署状态存在的代码。
许多商店犯的错误是没有意识到这一点。如果您习惯于在代码的可部署版本之间间隔数天或数周，那么世界上所有的DevOps都帮不了您。这就像开着一辆没有油的汽车开到一条漂亮、平坦的新路上。在采用DevOps之前，请确保您的开发文化已经成熟。
在某些方面，这个错误是后者的更具体版本。但值得单独呼吁，因为情况并非总是如此。
用最广泛的术语来说，您在一个范围的末端有两个协作工作流：基于主干的开发和基于功能分支的开发。基于主干的开发意味着开发人员始终在代码库的几乎连贯的单一版本中工作。基于功能分支的开发意味着团队的工作方式为各个功能提供了自己的隔离沙箱。
探讨每种方法的优缺点超出了本文的范围，但我会谈谈它们对您的DevOps采用工作意味着什么。源代码控制工具对您采用哪种方法有巨大影响，就像您的方法对DevOps作为一种方法有重大影响一样。
如果您喜欢基于功能分支的开发，那么您将在采用DevOps时遭受很多痛苦。DevOps使您如何在开发人员的机器和生产环境之间处理代码的许多方面自动化。保持代码库的许多不同概念风格会使DevOps的关注点复杂一个数量级。
迁移到基于主干的工作流程，让您的生活更轻松。
我将总结一些您可能只有在前三个方面做得很好后才会面对的问题。这是因为一旦您成功采用这些实践并在您的环境之间轻松移动代码，就会发生此错误。
有了这个问题，你就没有意识到你可以从你的新能力中得到什么。您可以轻松地四处移动您的构建，但您将它们作为整体移动。这是一个错误，因为你错过了。
通过基于主干的开发，您不再通过版本控制来管理功能，而是开始通过选择性部署来管理它们。您可以像Facebook这样的公司那样实现这一目标：使用功能标志管理系统。这样做不仅可以让您配置运营数据，还可以配置整套功能和用户体验。
为了在生产问题上实现最大的灵活性，您需要更改代码库。确保它是灵活的，以细粒度的方式构思，并且易于分区。因为DevOps不仅仅是关于自动化你部署事物的方式——它是关于自动化你在部署后处理它们的方式。
成都小程序开发一开始就建立在有缺陷的比喻之上。然后，它当然会通过敏捷和DevOps等运动进行纠正。当然，这些术语被夸大为流行语状态。但是，在表面之下，它们提供了真正的智慧和洞察力。如果你能看穿炒作，避免重大错误，你将从行业的这些纠正行动中获得巨大的价值。
