软件开发管理规范

1 容器化规范

在应用的容器化改造规范中，需要考虑的主要因素有：容器的高可用性、容器的运维、容器的安全性、容器的多租户隔离、容器的持久化存储等，容器化的过程中需要符合以下规范和要求：
(一) 建立清晰的可自动化编译和构建过程
使用Maven、Gradle、Make、Shell等工具实现编译步骤自动化
(二) 实现应用配置参数的外部化
基于环境变量或者配置文件的配置管理，便于容器适配不同的运行环境
(三) 提供合理可靠的健康检查接口
平台将通过健康检查判断容器状态，对应用服务进行状态保持
(四) 实现应用状态外部化，应用实例无状态化
应用状态信息存储于数据库或缓存等外部系统，实例实现无状态化
(五) 不涉及底层操作系统依赖及复杂的网络通讯机制
应用以处理业务为主，不强依赖于底层操作系统以及组播等网络通信机制以提高可移植性
(六) 部署交付件及运行平台的大小在2G以内
轻量级的应用便于在大规模集群中快速传输分发，更符合容器敏捷的理念
(七) 启动时间在5min以内
过长的启动时间不能发挥容器敏捷的特性

2 代码管理规范

代码管理我们使用git进行，git是一种较为先进的代码版本管理及协同工作平台，采用分布式文件块存储：
分布式：代码保存在所有协同成员的计算机上，网速较差时依然可用；而传统的集中式代码版本管理系统则较难脱离网络运行。
文件：直接以文件保存整个最新文档，版本提交及恢复速度快：而传统的增量式代码版本管理系统则在每次提交及恢复时都需要对所有的增量进行求和，速度慢。

2.1 git常用概念

(一) 仓库（Repositories）
类似我们生活中的仓库，存储东西，在这是网络或者本地实际存放代码的地方，同一个仓库可存多个项目。
(二) 参照（References）
可以看做是指向文件块中特定代码版本的指针，可沿代码版本有向图进行向前（一般指提交操作Commit）,向后（一般是恢复操作Restore）, 跳转（不同分支间的切换Switch）。
(三) 分支（Branch）
一般是为了进行代码调试或概念开发，从主要的开发版本中分离出一个副版本，并在此基础上进行修改，（实际中我们可以分离出来进行各自的模块开发）使版本有向图呈现分支状态。
(四) 合并(Merge)
一般是为了将代码调试或概念开发分支的代码加入到主要版本中，将对两部分的代码进行比较：
先向后回朔两个分支的最近公共节点，通过与最近的公共节点进行比较，分析两个分支各对哪些文件进行了修改（因为是文件块，所以需要对两个版本的文件求差，传统模式则需要对两个版本的记录进行求和）。
合并最容易产生的错误（冲突）如果某一个文件在 两个版本中均被修改过，则视为“冲突”，这时我们解决的办法是需要人工手动调整其中一个版本，需要确定找到两次提交的相关人员，确定双方修改的内容，进行逻辑的确认合并，切记此处不要随便删除改动一方的提交，一定要找到冲突双方进行确认，否则会造成计划外的错误和问题。
(五) 标签（Tag）
不移动的参照，以标记特殊的代码版本副本，比如说项目的里程碑等

2.2 git常用操作

(一) 新建分支
首先，每次开发新功能，都应该新建一个单独的分支

# 获取主干最新代码
$ git checkout master
$ git pull

# 新建一个开发分支myfeature
$ git checkout -b myfeature

(二) 提交分支commit