威哥Wego的专栏

在快速发展的技术领域，我们对“高质量交付”的要求越来越高，但面对复杂的系统、频繁的迭代和跨团队协作，如何在开发过程中保障质量？很多团队尝试过后期的严格测试和检查，却发现问题往往埋藏在开发早期。于是“质量内建”理念应运而生。它通过系统化的实践，帮助团队从一开始就把质量融入开发流程。今天，我们将带你深入了解这个重要的理念。

智能端点指的是微服务自身拥有较高的智能，能够处理复杂的逻辑和任务。哑管道则指的是服务之间的通讯通道尽量简单，不包含业务逻辑，仅负责消息传递。这种设计的核心思想是将复杂性转移到服务内部，使得通讯机制保持简单。

在前一篇文章中，我们探讨了微服务的基本定义及其架构风格。在这篇文章中，我们将进一步分析微服务架构的九大特性，重点讨论“经由服务组件化”这一特性。通过乐高积木的比喻，我们深入理解了组件、服务和库在微服务中的角色和区别，并分析了服务组件化的优缺点。

让我们来看看Martin对于微服务的定义

本篇是对汽车行业和互联网行业（2B和2C业务）分支管理现状的总结，以及演进趋势的预测与洞察。如果大家感觉这些内容对自己的工作还具有一定的借鉴意义，还请帮忙关注、点赞、转发，让更多的朋友能够了解。

通用分支模型对比，包括Git Flow/GitLab Flow/GitHub Flow/Trunk Based Development

今天给大家带来的是另一家新势力车企的分支管理模型总结。该公司采用多分支管理策略，包括主分支、开发分支、发布分支和热修分支，同样也是按代际划分进行独立演进。其半敏捷流程结合平台化概念，旨在减少车型差异，提高代码质量和产品发布效率。然而，当前缺乏明确的多项目同步策略，存在一定的改进空间。

某新势力车企采用了多分支管理策略，主要分为主分支、开发分支、预发布分支、特性分支和热修分支。其分支模型按代际进行划分，每个代际的分支模型与Git Flow基本一致。该模型在提高代码隔离和质量方面有一定优势，但在多项目并行情况下存在较高的同步成本和进度冲突问题。

今天和大家分享的是某互联网大厂的分支管理规范。该企业采用了大规模敏捷（LeSS）框架，通过明确的分支定义和管理策略，确保了高效的产品迭代和技术交付。其分支定义包括主分支、集成分支、支持分支、发布分支和热修分支，每个分支都有明确的生命周期和质量保障措施。交付流程涵盖了从需求优先级确认到正式发布的各个环节，充分利用自动化工具提升发布效率和质量。

今天和大家分享的是某独角兽级别、ToB领域 SaaS 平台的分支管理模型。该企业的产品、研发人员规模约 200 人，总用户在 500w 左右。通过采用简化版的大规模敏捷交付流程，明确的分支定义和管理策略，确保了高效的产品迭代和技术交付。其分支定义包括主分支、预发布分支、测试分支、特性分支和热修分支，每个分支都有明确的生命周期和质量保障措施。交付流程涵盖了从需求优先级确认到正式发布的各个环节，充分利用自动化工具提升发布效率和质量。

Trunk Based Development（TBD）即通常所说的主干开发。其实与其说TBD是一种分支模型，不如说是在Git诞生前受工具限制所不得不采取的开发模式。TBD模型早就已经存在，trunk为英文中树干的意思，是代码库的主要开发线，在之前的CVS和SVN时代大部分的软件研发都是这种模型，CVS中的Trunk目录的名字就是主干的意思。所以Trunk Based Development泛指在单一主干分支上协同开发的实践。

GitLab Flow是指利用GitLab工具平台来帮助团队更有效地协作和管理软件项目而采用的一种通用开发流程。GitLab Flow的核心思想是建立在Git分支模型及管理实践的基础上，结合GitLab的功能，以实现团队协同开发、自动化测试和持续集成和持续部署（CI/CD）。其目标是提供一种简化、可伸缩和可维护的开发流程，以便团队可以更频繁地交付高质量的软件。它强调了代码审查、自动化测试和持续集成，以确保代码的稳定性和可靠性。

GitHub Flow 起源于 GitHub 的内部开发实践，旨在提供一种更加灵活、简单的方法来适应现代软件开发的快速迭代需求。它强调简单性和快速迭代，只需一个常驻的主分支（main 或 master），所有的功能开发、修复和改进都在从主分支派生的短暂功能分支上进行，因为其简单清晰的特点，一经推出就迅速的被大量的开源社区项目所采用。

Git Flow是由 Vincent Driessen（文森特·德里森）在2010年提出的一种基于Git的工作流程。Vincent在他的博客文章《A successful Git branching model》中提出了Git Flow，提供了一种可靠的分支管理策略。