标签：角色 本地 ops 分支管理 net 策略 ide 扫描 私有
当今 IT 行业发展中比较流行的几个技术，首先是微服务化，将原有的一个系统拆分成多个，意味着有多个系统需要构建、测试、部署和运维。
第二个是敏捷开发模式，需求粒度更细化，要求一个可独立部署单元快速开发、快速测试、快速部署上线，实现快速迭代。
还有一个就是容器化，随着容器技术的快速发展，越来越多的应用迁移到了容器上。
这时候就会出现一些问题，如果当下软件交付继续使用传统模式，就会需要花费大量的人力物力，同时有大量的重复部署任务，且交付无法做到快速型。那么有没有一种更好的交付方式满足当下的软件发展趋势呢？答案肯定是有的，正是在这样的背景下，DevOps 横空出世。
DevOps 是 Development 和 Operations 的组合，即开发、运维一体化。通俗地来说就是通过一系列工具及制定一些规范，尽可能地实现软件交付自动化，同时保障软件交付质量。
DevOps 总得来说有以下几大特点，首先是自动化，通过引入一些列工具，实现从需求到上线整个交付工程自动化，必要环节进行人工确认。
第二点是规范化，单有工具是不行的，需要一系列的规范支撑，比如版本管理规范、测试管理、测试数据管理等。
第三点是缩短交付周期，交付过程基本是一键式或者全自动，省去了中间不必要的环节，缩短了交付周期。
第四点是交付质量有保证，交付过程中可以引入静态代码扫描、单元测试、接口测试等环节，并对每个环节设置质量门槛，降低了生产出现 bug 的概率，真正做到了防患于未然。
基于以上四个特点，我们整个产品有了相应的提升，交付过程自动化解放了劳动力，又保障了交付质量，自然会带来更大的收益。
版本控制系统（VCS）也叫源代码管理系统，顾名思义，提供最基本的版本控制功能，他会在文件修改的历程中保留修改历史，让用户可以方便地查看该文件的修改历史。并且可以方便地让用户撤销对文件的修改。
目前业界使用比较广的版本控制系统主要有两个，首先是 SVN，它是一个开放源代码的版本控制系统，基于 CVS 发展而来，用于多个人共同开发同一个项目，共用资源。简单、上手快，易操作，但是无法实现分支管理，比较依赖网络。
第二个是 GIT，它是一款免费、开源的分布式版本控制系统，用于敏捷高效地处理任何或大或小的项目，作为一个开源的分布式版本控制系统，可以有效、高速地处理各种项目版本管理，可以实现很好的分支管理。
持续集成这一块也给大家介绍一款常见的工具——Jenkins，相信很多小伙伴都使用过，它是一个开源自动化服务器，作为一个可扩展的自动化服务器，Jenkins 可以用作简单的 Cl 服务器，或者变成任何项目的持续交付中心。它的社区非常活跃，插件也较为齐全，可以集成打通需求管理、版本管理系统等。
持续测试这块我们会有一个测试分层，分为单元测试、接口测试、联调测试。单元测试是方法级的测试，开发同事需要针对源码编写测试类，目的是为了验证功能代码是否有问题，可以使用 junit+jmock 实现，对接到 pipeline。
接口测试是针对外暴露的接口或者为本系统提供服务的方法进行测试，需要编写测试案例，可以将 Jmeter 集成到 Jenkins 上实现接口自动化测试 及结果收集。
而联调测试是指系统间连通性测试，需要人工介入。
我们部署的东西不仅仅只涉及到应用部署包，还会牵扯到一些配置文件以及数据库脚本。配置文件在大多数情况下是与环境进行绑定的，每套环境使用一套配置文件，需要对配置文件做统一管理，发布时选择对应文件或者动态替换。
数据库脚本需要将 SQL 变更文件纳入到版本管理系统中，发版时增量执行变更 SQL。
持续集成将构建包推送到制品库中按照一定规范管理起来，部署时从制品库中拉取对应版本的应用包部署。应用可能部署到物理机，有可能是虚拟机、私有云或公有云。
在整个交付环节中，版本控制是最重要的一块，而版本控制又跟分支策略有关。如果前期分支策略做得不好的话，后期的版本控制肯定是很糟糕的。只有前面做好了，后面才有做好的可能。
这里相信小伙伴们都会有一定的了解，分支管理可以帮助我们避免代码的丢失，如果没有合理的分支管理，在某个功能还没有开发完，代码推送到远程会影响其他功能，如果不推送到远程仓库中，本地数据丢失会导致代码丢失。
同时，分支管理还可以提高代码质量。设置分支权限后，feature 分支向主干分合并需要 master 角色 review 评审，保障了主干分支代码质量。
最后，随着软件的迭代，版本号也随着变更，为了追溯每个版本的需求、变更集及线上 bug 修改，需要设计合理的分支策略并管理到需求和部署包。
首先，合理分支策略肯定要符合业务场景。没有最好的，只有合适的，设计符合自己业务场景的分支策略还是最关键的。
第二，分支层次结构清晰。清晰的分支层次结构能更好地体现每个分支的功能。
第三，避免形式主义。不应该为了做分支管理而设计多层而设计多层分支，导致一次提交需要多次合并，失去了高效支付效果。
最后是权限控制，需要对主干分支设置相应权限，只有指定人员才有权限合并，提高代码质量。
所有的交付过程都是基于 pipeline 做的，pipeline 俗称流水线，在 Jenkins 中也被称为 job，多个构建单元组成一条流水线，如代码编译、单元测试、代码扫描组成一条 pipeline。编排一个 pipeline 有两种方式：在 Jenkins 界面配置化实现以及编写 Jenkinsfile 文件来实现环节的编排。
我们主要推荐用 Jenkinsfile 进行编排，因为在当前的业务场景下，我们的建议是“一切配置皆代码”，这样能保证我们的所有配置是代码化的，即使我们的 Jenkins 服务器挂掉了或者被人删掉了，我们的 Jenkinsfile 也能存放在源代码管理系统中。
Jenkinsfile 是 Jenkins 可识别的脚本文件，以代码的形式将所有的构建步骤按照一定的语法写入到该文件中，创建 pipeline 是指定该文件路径。
我们将在完整视频中，继续为大家带来几种场景下的分支策略，以及 Pipeline 的设计、度量、反馈。点击观看完整视频。
CODING DevOps 系列第一课：基于开源工具链打造持续交付平台
标签：角色 本地 ops 分支管理 net 策略 ide 扫描 私有
原文地址：https://www.cnblogs.com/codingdevops/p/13153188.html
