Freshworks是一家致力于SaaS的公司。我们的客户大多是在互联网时代出生的，他们希望我们不断推出更新-问题必须在发现后立即修复，令人满意的功能进步必须定期推出。当我在构建企业内部版本产品时，用户不情愿地接受了6-12个月的版本更新等待时间，特别是如果他们不能尽快获得修复包的话。然而，这些天，人们的期望却大不相同。我属于Freshworks的工程团队，该团队构建了一个开发人员平台，返现卡，使世界各地的开发人员能够在Freshworks产品中构建集成和生产力应用程序以及全新的体验。我们的主要产品是Freshworks Marketplace。这篇文章讲述了我们如何成长为一个每天都在部署的团队。                                             小组在18个月内的部署复活开发平台作为我们的产品Freshdesk的一个分支迈出了它的第一步。我们不过是Freshdesk工程部的另一个小队。虽然我们大多数面向客户的代码都在Freshdesk代码库中，但是面向开发人员的代码仍然是独立的。我们的敏捷和速度与Freshdesk是分不开的。我们很高兴坐在Freshdesk的外衣上，im即时通讯云，看着我们最初的几个用户开发应用程序，并彻底改变他们的Freshdesk体验。随着Freshworks开始开发更多的产品，新产品也希望加入到应用程序策略中。在我们意识到之前，我们必须自己转型为一个多产品平台。我们必须发展速度更快的能力，为多种产品提供服务。随着新用例的开放，应用程序开发人员要求快速的节奏。我们必须找到一种快速部署的方法，以满足内部和外部的需求。瓶颈因为后知后觉是20/20，所以我们可以方便地回首，找出当时阻碍我们前进的障碍。我们的团队并没有同时发现所有的瓶颈，云实，但随着时间的推移，这些瓶颈基本上都被解开了。我们相信，大多数试图在日常部署过程中前进的团队都会遇到类似的挑战：代码集成工作流程：源代码是如何从工程师的笔记本电脑转移到生产环境中的，它必须导航到哪里才能到达目的地？自动化：移动代码（尤其是部署到测试或生产环境中）所涉及的步骤中有多少是自动化的？文化：是否每个人都觉得有权做出有计划的决定，并在他们感到自信的时候部署代码？架构：你的架构有多松散耦合，它能为你的工程师提供多大的自由度？作为一个全天候推动业务的团队，我们有一个额外的责任——行动迅速，但不要破坏事物。让我们挑出每一个瓶颈：代码集成原理与业内几乎所有人一样，我们过去一直遵循广受欢迎的GitFlow特性分支原理作为我们集成工作流的基础。简言之，GitFlow规定了在特性分支中构建和测试变更，该分支在适当的时候合并为一个稳定的分支，如"develope"。在合并和集成了足够多的特性之后，通过将develope合并到master来完成一个发布。GitFlow为我们的团队提出了几个挑战：分支测试环境：每个特性分支都必须在自己的测试环境中进行部署和测试。我们可以同时测试的特性数量是我们可以管理多少环境的一个因素，而不是有多少工程师可用的因素。这是一个挑战，考虑到我们的环境主要是Freshdesk的扩展，但我们并没有真正构建Freshdesk。保持环境的正常运转是一个不断追赶的游戏。每次从头开始建立环境太麻烦了。痛苦的合并：随着特性快速推出，合并到稳定分支（称为预阶段）总是充满冲突。解决方案往往耗时太长或导致倒退。为了最小化回归，我们最终在预测试阶段对特性进行了双重测试。这造成了背压，有可能拖累开发商。 使用我们的GitFlow版本将三个独立特性合并到生产环境中当我们慢慢离开Freshdesk时，我们可以自由选择更适合我们团队的理念。我们的平台主要建立在一个面向服务的架构上（而不是一个整体），我们的团队比Freshdesk的要小得多。我们意识到我们有低重心的优势（通常在软件工程术语中被称为敏捷性），并决定采用三个流。这三个流简化了GitFlow分支策略，以优化在开发过程中更早地识别合并冲突。             使用三个流程将功能合并到生产中 三流迅速带来了以下好处：单一测试环境：我们只需要管理一个"开发"环境来测试工程师提交的所有更改。立即解决冲突：工程师不是在测试周期结束后学习冲突，而是在他们开始致力于"开发"时就发现潜在的冲突。在预测冲突和允许代码在特性切换后交付到生产环境方面，三流确实需要更严格的开发纪律。纪律的缺失必须通过过度的沟通来弥补，同时还要有一种微妙的船运舞蹈。在我们的经验中，与过去相比，这仍然是顺利和无麻烦的。工具和自动化由于测试和部署中涉及的大部分工作都是手动的，所以我们将努力准备部署更改，然后在它们准备好后立即发送。幸运的是，事实证明，在可以实现的自动化程度上存在一个临界点，超过这个临界点，频繁的运输就成为可能。根据我们的经验，我们发现以下因素对于达到临界点至关重要：船宝贝船！这是我们每个Jenkins管道中的阶段的名称，它将对单个微服务所做的更改部署到相关的环境中，包括生产环境。团队中的任何人都必须简单可靠地发布更改。代码即配置：我们有太多的配置是显式的，不在git中，网站自助建站系统，以至于大部分部署都需要在"Ship baby Ship！"之前进行手动设置！"可以跑。我们开始将配置拉回到每个微服务的代码库中，除非是全局环境设置或安全参数（那些属于更安全的密钥管理存储库）。最终，大多数部署都是完全自动化的。回归自动化：使其进入登台环境的更改必须快速找到进入生产环境的途径。在大多数自动化套件通过了85%的测试用例自动化之后，我们发现自己在几个小时内就把变更推到了登台阶段。关键是要在新功能不断推出的情况下保持这一覆盖水平。                     在我们的Jenkins服务器中的单个部署管道中的阶段一旦团队习惯了使用自动化部署进行部署，每个新的服务都将开始使用完全自动化的管道，利用现有的模板。建筑与自由度当一个变更准备好部署到生产中时，通常阻碍它的是冲突——另一个变更正在争先恐后地部署，但可能会破坏原来的变更。这些冲突通常是通过确定一个顺序来解决的，在这个序列中，关联的更改可以在不中断的情况下展开。当然，这是以阻碍释放管道和施加背压为代价的。生产型工程师不喜欢背压。模块化体系结构图片来源：Raphael Koh当变更被模块或组件分开，或者更好地说是服务边界时，发生冲突的概率会大大降低。代码库和部署体系结构越细化，大数据数据库，两个更改相互冲突的可能性就越小。这并不意味着高度分散的体系结构必然是一件好事——随着碎片的增加，理解、管理和实现变更变得越来越具有挑战性。如前所述，我们有幸从面向服务的体系结构开始。该体系结构允许我们计划更改，以便将它们分布在我们的服务中，并尽可能独立地进行发布。联轴器我们确实有另一组问题源于与一个消耗我们服务的Freshworks产品的耦合。不幸的是，我们最初的架构与Freshdesk的耦合太紧密了。这要求与Freshdesk同步部署，我们已经习惯了。当我们将目光转向更多的Freshworks产品时，在多个产品之间进行锁定部署显然不是一个开始。我们有意识地决定对Freshworks产品的许多接口进行一次架构清理，这个平台将在生产中使用。这是一项艰巨的任务—我们还没有完成—但是每个解耦的接口或服务都为我们提供了额外的自由度。通过每次分离，我们可以在希望的时候更频繁地进行部署，而不是与来自Freshworks产品（或者更糟的是，多个Freshworks产品）的部署进行协调。投资于足够模块化和解耦的体系结构恰好是每天部署的难题中的一个关键部分。人与文化在促成频繁部署的所有因素中，在运输变化中寻找乐趣的文化可能是最重要、但也是最被忽视的方面。由一组工程师通过一个单一的mi驱动，可以取得很多成就