本工程是为了针对 beego 工程做持续集成，支持直接开发或者在 CI/CD 链中使用

当然你可以改造这个工程使用别的 web 框架，这只是一种 golang依赖管理 渗透到生产的方案，落地后的产物

• 开箱即用，所见即可开发
• 更少的依赖更新获取，增加开发效率
• 依赖管理不在透明化，可跟踪依赖问题

将依赖管理分离清晰，包括

依赖记录，依赖来源，版本锁定，更新版本，依赖部署

使用 git 仓库和 docker 仓库，git 仓库必须有的是依赖来源管理文件，版本锁定文件， docker 仓库以 tag 提交来记录部署依赖

使用 go dep 或者其他能确认并且记录依赖的工具，或者直接源码放置到镜像制作过程中 不要把依赖放任到本地环境的 GOPATH 中，非要开发过程使用，也尽量做到隔离使用

版本锁定，使用了隔离 $GOPATH(利用 docker 容器环境隔离的效果)，代码资源隔离，是相对软隔离方式，开发和部署分离

代码资源隔离细节，隔离的代码，一部分是在镜像内置了代码资源，当然允许开发过程中修改这些资源，但是在 CI/CD 时强制校验，来达到管理的目的，所以，做自动化部署检查是必须的

更新版本，这个需要先制作一个依赖链才可以做到，对应镜像是这种结构

env_image ->  framework_1  -> work_group_one_framework_1  ->  work_containt_group_one_framework_1
          |
          \   framework_2  -> work_group_one_framework_2  ->  work_containt_group_one_framework_2
                            |
                            |
                            \ work_group_two_framework_2  ->  work_containt_group_two_framework_2

别被图吓到，其实就三层，这里分别涉及到 (框架镜像，业务组镜像，业务镜像)

• env_image 基础镜像，一般是 golang 的官方镜像，不算管理层次
• framework_1 框架镜像，比如当前工程就是框架镜像，为第一层
• work_group_one_framework_1 就是业务组 group_one 使用的 framework_1 的镜像，为业务组层
• work_containt_group_one_framework_1 就是当前开发的业务的镜像， 为具体业务层

开发过程使用的是 work_containt_group_one_framework_1 某个 tag 的镜像，run 时的容器

当然上面制作的所有过程相对应的 git 仓库是有对应命名规则的，也便于记录和管理 更新版本，其实就是更新对应 docker 镜像的 tag

分为 测试部署，灰度部署，正式部署

• 测试部署是直接创建 对应开发业务的镜像的某个 tag，做的实时构建，要求，一旦有错，不得通过，必须修复检查
• 灰度部署，如果使用，就需要在 开发的业务的镜像 复制一份，做到最小依赖，甚至直接使用 二进制包来部署
• 正式部署，同灰度部署，区别是必须加入灾备和监控

我这里对于灰度部署，是技术上的灰度，不是业务上的，技术上的灰度是允许不做灾备，或者监控的，目的就是为了触发问题，如果业务强行需要高安全和可用，那么使用正式部署模式

• beego 框架依赖，其中tag为框架的某个版本，见 Dockerfile