持续交付-第二章 配置管理

上一章讲了有关配置管理的内容,存在一些问题,希望在这一章得到答案

配置管理的定义

配置管理是指一个过程,通过该过程,所有与项目相关的产物,以及他们之间的关系都被唯一的定义,修改,存储和检索。

版本控制系统是配置管理中最显而易见的工具,决定使用版本控制工具仅仅是配置管理策略的第一步

使用版本控制工具

大多数的项目都使用版本控制工具,对于开发应用来说,我们可以对每一次的版本的所有文件配置进行保存,并且可以再现一份与生产环境一样的软硬件环境。而且还容易知道软件的错误,并快速的解决。

关于版本控制的建议:

  • 对所有的内容进行版本控制
  • 频繁的提交代码到主干
  • 使用意义明显的提交注释

依赖管理

依赖管理中的关键点,因为她会影响配置管理

  • 外部库文件的管理
  • 组件管理

软件配置管理

软件在构建,部署,运行时,我们可以通过配置信息改变它的行为。要像对待代码那样对待系统配置,让他受到管理和测试。

  • 配置与灵活性
    大多数的配置信息没有格式检查,且未经测试。通过对部属活动的冒烟测试可以缓解配置验证的问题。

  • 配置的分类

  • 应用程序的配置管理
    1.配置信息以键值对的形式表示
    2.应用软件的配置信息保存通常选择 包括数据库,版本控制库,文件目录或注册表等。

  • 跨应用的配置管理
    为每个应用程序维护一份所有配置选项的索引表。

  • 管理配置信息的原则
    1.我们应该在什么时候注入那类配置信息,要与运维和支持团队一同讨论决定。
    2.应用程序的配置项要与源代码保存在同一格存储库
    3.通过自动化过程将配置项取出
    4.配置系统能依据不同的需求,提供不同的配置值
    5.配置项明确的命名
    6.每个配置元素不和其他元素重叠
    7.配置信息尽可能的简单
    8.保证测试以覆盖到部署或安装时的配置操作。

环境管理

没有哪个应用程序是孤岛,每个应用程序都有其依赖的环境,我们需要进行环境管理,关键在于通过一个全自动化的过程来创建环境。

  • 环境管理工具
    代表性的puppet和CfEngine
  • 变更管理过程
    对环境的变更过程进行管理

学到

1.对于一些比较复杂的任务可以使用增量式的开发,就是先开发主要的功能模块,再开发次要的功能模块,感觉这与我们所说的mvp最小可行性产品有一定的关系。

2.对所有的内容进行版本控制,我们一般可能只注重代码和环境的管理,忽视了文档的重要性,可能是因为我们的软件规模较小,所以文档的缺失没有太大的影响,但往往当回头看我们的代码,想找到自己代码中的某个接口对应的操作时,才发现自己没有对这些基本的信息进行记录,导致修改,查看之类的操作可能会很麻烦。

3.不仅仅对软件相关的产物进行管理,而且要对软件所依赖的环境进行管理,可能在不同的电脑上运行出不一样的结果,可能就是因为环境的影响,所以我们使用软件第一步就是要对环境进行配置。

总结

1.到现在读了两章的内容,其实一直都觉得这本书不是很好读,有一种我认识所有的字,但读过之后感觉不理解,需要重复读几遍才能够有理解,理解之后会发现一些自己缺失或者是理解的不够全面的地方。
2.配置管理是我们了解这本书的基础,没有配置管理的基础,持续交付会变的困难重重。

你可能感兴趣的:(持续交付-第二章 配置管理)