SVN多分支开发模式V1.0.1

1目的

规范开发模式过程，指导项目研发、质控测试、DevOps的相关活动。

2适用范围

本规范的作用范围是为互联网软件产品相关项目开发模式的管理过程。

（1）   对项目团队中研发人员在开发模式过程中的活动、职责等方面进行了指导；

（2）   对项目团队中质控测试在开发模式过程中的活动、职责等方面进行了指导；

（3）   对项目团队中DevOps人员在开发模式过程中的活动、职责等方面进行了指导。

3角色及职责定义

（1）   项目研发：需求功能的实现者，分支开发、转测阶段由研发负责人驱动，交付质控提测邮件中需明确六要素：

项目名称、版本号、分支路径、脚本路径、部署手册、功能边界。

（2）   质控测试：为实现版本轮转高效，除日常测试活动外，

测试环境【合并主干并发布测试环境】、

预发布环境【主干测试通过发布预发布环境】、

生产环境【预发布环境验收通过，发布生产环境并完成版本归档等】

由质控团队统一负责服务。

（3）   DevOps：持续交付工具研发和维护，负责版本交付周期过程中的发布支持。

4开发模式

包括单分支开发模式和多分支开发模式。下面分别阐述每种开发模式在项目过程中如何进行。

4.1开发模式

 

                            

（1）单分支开发模式：确定基线、拉分支、合主干、项目发布、版本归档、持续交付。

（2）多分支开发模式：确定基线、拉（特性）分支、同步/回滚/合主干、项目发布、

版本归档、持续交付。

4.1.1单分支开发模式

4.1.1.0确定基线版本

SVN-Trunk：工程Demo – 》特性开发–》 稳定版本

4.1.1.1拉分支

分支来源于稳定主干，稳定主干均需符合以下条件：

（1）   版本已发布生产环境；

（2）   版本已完成版本归档。

4.1.1.2合主干

分支提测合主干

六要素：项目名称、版本号、分支路径、脚本路径、部署手册、功能边界。

4.1.1.3项目发布

4.1.1.3.1持续集成

• 随着软件项目复杂度的增加，对确保集成和软件组件一起工作的要求也就越来越高，因此要早集成，常集成。早集成、常集成，有助于在早期发现项目风险和质量问题，若到项目后期才发现这些问题，解决问题的代价会很大，将导致项目延期或者项目失败。

 

 

l  Jenkins是将代码进行统一的编译打包、还可以放到tomcat容器中进行发布。

通过配置，将以前：编译、打包、上传、部署到Tomcat中的过程交由Jenkins，Jenkins通过给定的代码地址URL，将代码拉取到其“宿主服务器”（就是Jenkins的安装位置），进行编译、打包和发布到容器中。

在Jenkins的宿主服务器中必须要有可以进行：代码clone（Git）、代码编译（Maven）、代码运行（Tomcat）的基本环境

4.1.1.3.2持续部署

Udeployer是一套完整的持续交付生态系统，在交付过程的每一个步骤都是可视化、自动化的，可以带来包括效能在内的显著的好处，自动应用部署也改进了软件的总体质量。Udeployer集合了Jenkins、swarm、docker等工具，在跨网段、跨内外网等方面可以灵活配置。在整个版本交付生命周期（包括部署在内）推荐使用Udeployer，能够把人为的干预最小化、节省各环节等待时间，使得交付的流程更清晰化。一旦把人的干预去掉，质量就更加可预测，会变得更好。

其他自动化部署工具（Ansible、SaltStack）

4.1.1.4版本归档

版本管理是为满足不同需求，对同一产品或系统进行局部的改进和改型所产生的产品或系统系列的变更情况进行记录、跟踪、维护和控制的过程。

版本是记录特定对象各个可选状态的快照，版本管理的任务就是对对象的历史演变过程进行记录和维护，根据实际应用背景选择合适的版本间的拓扑结构，并至少应包括以下功能：（1）新版本的生成;统一、协调管理各个版本；

（2）有效记录不同版本的演变过程及对不同版本进行有效管理，以尽可能少的数据冗余记录各版本。

（3）保证不同版本在逻辑上的一致性和相对独立性，一个版本的产生和消失不会对其

余版本的内容产生影响。

（4） 版本切换时，指定了新的当前版本后，必须保证对象的映象和指定的版本保持一致。

4.1.1.5持续交付

4.1.1.5.1统一源码路径（保证测试环境、预发布环境、生产环境的源码一致性）

（1）分支：由归档后的主干创建，操作人员为项目研发，用于新需求功能实现。

（2）主干：由提测分支合并，操作人员为质控测试；用于功能测试、测试环境、预发布环境、生产环境的运行。

（3）Tag：预发布环境验收通过，发布生产环境并完成版本归档，操作人员质控测试，用于记录生产环境稳定版本，便于回滚主干操作。

4.1.1.5.2统一依赖关系（保证测试环境、预发布环境、生产环境的容器一致性）

（1）  Swarm集群

l  Swarm是一套较为简单的工具，用来管理docker集群，它将一群Docker宿主机变成一个单一的，虚拟的主机。Swarm使用标准的Docker API接口作为其前端访问入口，换言之，各种形式的Docker Client(docker client in Go, docker_py, docker等)均可以直接与Swarm通信。

l  Swarm deamon只是一个调度器（Scheduler）加路由器(router)，Swarm自己不运行容器，它只是接受docker客户端发送过来的请求，调度适合的节点来运行容器，这意味着，即使Swarm由于某些原因挂掉了，集群中的节点也会照常运行，当Swarm重新恢复运行之后，它会收集重建集群信息。下面是Swarm的结构图：

 

 

图1

 

图2

（2）  Docker仓库

• Docker 是一个开源的应用容器引擎，让开发者可以打包他们的应用以及依赖包到一个可移植的容器中，然后发布到任何流行的 Linux 机器上，也可以实现虚拟化。容器是完全使用沙箱机制，相互之间不会有任何接口。

• 仓库是集中存放镜像文件的场所。有时候会把仓库和仓库注册服务器（Registry）混为一谈，并不严格区分。实际上，仓库注册服务器上往往存放着多个仓库，每个仓库中又包含了多个镜像，每个镜像有不同的标签（tag）。

• 仓库分为公开仓库（Public）和私有仓库（Private）两种形式。

最大的公开仓库是 Docker Hub，存放了数量庞大的镜像供用户下载。 其作为默认docker仓库，但在国内下载速度很慢。当然，用户也可以在本地网络内创建一个私有仓库。当用户创建了自己的镜像之后就可以使用 push 命令将它上传到公有或者私有仓库，这样下次在另外一台机器上使用这个镜像时候，只需要从仓库上 pull 下来就可以了。

4.1.1.5.3自动化发布（源码交付和依赖关系交付，通过自动化交付实现）

同上“4.1.1.3项目发布”

4.1.2多分支开发模式

同步/回滚/合主干

 

 

4.1.2.1直接合并主干

提测版本号末位-1与当前主干版本号一致。

4.1.2.2先同步该主干，再合并主干

  （1）提测版本号末位-1与当前主干版本号不一致；
（2）其他分支有归档记录，找到最近一次归档的版本号。

4.1.2.3先回滚上一版本，再合并主干

（1）提测版本号末位-1与当前主干版本号不一致；

（2）其他分支无归档记录；

（3）提测版本号末位-1在历史版本中存在 ， 则需找到主干版本号末位-1的主干。

4.1.2.4先回滚分支对应主干，再合并主干

（1）提测版本号末位-1与当前主干版本号不一致；
（2）其他分支无归档记录；
（3）提测版本号末位-1在历史版本中不存在，则需找到对应的拉分支时主干。