Typesafe的Config库，纯Java写成、零外部依赖、代码精简、功能灵活、API友好。支持Java properties、JSON、JSON超集格式HOCON以及环境变量。它也是Akka的配置管理库。

    特性：

• 纯java实现，无任何依赖
• 充分的测试
• 支持: Java properties, JSON
• 可以合并各种格式的配置文件
• 可以通过文件、urls、classpath加载配置
• 支持多层嵌套的配置方式
• 识别Java system properties, 如java -Dmyapp.foo.bar=10
• 可以转换长短，大小等单位。如配置文件中timeout=10s，则可以转换成任意的毫秒或者类型转换，比如yes可以转换为boolean类型的true:
  comments
  includes
  substitutions (“foo” : ${bar}, "foo" : Hello${who})
  properties-like notation (a.b=c)
  less noisy, more lenient syntax
  substitute environment variables (logdir=${HOME}/logs)

    目前config只支持配置文件，如果想从数据库获取配置文件，需要自己定义。 config库很擅长合并配置。

Example

    默认加载classpath下的application.conf,application.json和application.properties文件。通过ConfigFactory.load()加载。

application.conf：

conf.foo="This value comes from simple-app's application.conf"
conf.whatever = "This value comes from simple-app's application.conf"

application.properties:

properties.foo="This value comes from simple-app's application.properties"
properties.whatever = "This value comes from simple-app's application.properties"

application.json:

{
    "id":1,
    "label":"person",
    "outE":{
        "uses":[
            {
                "id":16,
                "inV":11,
                "properties":{
                    "skill":5
                }
            },
            {
                "id":15,
                "inV":10,
                "properties":{
                    "skill":4
                }
            }
        ],
        "develops":[
            {
                "id":13,
                "inV":10,
                "properties":{
                    "since":2009
                }
            },
            {
                "id":14,
                "inV":11,
                "properties":{
                    "since":2010
                }
            }
        ]
    },
    "properties":{
        "name":[
            {
                "id":0,
                "value":"marko"
            }
        ],
        "location":[
            {
                "id":6,
                "value":"san diego",
                "properties":{
                    "startTime":1997,
                    "endTime":2001
                }
            },
            {
                "id":7,
                "value":"santa cruz",
                "properties":{
                    "startTime":2001,
                    "endTime":2004
                }
            },
            {
                "id":8,
                "value":"brussels",
                "properties":{
                    "startTime":2004,
                    "endTime":2005
                }
            },
            {
                "id":9,
                "value":"santa fe",
                "properties":{
                    "startTime":2005
                }
            }
        ]
    }
}

public class SimpleTypesafeConfig {
    private Config config;

    public SimpleTypesafeConfig(Config config) {
        this.config = config;
        config.checkValid(ConfigFactory.defaultReference(), "conf");
    }
    public SimpleTypesafeConfig() {
        this(ConfigFactory.load());
    }
    public void printSetting(String path) {
        System.out.println("The setting '" + path + "' is: " + config.getString(path));
    }
    public static void main(String[] args) {
        SimpleTypesafeConfig s = new SimpleTypesafeConfig();
        s.printSetting("properties.whatever");//application.properties

        //output: The setting 'properties.whatever' is: "This value comes from simple-app's application.properties"
        s.printSetting("conf.whatever");//application.conf

        //output:The setting 'conf.whatever' is: This value comes from simple-app's application.conf
        s.printSetting("label");//application.conf

        //output: person
    }
}

其中核心加载代码：

config.checkValid(ConfigFactory.defaultReference(), "conf");

底层调用：

    private static ClassLoader checkedContextClassLoader(String methodName) {
        ClassLoader loader = Thread.currentThread().getContextClassLoader();
        if(loader == null) {
            throw new BugOrBroken("Context class loader is not set for the current thread; if Thread.currentThread().getContextClassLoader() returns null, you must pass a ClassLoader explicitly to ConfigFactory." + methodName);
        } else {
            return loader;
        }
    }

 

 

 

 

 

 

 

配置库管理及版本管理规范

 

 

 

 

 

 

 

版本信息                                       A代表新增，M代表修改，D代表删除。

版本号	发布日期	提交人	A.M.D	摘要
V1.0	2019/1/8	杨彬彬	A	初稿

 

 

 

 

 

配置库管理及版本管理规范 1

1. 前言 4

1.1. 目的 4

1.2. 配置库代码管理工具 4

1.3. 角色和职责 6

2. 配置仓库管理 7

2.1. 配置仓库说明 7

2.2. 配置仓库管理规范 8

2.3. 配置仓库权限管理 9

2.4. 灾备策略 12

2.5. 灾备还原 12

3. 分支管理规范 12

3.1. 分支工作流程图 13

3.2. 分支职责 13

3.3. 创建分支规范 14

3.4. 分支命名规范 15

4. 代码管理规范 15

4.1. 提交代码规范 15

5. 版本管理规范 17

5.1. 目的 17

5.2. 项目版本管理 18

5.3. 软件产品包版本管理 18

5.4. 出包步骤 19

 

1. 前言 
   1. 目的

1. 规范项目代码管理流程，明确开发人员和项目管理者的职责。
2. 规范代码库分支管理和版本管理，使代码分支及版本结构清晰，方便维护。
   1. 配置库代码管理工具 
      1. Git介绍

使用GitLab作为代码管理工具，GitLab 是一个用于仓库管理系统的开源项目，使用Git作为代码管理工具，并在此基础上搭建起来的web服务。

Git是一个开源的分布式版本控制系统，用以有效、高速的处理从很小到非常大的项目版本管理。可以实现数据备份、记录历史、回到过去、多端共享、分工合作。

1. 1. 1. Git分层结构

 

git的工作总共分四层，其中三层是在本地，包括了工作目录，暂存区和本地仓库。

工作目录：

执行命令git init时所在的地方，也是执行一切文件操作的地方。

暂存区：

 在.git文件夹目录中，在工作区和版本库中间起缓存作用的一个区域。它通过git add命令添加进暂存区。存储了一些即将被commit的文件。

本地仓库：

在.git文件夹目录中，使用了git commit命令之后添加进的真正的“仓库”。里面存储了每次commit的记录，每次commit一次会让HEAD指针指向新的目录树，而旧的目录就存在版本库中，可以使用命令来提出之前的目录树。

git所存储的都是一系列的文件快照，然后git来跟踪这些文件快照，发现哪个文件快照有变化它就会提示你需要添加到暂存区或是提交到本地仓库来保证你的工作目录是干净的。

进入工作区.git文件夹，如下.git目录或文件结构说明：

目录或文件	说明
config文件	项目的配置文件，里面有中心服务器的信息和分支信息。
HEAD文件	指向当前的分支。
index文件	暂存区的相关信息。
logs目录	相关操作产生的日志。
objects目录	存储的就是所有的数据，也就是快照。 存放的是实际上的文件资源，每次当使用了git add命令之后，就已经把文件存到了objects目录里面。objects目录中的object对象都有一个通过哈希算法计算出来的40位16进制的id，前两位是目录名，后38位是文件名。因为哈希算法可以只比较哈希值，就能知道这两个对象是不是一样的，这样可以提高效率。
refs目录	存储指向数据提交对象的指针。

1. 1. 1. 工作流程

1. 1. 角色和职责

角色名称	职责
配置管理员	管理配置服务器，维护代码仓库、安全设置，定期备份代码仓库。 负责为项目提供全面的配置管理基础设施和环境。包括代码仓库建立、人员添加等工作。 编写和维护配置管理的相关文档，包括服务器配置管理方法、配置工具使用方法等。 编写培训材料，制定培训计划，对开发人员和项目管理人员进行配置管理工具使用培训。 负责构建release发布版本。并解决或指导开发人员解决合并冲突。 负责解决在使用配置管理工具过程中遇到的问题。
开发负责人	管理源代码，构建代码框架，导入配置服务器。 在配置管理员协助下对源代码进行管理。 负责同意master分支的合并请求。 根据项目进展制定开发基线，管理版本编号以及分支版本，必要的时候，负责版本的合并。
开发人员	从服务器克隆项目，按照分配的任务，进行分工协同开发。 从服务器获取代码库最新变更，在自己负责的模块中加入、修改或删除文件。 及时提交代码到开发分支并附加变更说明。 负责构建SIT环境版本。
测试负责人	制定测试计划。 确认条件不允许时的例外放行。 跟踪并报告测试工作的进展，发布后撰写测试总结报告，对测试遗漏的问题进行分析。
测试人员	编写测试计划、规划详细的测试方案、编写测试用例。 根据测试计划搭建和维护测试环境。 执行测试工作，提交测试报告。包括编写用于测试的自动测试脚本，完整地记录测试结果，编写完整的测试报告等相关的技术文档。 对测试中发现的问题进行详细分析和准确定位，与开发人员讨论缺陷解决方案。 提出对产品的进一步改进的建议，并评估改进方案是否合理；对测试结果进行总结与统计分析，对测试进行跟踪，并提出反馈意见。

 

 

1. 配置仓库管理
   1. 配置仓库说明

     配置管理员负责建立配置仓库，以便管理源代码、相关文件及资料。每个开发人员在本地都有自己的版本库，在服务器上有一个公共的版本库。

1. 1. 配置仓库管理规范

根据配置管理的不同角色所分配的不同职责范围，对本地库和版本库进行管理和操作。

1. 1. 1. 远程仓库管理
2. 配置管理员:创建远程仓库、人员添加、权限分配、打标签、构建版本等工作。
3. 开发负责人:导入该项目到远程仓库并完成分支的创建和设置。
   1. 1. 本地仓库管理

本地库由开发人员和开发负责人负责日常的更新和开发工作。

1.  克隆远程仓库，搭建开发环境

开发人员根据配置管理提供的git访问地址，将远程仓库克隆到本地，使工作区可以正常运行起来，并根据分支策略在开发分支上创建分支进行开发工作。

1.  代码提交

开发人员修改完成后提交代码到暂存区，在暂存区域生成文件快照并提交到本地和远程开发分支，由开发负责人来进行代码的审核和合并。建议开发人员及时同步代码，以避免冲突和丢失修改。同时，开发人员必须保证上传的代码是通过编译的。

在开发过程中，很多时候需要对一个项目进行分支操作，在开发分支上对项目进行开发。这由开发人员负责执行。

1. 1. 配置仓库权限管理
      1. 添加用户

新员工入职后，如需配置库权限，可走OA或邮件(抄送部门领导)发送给配置管理员申请权限，待领导同意或OA审批通过后，配置管理员为其创建用户并分配对应权限。用户名生成规则为邮箱前缀。

1. 1. 1. 创建群组

默认只有配置管理员有权限进行群组的创建与编辑(可建子群组)，如有需要可提OA或邮件(抄送部门领导)发送给配置管理员申请权限，待领导同意或OA审批通过后，配置管理员为其创建群组或调整相应权限。邮件或OA里面需要注明具体信息，如：创建群组的名称，或调整群组的具体权限信息等。

1. 1. 1. 用户权限

如需配置库权限，可走OA或邮件(抄送部门领导)发送给配置管理员申请权限，待领导同意或OA审批通过后，配置管理员为其创建用户并分配对应权限。邮件或OA里面需要注明申请的具体信息，如：

姓名：xxx

群组名与角色：atp-bos  master

项目名与角色：ATP/Common  develop

权限截止日期：2019-07-08（永久权限不写此项）

不同角色拥有不同权限，下面列出Gitlab各角色常用权限

1. 工程权限

行为	Guest	Reporter	Developer	Master	Owner
创建issue	✓	✓	✓	✓	✓
留言评论	✓	✓	✓	✓	✓
更新代码		✓	✓	✓	✓
下载工程		✓	✓	✓	✓
创建代码片段		✓	✓	✓	✓
创建合并请求			✓	✓	✓
创建新分支			✓	✓	✓
提交代码到非保护分支			✓	✓	✓
强制提交到非保护分支			✓	✓	✓
移除非保护分支			✓	✓	✓
添加tag			✓	✓	✓
创建wiki			✓	✓	✓
创建里程碑				✓	✓
添加项目成员				✓	✓
推送保护分支				✓	✓
是否保护分支				✓	✓
修改/移除tag				✓	✓
编辑工程				✓	✓
添加deploy keys				✓	✓
配置hooks				✓	✓
切换visibility level					✓
切换工程namespace					✓
移除工程					✓
移除保护分支					✓

 

1. 群组权限

行为	Guest	Reporter	Developer	Master	Owner
浏览组	✓	✓	✓	✓	✓
编辑组					✓
创建项目				✓	✓
管理组成员					✓
移除组					✓

1. 1. 1. 保护分支

默认保护master分支，可使用正则表达式保护分支。保护的分支不能进行push -f操作。

1. 1. 1. 项目的可见性

项目的可见性不能超出群组的可见性范围，项目或群组有三种可见性：

Private:私有，必须配置权限才可进行访问。

Internal:内部，必须进行帐号密码登录后才可进行访问。

Public:公开，所有人都可进行访问。

1. 1. 1. 移除用户

定期清理已离职或调出项目的成员权限

1. 1. 灾备策略

<暂无>

1. 1. 灾备还原

<暂无>

1. 分支管理规范

本公司采用git flow工作流模式进行分支管理。

1. 1. 分支工作流程图

图 3-1 git flow工作流程图

1. 1. 分支职责
2. 主分支master

代码库应该有一个、且仅有一个主分支。它是自动建立的，一般默认此分支是被保护的，版本库初始化以后，就是在主分支在进行开发。此分支除第一次进行原子提交推送外，只能接收其它分支合并，任何人不能直接在master分支上进行修改和提交。

1. 开发分支develop

用于日常开发，存放最新的开发版的一个主要分支。不管是要做新的feature还是需要做bug fix，都是从这个分支分出来做。在这个分支下主要负责记录开发状态下相对稳定的版本，即完成了某个feature或者修复了某个bug后的开发稳定版本，开发完成需要提交测试的功能都必须要合并到该分支。

1. 辅助分支

feature: 开发新功能的分支, 基于 develop, 完成后 merge 回 develop。

release: 准备要发布版本的分支, 用来修复 bug. 基于 develop, 完成后 merge 回 develop 和 master；

hotfix: 修复 master 上的问题, 等不及 release 版本就必须马上上线. 基于 master, 完成后 merge 回 master 和 develop。

1. 1. 创建分支规范

1.配置管理员在建立仓库时创建一个master分支和develop分支。

2.开发人员根据开发的功能点从develop分支创建一个feature分支，当功能点开发测试完毕之后，就会合并到develop分支去，可以将feature分支删除。

3.当需要发布一个版本来测试时，开发人员从develop分支创建一个release分支来测试。

4.正式发布后，过程中出现bug,从master分支创建一个hotfix分支，修补结束以后，再合并进master和develop分支。

1. 1. 分支命名规范
2. 主干分支:master
3. 开发分支:develop

1. 创建特性分支，名称要以f-开头，加上特性名
2. 创建发布分支，名称要以r-开头，加上预发布版本号
3. 创建Bug修复分支，名称要以b-开头，加上Bug号

1. 创建标签：

1. 当软件包发布到UAT环境时要在release分支上打标签，名称要以发布版本号加上RC1，RC2等结尾。
2. 当软件包发布到正式环境后要在master分支上创建标签，名称要以发布版本号加上REALESE结尾。

1. 代码管理规范
   1. 提交代码规范
      1. 目的

为了规范代码库分支管理和版本管理，使代码分支及版本结构清晰，方便维护，并避免由于维护造成的错误的版本发布等问题。

1. 1. 1. 代码提交说明

由对应分支修复的实际开发人员提交或合并到开发分支，开发负责人需要进行判断是否需要合并，并协助解决冲突代码。提交的信息必须按照代码提交模板规定来书写。

1. 1. 1. 代码提交模板

Commit message格式：

type(scope): subject

BugID：如果是修复Bug，请加上Bug号

 

type： 用于说明 commit 的类别，暂时只使用下面标识(后续可完善增加)。

feat：	新功能（feature）
fix：	修补bug
docs：	文档（documentation）
style：	格式（不影响代码运行的变动）
refactor：	重构（即不是新增功能，也不是修改bug的代码变动）
chore：	构建过程或辅助工具的变动
test：	测试用例的修改
ci：	自动化流程配置修改
revert：	回滚到上一个版本
Other：	其它

 

scope：【可选】用于说明commit的影响范围

subject

subject是 commit 目的的简短描述，不超过50个字符。

例如:

feat(ssr): 增加可视化功能

BugID:8023

1. 1. 1. 代码提交步骤

1. 同步远程仓库代码，和远程仓库进行代码合并。

2. 将分支工作区修改的代码和提交描述等提交到开发分支。

3. 开发负责人对提交的分支代码进行审核和合并，并解决冲突。

4. 同步到主分支上。

1. 1. 1. 解决冲突

pull同步工作区，找到冲突文件，解决冲突重新提交。

1. 版本管理规范 
   1. 目的

标识、控制和追踪软件开发和实施过程中产生的各种软件产品版本。

1. 1. 项目版本管理
      1. 版本号约定

<主版本>.<次版本>.<增量版本>-<SNAPSHOT>

主版本：标示项目的重大架构变更。

次版本：表示重大Bug的修复，较大范围的功能增加和变化。

增量版本：一般标示一些小的bug fix，不会有重大的功能变化。

SNAPSHOT：快照版本，只能用于开发阶段对内发布，对外发布时不允许出现SNAPSHOT版本。

eg：1.3.4-SNAPSHOT

【1】代表该版本是第一个重大版本；

【3】表示这是基于重大版本的第三个次要版本；

【4】表示该次要版本的第四个增量版本；

【SNAPSHOT】表示此版本为快照版本；

 

版本号的修改由开发人员根据以上规则进行更改。

1. 1. 软件产品包版本管理

预发布环境：V主版本号.子版本号.增量版本号_日期版本号(yyMMdd)_阶段版本号

如：V2.15.0_190108_RC1

正式环境：V主版本号.子版本号.增量版本号_日期版本号(yyMMdd)_RELEASE

如：V2.15.0_190108_RELEASE

 

主版本号：当功能模块有较大的变动，比如增加多个模块或者整体架构发生变化。此版本号由项目决定是否修改。

子版本号：当功能有一定的增加或变化，比如增加了对权限控制、增加自定义视图等功能。此版本号由项目决定是否修改。

增量版本号：一般是 Bug 修复或是一些小的变动，要经常发布修订版，时间间隔不限，修复一个严重的bug即可发布一个修订版。此版本号由项目经理决定是否修改。

日期版本号:用于记录修改项目的当前日期，每天对项目的修改都需要更改日期版本号。此版本号由开发人员决定是否修改。

阶段版本号:此版本号用于标注当前版本的软件处于哪个开发阶段，当软件进入到另一个阶段时需要修改此版本号。此版本号由项目决定是否修改。

 

当软件包正式发布客户后需要配置管理员进行归档操作。

1. 1. 出包步骤
2. 项目负责人通知项目组准备出包，同时给出出包时间点，如半小时后出包。
3. 开发人员收到出包通知后，尽快将完成的代码进行提交到特性分支，并将特性分支代码合并到develop分支。
4. 提交代码完成后，配置管理员基于develop分支拉release分支，并在构建时根据标签命名标准构造新标签号。如构建失败则通知开发人员在release分支上修改后重新构建。
5. 通过maven和jenkins进行构建、打包和发布部署。
6. 构建完成后通知相关人员。

 

如何有效管理配置三库？

项目配置三库分别是开发库、受控库、产品库；针对三库的关系，概要总结就是：配置三库逻辑上独立，物理上一体，这样能确保配置项历史的可追溯性。

开发库，开发人员的工作空间，开发人员在配置项写入时，必须填写相关信息以标识配置项，配置项支持Checkout\Checkin能力。

受控库，保存已被批准的配置项（包括基线），由配置管理员管理与维护。信息分两类：受控基线和受控配置项。

产品库，作为最终产品存放在产品库，等待交付客户使用，出入库要严格办理手续。

配置项在三库之间进行迁移流动，迁移流动都需要相应的管理过程来支撑，有时还需要进行相应的配置审计。满足以上管理思想的配置三库整体框架如下图：

本人认为满足配置管理规范要求的配置系统，至少也具备如下特征，特征1，配置三库逻辑上独立，物理上一体，三库对应不同管理过程，不同组织的管理审批过程不同，这就要求配置三库平台要能支持管理过程的灵活自定义，满足组织的个性化要求，如下：

特征2，配置审计是配置管理非常重要内容，不同配置管理活动审计关注的要素不一样，系统要具备让组织能够灵活配置不同配置审核要素的能力，如下：

特征3，除了能够很好支持项目级配置管理外，组织级配置管理也是非常重要的管理视角，通过组织级配置管理，可以有效监督检查各个项目配置管理工作开展的有效性，如下：

特征4，配置状态过程记录是一个非常重要的内容，配置状态记录类似一个忠实的记录员，客观记录配置管理的所有操作过程，随时可以进行历史回溯，如下：

这就是我们对配置管理的价值探索，配置管理是研发项目非常基础的管理内容，承担产品成果固化的重大责任，希望以上探索对你有帮助。