云原生时代，企业如何选取、落地研发模式 _云效流水线落地研发模式

【云原生时代，企业如何选取、落地研发模式】

文章插图

云原生是近几年IT圈最火热的词汇之一，几乎每一个云计算产品都会或多或少跟云原生发生关联。那到底什么是云原生？它对企业的项目研发又有什么样的影响跟要求？云原生这个大的时代背景下，企业又应如何落地相应研发模式来提高研发效率，提升企业竞争力呢。

容器是云原生变革的根本，其他的东西都是基于这个基础所引申和集成起来的。
云原生时代的软件研发要求：快、稳和省。
研发模式选择取决于是持续发布的方式还是版本制发布的方式。
通过分支模式和工具平台，可以从繁琐的手工工作中解放出来，让我们研发协同的效率更高。

云原生变革的根本什么是云原生？2019年Pivotal官网给的定义，云原生关注4点，包括：DevOps，持续交付，容器以及微服务，这里我们只把容器凸显出来。因为其他三个并不是云原生所特有的，我们本来就在做这样的一些事，这里唯一的区别就是容器。容器就像集装箱，它成了一个标准，成了这几年云原生研发的一个底座，基于这个底座，再集成持续交付、微服务和DevOps等实践，就组成了我们通常所说的云原生。云原生时代软件开发的特点随着云计算的发展，越来越多的企业开始上云，企业上云的第一个前提条件就是能够基于云上的这些服务提供更好的业务需求的响应能力，需要更快。其次，因为现在企业很多基础设施也在云上，比如说一些金融类的服务也慢慢上云了，这要求服务要非常的稳，不能出现问题，不管是安全问题，还是稳定性问题。第三，有这两个基本条件之后，企业希望投入的成本能足够的低，成本可能包括两方面，一方面是物理上的，硬件上的设施投入，比如ECS等，另外一个是我的人力成本，不管开发也好，运维也好，在这上面投入的人力成本要尽可能的低，所以总结下来就是三个字，快、稳和省。接下来，我们看一个企业的实际场景问题，为什么团队变大了，发布却变得更困难了。这是个很典型的问题，尤其当一个团队，从十几个人快速发展到一百多个人的时候，是非常明显的。原来一周可以发个一两次，但是到了100多人的时候，可能一个月才能发一次，这背后的原因，就是协作变复杂了。有一个研究报告提到，有效的研发时间，在整个项目周期中可能是不到20%的，大量的时间都是在做各种协同的事情，本次分享我们主要去讲怎么去解决这类问题。协同问题，严重影响研发效率，如何为研发团队设计合适的研发模式持续发布or版本制发布我们从大家的发布形态去看怎么去设计合适的研发模式。比如我给银行做项目半年或者三个月给他一个版本，那个版本是明确的，发布什么东西很明确，这个时候认为它是版本制发布的方式，如果是另外一种，比如只是一个在线的服务，这个服务我不关心历史版本，只要最新的服务ok就行了，我们认为它是一个持续发布的方式。持续发布的研发模式：只分支合并一次持续发布的特点是分支只合并一次，即从feature分支合并到master，它以一个特性或者需求为单位，开发完、验证完就可以发布，所以这个时候发布的粒度是一个feature 。当代码在feature分支上做提交后，会自动的做一些单元测试和扫描，然后做构建，然后部署到测试环境，在上面做一些自动化测试，之后可能会做一些人工的验证，然后部署到UAT环境，做一些验收和审核。如果审核通过了，就合并到主干，然后部署到生产环境，整个过程非常清晰顺畅。版本制发布研发模式版本制发布方式特点是分支合并两次。这里面有一个feature branch，一个master，一个release branch 。master就是主干，主干是长期的分支，存放最新的发布过的、可用的代码；feature branch是特性开发的分支，每做一个特性开发的时候，会拉一个feature branch，在上面进行开发和自测。要做发布的时候，会拉一个release branch，release branch也是临时的分支，之后，所有符合条件的feature branch就会合并到release branch，在release branch上做集成验证和测试，验证通过了，并且通过验收之后，会合并到主干，然后部署到生产环境，这个就是版本制的方式。这里有两次代码合并的过程，第一次合并是从feature branch合并到release branch，第二次是从release branch合并到master 。云效流水线落地研发模式研发模式怎么在云效上落地？首先，我们会在云效上建立两条流水线，一条dev流水线，即开发流水线，一条release流水线，即发布流水线。开发流水线的话，它的触发源就是feature分支一次git push，之后自动的去做一些代码扫描、单元测试、构建或者是测试环境部署，也可以到上面去做自动化测试，云效流水线都是支持的。开发流水线运行通过后，我们可以根据需要，将feature分支合入到release分支，此时就会触发我们的第二条流水线也就是release流水线运行。release流水线的会在上面同样去做前面的那些动作，但是会额外有一些管理员的卡点，包括一些UI测试，SIT测试等等。验收通过后，会发布到UAT环境，并且做PO验收和运维审核，最后合并master，然后生成一个版本，并且部署到正式的环境中。这就是版本制发布的一个研发模式，它的特点跟刚刚比会多一次分支合并操作。