全文共字，预计学习时长8分钟
源代码控制是软件开发中不可或缺的一部分。对源代码进行恰当的存储和管理将极大地方便工作，特别是当大型产品团队持续发布代码时。
在微软公司，仅是负责产品开发与测试的团队就拥有多名员工。试想一下，在如此之大的一个团队中，若是代码未能得到恰当的维护与发布，这该是一场多大的噩梦啊。
今后，对于几乎所有的软件开发公司来说，代码发布管理方案及其流程要求都会非常相似：无缝地对代码进行管理，并进行适当的版本控制，从而在产品开发以及生产的过程当中，加快代码周转时间。
先从源代码控制系统——分布式版本控制系统（GIT）说起。
通常，代码管理是在四个不同类型的GIT分支当中完成的。这四个分支为：
·主分支/开发分支(有时二者同时存在)
·功能分支
·发布分支
·热补丁分支
我们以产品天睿公司数据库引擎+机器学习引擎为例，这款产品现已在Azure上架并提供相应服务。
来设想这样一个情境：假设现在需要将Viewpoint与Unity这两款天睿公司的专利附加产品和数据库引擎整合起来。
注：上述情境纯属虚构。支持以上附加功能的数据库已在Azure上提供相应服务，并已在用户中普遍推广开来。
经过整合，这两款附加产品会成为可以同时使用的两项功能。
同时，假设我们还要考虑到这样一个问题：由于Viewpoint这个软件相对复杂、难以掌控，因此Viewpoint整合完成并投产的时间要比Unity晚一个月。
发布过程的总体要求如下：
·对于团队成员来说，所采用的方法应该足够简单，以便他们快速上手编写代码。
·具备能快速修正已发布代码的灵活性，保证在生产时不会出现不完整且不必要的代码。
·能够用合适的方式追踪记录已发布的代码；另外，不是所有的用户都会即时将自己使用的产品代码更新到最新版本，因此我们也希望可以同时刻支持已发布代码的不同版本。
在下面有关于Git流方法的介绍中，我们先会探讨“如何利用Git流管理已发布代码”这个问题，再介绍微软发布流策略，最后，还会讨论一下团队整合方面的建议。
GIT流方法
GIT流方法始创于年，由文森特·德赖森（VincentDriessen）提出。直至今天，这个方法仍为众多产品公司广泛使用。那么现在，就让我们在Git流中构建出上文提出的假设。
主分支与开发分支
·用以支持天睿公司产品在Azure上提供稳定服务的主要生产代码会出现在主分支上。这条分支是用来存储到目前为止所有已发布功能的官方发布历史记录。
·开发分支作为一个整合分支，会把发布的各个代码汇总到主分支上。在创建主分支之后，开发分支会从主分支中分离出来。
功能分支
·为了整合Viewpoint以及Unity，开发人员要将代码开发为两个不同的功能分支，然后再将这两个分支合并成一个开发分支。
·多个开发人员可以根据自己的细化任务在各自的子功能分支上工作，然后将代码合并到主功能分支上，以便最终完成该功能。
·一旦某个功能分支开发完毕，开发人员就要将其不断更新，使之与开发分支保持一致，这样就可以很好地检查编写进功能分支的新代码，并对其完成合并工作，从而确保产品的质量保证（QA）。成功保证QA后，这一功能分支就会重新合并到开发分支上。
发布分支
·在假设中，开发人员要首先发布Unity的整合版本。开发人员要先将功能分支合并到开发分支，再从开发分支当中分离出一支发布分支。
·这个发布分支可能会成为最终产品，并且会根据发布计划与发布标签的情况合并到主分支上。
·其他功能的开发并不会受到影响，因为在这些功能发布之前，它们是不会合并到开发分支上的。
·使用此发布分支方法将使查看发布级别的变更日志变得更为简单。
热补丁分支
·假设天睿公司的数据库引擎在某个特定的Azure服务区（假设为中国服务区）中无法与Unity连接，这便形成了一个实时服务的程序故障。
·为了处理这一程序故障，开发人员要从主分支中创建一个热补丁分支，再在热补丁分支上修正该故障。测试结束后，该补丁分支会与开发分支和主分支合并。
·当新功能通过不同的发布分支合并到主分支时，需要在开发分支上合并，以避免补丁分支被覆盖。
Git流方法的优点？
·开发人员可以很清楚地了解到哪些是实时功能、以及这些实时功能是何时启用的，同时还可以对这些功能进行控制。除此之外，开发人员还可以在代码库中针对不同的功能用合适的方法管理发布历史。
·由于未发布的候选代码肯定会被检入到开发分支当中，这些代码的开发不会因即将创建的发布分支而受到影响。
·开发人员可以将单个功能分支设置为受保护的Git分支，并且通过拉取请求的方式将特定的开发人员子功能分支的代码合并到主分支中，这一操作可以增强检入安全性。
Git流方法也可能会增加开支？
·要使这种方法发挥完美效果，开发人员就要保持警惕，确保所有热补丁分支都已合并到主分支和开发分支上。如果未能成功将相关分支合并到开发分支上，程序故障等问题还会重新出现在之后创建的发布分支中。人为的小失误可能就会对生产造成重大影响。
·操作中涉及分支数量极多，因此即使是升级一个小功能，发布工作也会变得十分繁重。
微软发布流
为了降低Git流的复杂性，提高代码的生产速度，整个微软公司正朝着“工程系统一体化”的方向发展。VSTS团队等微软内部团队采用的是比Git流更为简单的分支方法。
虽然Git流方法在管理及发布代码方面相当，但对于大型团队来说，管理如此多的分支和层次体系仍然十分麻烦。另外，鉴于其合并热补丁分支的方式，Git流方法可能会导致频繁的合并冲突（详情请参阅“缺点”部分）。
接下来看一看如何在数据库引擎的帮助下用微软发布流方法整合Unity和Viewpoint。通常在这种情况下，开发人员要用到的分支种类会更少一些。
主分支
·这一分支是每次合并的中心支柱。天睿公司的代码为Azure提供服务，而在发生合并的这一特定时间点上，该分支则是这些天睿公司代码的真正来源。
·单个主题（如用于整合Viewpoint的代码）以及热补丁分支要合并到主分支上，而发布分支是从主分支上分离出来的。
主题分支
·每位开发人员都要从主分支中分离出主题分支，并在主题分支上完成大量工作。这一分支可能会包含用于特定功能的少量代码，抑或是小故障修正，等等。
·在假设中，Viewpoint和Unity两个功能的开发都要由多个开发人员在不同的主题分支上进行。
·目标代码完成后，开发人员需要通过拉取请求的方式将主题分支合并到主分支上。
·通常情况下，发布流方法并不要求开发人员将子主题分支合并到某个母主题分支，然后再将该母主题分支合并到主分支上。这是为了降低整个操作的复杂程度。
发布分支
·当代码需要在特定时间点投入生产时，开发人员就要从主分支中分离出一个发布分支。例如，在按照计划将Unity与数据库整合在一起，并完成了相应的开发和测试工作后，开发人员会创建一个新的发布分支。
·采用敏捷方法的团队往往会在迭代周期（sprint）的最后创建发布分支，sprint中的各个任务也是如此定义的，从而可以使其在sprint结束时作为开发成果投入生产。
·一旦创建了新的发布分支，开发人员无需再保留旧发布分支。新发布分支需要从主分支上分离并创建出来，这是因为主分支的代码是最新的，而且它也已经弃用/删除了旧发布分支。
热补丁分支
·开发人员若是需要通过修改生产代码的方式紧急修正程序故障，通常会创建热补丁分支。
·相比于Git流，微软发布流热补丁分支的操作有很大不同。
·当需要修正程序故障时，开发人员会从主分支中分离并创建出一个普通分支，然后按照常规的方法修正并测试，最后将其再次合并到主分支上。之后开发人员还会选择性地把修改的代码同步更新到发布分支上。
·这种方式可以确保修正补丁一定会出现在主分支上。
·只有成功发布的代码才能实时修正程序故障，因此产生合并冲突的可能性极小。
发布流方法的优点？
·由于所有程序故障、热补丁以及功能开发代码都会首先检入到主分支上，所以主分支上的代码一定会更新为最新版本。这可以帮助开发人员更好地管理代码发布，对自己的工作更有信心。
·鉴于只用到了一个主分支，且没有创建开发分支，因此代码发布的管理工作会简单许多，这一点在团队壮大的过程中会变得尤为明显。
·这一方法会非常适合我们团队，因为我们在开发并发布代码时采用的是敏捷开发法。
发布流方法也可能会增加开支？
·由于所有分支都是从主分支中分离出来的，且所有的分支最后又都会合并到主分支上，因此要想让那些不会发布的发布分支上的代码保持不变，还是比较困难的。
·为了防止那些不完整的功能、甚至是被禁用的功能被发布并生产，制作发布时间轴和进行工作隔离时必须保证没有失误。
二者结合扬长避短
根据对自身需求以及对Git流和发布流的了解程度，我们决定采取一种中庸之道——取二者优点总结而成的一种新方法。
新方法遵循微软发布流的方法原则，但有以下两个主要变化：
·创建一个母主题分支/母功能分支，并按常规要求进行拉取请求，从而将母主题分支/母功能分支中与某功能相关的代码合并起来。只有当完全开发并测试过某功能后，开发人员才会将其合并到主分支上。
·先从发布分支分离并创建出一个热补丁分支，将该分支合并回发布分支后，再将更改选入到主分支当中。这样我们就可以确保只有热补丁分支被合并进了发布分支，同时也能确保热补丁分支成功合并进了主分支。
用正确的方法管理代码不仅有助于减少程序故障的发生，还有助于推动发布工作的合理规划以及正确维护。若是采用此种方法，开发人员就很有可能将发布周期缩短至一个月，基于Pipeline的CI/CD也会相应得到更多应用。
留言点赞
转载请注明：http://www.0431gb208.com/sjszjzl/7455.html
