回顾原有的几个概念：
服务：微服务架构，每个项目代码库，都最终打包为一个docker镜像，而这里的服务就是描述这个镜像最基本的配置，描述一个应用最初，最抽象的状态
环境集：一个环境集合，例如测试环境中的某个sandbox环境，生产的统一集群环境。

节点：节点从属于环境，一个环境集下可存在多个节点。如生产环境的多个节点app1，app2
部署单元：部署单元由环境集，节点，服务，三部分组合而成的服务容器(通俗的描述：就是在某个环境集的某台节点部署某个服务，在docker服务下表现为服务容器，运行状态下可使用docker ps查询)

原有的构建步骤：

生产–在没有构建中心之前，服务都是在其他环境通过脚本或者jenkins构建成为镜像，再行手动填写更新服务。
测试–通过tscompose构建并启动服务容器，在对应的测试主机上进行反复操作。

构建中心在在这中间扮演的角色：

构建中心应当是完全替代jenkins进行持续集成的功能模块，在开发此模块的过程中，走了很多弯路。甚至走偏的中心思想。脱离了最初的对于环境集，部署单元的理解。

现在部署中心将与构建环境融为一体，构建从部署配置中来，部署从构建结果中去。而这也是在初期开发构建中心时最为为头痛的问题，如何将构建个发布结合到一起。(历史原因是部署中心走在前，对于构建的问题没有加强考虑，过于片面的理解所谓的构建)

构建需要考虑的问题有以下几点：

1.代码源信息描述在何处？
源代码信息维护在服务的基础信息中，因为不论环境如何变化，单个项目的代码源信息是不会改变的
2.在何处构建，在何处发布？
因为项目内容，环境，配置有所不同，服务在何处构建，存在区别。好比普通的sandbox上构建服务都是构建并发布。不存在运维参与升级，测试环境一个特点就是“快”（快速构建，快速发布，快速测试），针对预发布环境是“准”，预发布环境作为上线前最后一道验证环境。需要确认代码准确，并且不被其他因素所影响，比方说服务器性能等等，所以一般不会在预发布环境进行发布并部署，专门使用一台构建主机，预发布环境作为运行环境。生产环境就和预发布环境没什么区别了
3.代码分支如何切换？
在一个环境进行构建，可能需要频繁的切换分支进行构建（比方在预发布环境构建order项目分支为R_001分支），可以将分支描述在部署单元之上，一个部署单元就可以描述一个构建任务，在部署单元上配置的分支就是构建的分支
4.不同服务的构建方法有所不同，怎么描述构建的过程？
尽管各个项目的构建方式不同，如maven，sbt，npm，shell。最终都是一组指令，将这组指令描述在服务信息中

构建的流程：

1.在环境集中添加主机时，需要指定构建主机(一个环境集下面可不可以有多个构建主机？)
2.服务管理内描述了服务的源代码信息，构建指令，依赖服务信息
3.部署单元既描述部署信息(某个环境集的某台节点部署某个服务),也描述构建信息(构建某个环境的某个服务的某个分支)，通过部署单元对应的环境集查找这个环境集下已经指定的构建主机，而部署节点就是部署单元中所指定的部署节点
4.一个部署单元就相当于构建任务，配置完成后可在持续集成的界面查看其配置改动，开始构建即可在对应构建主机上进行构建，最后在部署节点上进行部署
5.针对服务依赖的管理，首先是从部署单元对应的服务信息中获得服务的依赖树，在构建执行前，查找依赖服务在部署单元中是否存在，如果存在即构建(且这个依赖服务的构建分支由所在的部署单元指定)
6.在部署单元进行部署配置时，填写的镜像tag统一使用latest，将构建所得镜像唯一的tag打包为latest镜像进行持续的构建

1
2
[A:7349d95 => A:latest]
up -d this latest service

随记

  • 环境集管理可指定构建主机
  • 构建的视图环境是类似发布部署的视图，可以选定环境集的么某个服务进行构建/构建并部署