精华内容
下载资源
问答
  • 配置管理之三类配置
    万次阅读
    2018-02-22 15:19:13

    三库管理原则

    项目配置管理的库分为开发库、受控库、产品库。这三个库是相互独立的物理库,其中受控库在逻辑上分为配置库和基线库。

    1.1 开发库

    存放代码、脚本等开发过程中的产物。由开发人员使用。

    只有开发人员可读和写。开发人员在配置项写入时,必须填写注释信息以标识配置项的功能;配置项变更时注明变更理由。

    例如:http://192.168.1.1:3000/TD_GROUP/gateway_portal.git

    1.2 受控库

    保存已被批准的配置项(包括基线)或项目统一管理的过程资产记录,由配置管理员管理与维护。分两类:

    1、 受控基线库

    存放基线类配置项,由项目配置管理员管理和使用。其变更需要经CCB评审或项目经理批准后,由配置管理员负责检入、检出。

    例如:开发人员在源程序编码完毕并自测通过后,提交配置管理员将代码入基线库。

          架构人员提交经过评审的系统设计文档。

    2、 受控文档库

    存放各类计划、项目的支持性记录等不是基线的配置项。受控文档库由其项目经理指派人员维护其变更,可不是配置管理员。其变更不需要经过CCB或项目经理审批。

    例如:周报、会议纪要、检查单等记录性文件。

    1.3 产品库

    保存发布基线的配置项。作为最终产品存放在产品库,等待交付客户使用,出入库要严格办理手续。

    例如:通过系统测试的程序包。

    更多相关内容
  • JAVA 配置管理库 typesafe.config

    千次阅读 2017-07-27 18:13:14
    Typesafe的Config库,纯Java写成、零外部依赖、代码...它也是Akka的配置管理库。特性: 纯java实现,无任何依赖 充分的测试 支持: Java properties, JSON, and a human-friendly JSON superset 可以合并各种格式的配置

          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;
            }
        }
    展开全文
  • 配置库管理及版本管理规范

    千次阅读 2019-01-08 19:50:56
    配置库管理及版本管理规范               版本信息 A代表新增,M代表修改,D代表删除。 版本号 发布日期 提交人 A.M.D 摘要 V...

     

     

     

     

     

     

     

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

     

     

     

     

     

     

     

    版本信息                                       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. 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. 管理配置服务器,维护代码仓库、安全设置,定期备份代码仓库。
    2. 负责为项目提供全面的配置管理基础设施和环境。包括代码仓库建立、人员添加等工作。
    3. 编写和维护配置管理的相关文档,包括服务器配置管理方法、配置工具使用方法等。
    4. 编写培训材料,制定培训计划,对开发人员和项目管理人员进行配置管理工具使用培训。
    5. 负责构建release发布版本。并解决或指导开发人员解决合并冲突。
    6. 负责解决在使用配置管理工具过程中遇到的问题。

      开发负责人

    1. 管理源代码,构建代码框架,导入配置服务器。
    2. 在配置管理员协助下对源代码进行管理。
    3. 负责同意master分支的合并请求。
    4. 根据项目进展制定开发基线,管理版本编号以及分支版本,必要的时候,负责版本的合并。

      开发人员

    1. 从服务器克隆项目,按照分配的任务,进行分工协同开发。
    2. 从服务器获取代码库最新变更,在自己负责的模块中加入、修改或删除文件。
    3. 及时提交代码到开发分支并附加变更说明。
    4. 负责构建SIT环境版本。

    测试负责人

    1. 制定测试计划
    2. 确认条件不允许时的例外放行。
    3. 跟踪并报告测试工作的进展,发布后撰写测试总结报告,对测试遗漏的问题进行分析。

    测试人员

    1. 编写测试计划、规划详细的测试方案、编写测试用例
    2. 根据测试计划搭建和维护测试环境
    3. 执行测试工作,提交测试报告。包括编写用于测试的自动测试脚本,完整地记录测试结果,编写完整的测试报告等相关的技术文档。
    4. 对测试中发现的问题进行详细分析和准确定位,与开发人员讨论缺陷解决方案。
    5. 提出对产品的进一步改进的建议,并评估改进方案是否合理;对测试结果进行总结与统计分析,对测试进行跟踪,并提出反馈意见。

     

     

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

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

      1. 配置仓库管理规范

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

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

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

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

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

    1.  代码提交

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

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

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

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

        1. 创建

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

        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. 保护分支

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

        1. 项目的可见性

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

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

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

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

        1. 移除用户

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

      1. 灾备策略

    <暂无>

      1. 灾备还原

    <暂无>

    1. 分支管理规范

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

      1. 分支工作流程图

    图 3-1 git flow工作流程图

      1. 分支职责
    1. 主分支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.配置管理员在建立仓库时创建一个master分支和develop分支。

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

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

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

      1. 分支命名规范
    1. 主干分支:master
    2. 开发分支:develop
    1. 创建特性分支,名称要以f-开头,加上特性名
    2. 创建发布分支,名称要以r-开头,加上预发布版本号
    3. 创建Bug修复分支,名称要以b-开头,加上Bug号
    1. 创建标签:
    1. 当软件包发布到UAT环境时要在release分支上打标签,名称要以发布版本号加上RC1,RC2等结尾。
    2. 当软件包发布到正式环境后要在master分支上创建标签,名称要以发布版本号加上REALESE结尾。
    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. 同步远程仓库代码,和远程仓库进行代码合并。

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

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

    4. 同步到主分支上。

        1. 解决冲突

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

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

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

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

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

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

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

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

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

    eg:1.3.4-SNAPSHOT

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

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

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

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

     

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

      1. 软件产品包版本管理

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

    如:V2.15.0_190108_RC1

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

    如:V2.15.0_190108_RELEASE

     

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

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

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

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

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

     

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

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

     

    展开全文
  • 如何有效管理配置三? 项目配置三分别是开发、受控、产品;针对三的关系,概要总结就是:...受控,保存已被批准的配置项(包括基线),由配置管理员管理与维护。信息分两类:受控基线和受控配置项。...

    如何有效管理配置三库?

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

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

    受控库,保存已被批准的配置项(包括基线),由配置管理员管理与维护。信息分两类:受控基线和受控配置项。

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

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

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

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

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

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

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

    展开全文
  • [项目管理]-第十章:配置管理

    千次阅读 2019-05-24 15:36:54
    第十章:配置管理(PPT.279) 1.配置管理的概念(PPT.281) 概念:是项目管理的一项内容,主要涉及对变更进行系统地控制,建立和维护在项目的 整个软件生存周期中软件项目产品的完整性。 主要包括: 1)标识在...
  • Typesafe的Config库,纯Java写成、零外部依赖、代码精简、功能灵活、...它也是Akka的配置管理库. Overview 纯java实现,无任何依赖充分的测试支持: Java properties, JSON, and a human-friendly JSON superset可
  • 配置管理工具SVN的使用

    千次阅读 2018-02-22 15:33:37
    下载地址1、客户端64位V1.9.7 https://tortoisesvn.net/downloads.html 官网地址:https://tortoisesvn.net/2、服务端64位Visual SVN ServerV3.6.4 https://www.visualsvn.com/server/download/ 服务端操作建立 ...
  • 软件配置管理

    千次阅读 2020-11-17 13:25:52
    3,软件配置管理是一种标识、组织和控制修改的技术,软件配置管理应用于整个软件工程过程 4,SCM活动的目标就是为了标识变更、控制变更、确保变更正确实现并向其他有关人员报告变更 5,从某种角度讲,SCM的目的是...
  • 配置管理漫漫谈之典型配置结构

    千次阅读 2010-04-02 11:01:00
    在笔者之前的文章《配置管理漫漫谈之SCM基本知识》中提到配置结构层次:配置一般由动态(开发、受控)、静态(产品)组成。开发:项目成员的工作环境,保存正处于开发/变更的工作产品(文档/源代码)。...
  • 试用配置管理库typesafe.config

    万次阅读 2014-04-29 16:32:03
    Typesafe的Config库,纯Java写成、零外部依赖、代码精简、功能灵活、API友好...它也是Akka的配置管理库 Useage Typesafe的Config库,默认加载classpath下的application.conf,application.json和application.prope
  • 配置管理流程

    千次阅读 2019-09-18 05:23:36
    配置管理流程 1 概要 1.1 内容 规范配置管理活动,确保配置项正确地唯一标识并易于存取,保证基准配置项的更改受控,明确基线状态,在贯穿整个软件生命周期中建立和维护项目产品的完整性和可追溯性。 1.2 适用...
  • 第七章 软件配置管理

    万次阅读 多人点赞 2018-07-02 14:41:56
    本章内容提要软件配置管理的作用软件配置管理的相关概念建立软件配置管理环境版本控制系统集成分支管理变更管理配置审计和配置状态报告配置管理过程软件配置管理工具第一节 软件配置管理的作用星形网拓扑结构不同...
  • 我说CMMI 2.0 之 配置管理

    千次阅读 2019-01-28 11:02:32
    和CMMI1.3相比,CMMI2.0中配置管理的实践基本没有变化。CMMI DEV 2.0 的20个PA中,CM是唯一一个没有3级实践的PA。 基本概念 这个PA涉及到的基本概念比较多,我们挑选部分基本概念,做通俗解释: 配置管理:通过...
  • 配置管理-学习笔记

    万次阅读 多人点赞 2018-11-06 10:47:06
    配置管理 配置管理是描述、跟踪、控制和汇报所有IT基础架构中所有设备或系统的管理流程。这些设备和系统被称为配置项,通过该管理流程实现对所有配置项的有效管理、跟踪和控制,以支持IT服务和基础设施成功运行。 ...
  • 配置管理员岗位职责

    千次阅读 2019-09-18 05:23:37
    配置管理员岗位职责 一、配置经理的基本技能与资格 资格: 能够重视配置管理工作; 能够按规范实施配置管理工作; 积极支持部门的配置管理方面的工作; 能够积极支持与帮助其他人员; 为部门的配置管理能力的提高...
  • 软件配置管理是软件过程管理的重要内容,作为一名软件测试人员。了解软件配置管理的基本知识非常重要。 CMM(Capability Maturity Model,能力成熟度模型)中的3是指:开发、受控、产品。 其中: 开发:保存...
  • 软件配置管理岗位职责说明

    千次阅读 2010-08-22 09:33:00
    软件配置管理岗位职责说明一、配置经理的基本技能与资格 资格: 能够重视配置管理工作; 能够按规范实施配置管理工作; 积极支持部门的配置管理方面的工作; 能够积极支持与帮助其他人员; 为部门的配置管理...
  • 16个最佳软件配置管理工具

    千次阅读 2019-11-09 09:04:10
    配置管理(CM)是一种系统工程方法,用于在产品的整个生命周期内建立和维持产品的性能,功能和物理属性与其设计,要求和操作信息的一致性。它们为您的组织带来了成本效益和更好的时间管理。 当今市场上充斥着各种...
  • 配置库也称为配置,用来存放配置项的工具。主要分为以下三类。 1、开发 development library 存放开发过程中需要保留的信息,供开发人员专用。中信息可能较为频繁的修改,这通常不会影响到项目的其它部分...
  • 项目配置管理计划-完整的范例文档

    热门讨论 2009-03-30 10:10:26
    2.3 配置管理员........................................................................................................................3 3. 软件配置管理计划................................................
  • 配置管理的主要活动

    千次阅读 2019-09-18 05:23:35
    配置管理的主要活动 配置管理的主要活动有12个: 一、配置管理计划 配置管理的目标和范围 与特定的支持小组相关的政策,标准和程序 配置管理角色和责任安排 配置项命名规则 实施配置管理活动的日程安排和程序 与第...
  • 在大型集群和分布式应用中,配置不宜分散到节点中,应该集中管理,为各种业务平台提供统一的配置管理服务。 随着业务的发展,应用系统中的配置通常会越来越多,常见的一些应用配置大致会有数据源配置,数据源组件...
  • 【信息系统项目管理师】第十五六章 配置管理和标准化
  • 软件配置管理与CMM/CMMI-三管理

    万次阅读 2012-08-30 09:08:00
    提供了专门的软件配置管理办法; CMM/CMMI 将软件配置管理的活动分为 6 个方面: SCM 过程管理、软件配置标识、软件配置控制、软件配置状态统计、软件配置审计、软件发布管理和交付。 软件配置管理定义了如下目标 :...
  • kettle-配置资源

    万次阅读 2017-02-08 15:47:45
    打开spoon的时候会弹出一个提示框,让我们连接到资源。... 笔者这里已经配置了两个资源,Oracle和mysql,点击右上角的笔状图标可以对已有资源进行编辑,加号图标可以新建资源,叉号图标可以删除资源

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 957,897
精华内容 383,158
关键字:

配置管理库