基于Maven profile的配置管理

应用场景

在java项目的开发过程中，配置文件中相关配置项的值是应不同的执行环境所变化的，并且这种变化也可能是事前未知的。

纵向变化-执行者

一种是随着执行者的不同而不同，譬如说开发人员开发过程中debug的环境（简称dev）、个人CI与单元测试环境（ut)、团队CI环境、测试环境可能使用不同类型的数据库和执行环境。

横向变化-时间

另外一种是随着时间的变化而变化的。例如在笔者所服务的公司，通过使用模板机VM的方式提供带系统、数据库和基础数据的开发测试环境给大家使用，但是随着版本不断上线，模板机VM会不断被更新。在模板机被更新后，需要重新clone环境并使用，这时如IP等信息基本都会有变化，因此即使是如团队CI环境，可能也会需要变化。

解决方案1- profile

通过maven profile来针对横向变化的部分来形成一个个profile,在运行时动态选择即可。

解决方案2 - filter

在maven profile的基础上，针对临时变化的部分，可以通过filter在runtime动态指定环境的参数值。

利用spring框架自身提供的profile机制

最终的解决方案

针对公司现有java类产品的开发框架(springMvc)，使用了如下的方式
1、将src/main/resouces下的配置文件复制到src/test/resouces下，对需要参数化的配置项的值进行参数化修改。
key=123 修改为key=${key}
2、在pom.xml中建立dev/ut/ci/qa等profile

    dev
    
    
        true
    
    
        
            src/test/resources/app_dev.properties
        
    


    ut
    
        false
    
    
        
            src/test/resources/app_ut.properties
        
    

3、在pom.xml的部分加入filter，指定需要被替换的参数文件

   
            
                
            
                src/test/resources
                
                    frameworkConfig.properties
                    cfc_config.properties
                    
                true
            
           
             
                src/test/resources
                
                    frameworkConfig.properties
                    cfc_config.properties
                    app_*.properties
                    
                true
            
        
   

这里有个坑要注意，一般在网上搜来的都是profile/filter介绍都是关于标签的，其实对应的是src/main/resouces目录。如果要操作src/test/resources目录，则需要使用标签。
4、在src/test/resouces下建立类似app_dev/app_qa等配置文件，文件中填写相应的配置项的值。
如：key=123
5、在pom.xml的 的filter中增加exclude部分来剔除4中的配置文件，以免污染构建后的二进制文件夹。

        app_*.properties

6、如果有临时变化，不需要通过commit到代码库中，则可以在运行时，通过类似

mvn test -Pdev -Dkey=666

的方式来动态修改key的值。

为什么不用配置中心

笔者所在的公司也建设了配置中心，所有系统在启动时都需要通过配置中心来获取对应配置项中的值。在其设计过程中，除了prod环境外，也规划了dev/qa等环境。 由于配置中心是一个web服务，对于多个开发/测试人员，如果在同时针对某个系统进行开发/测试，但使用不同的环境，其在配置中心的配置项的值也不同，如果使用同一个配置中心，则会造成配置项的值冲突。
现实中，也是通过模板机来部署多套配置中心来规避上述问题。但是在开发/单元测试/集成测试的过程中，我们希望配置值能跟随代码库进行配置管理。

With the above configuration, both main/resources and test/resources folders are treated as resources while the second one should be treated as test resources. Because of that, the resources:resources goal handles not only the config.xml but also test-config.xml and both lands in target/classes properly filtered.
Because of default definition, the other goal resources:testResources copies test-config.xml to target/test-classes without applying the filters (as by default filtering is disabled).