DevOps基本术语和概念

DevOps基本术语和概念

软件开发方法论

划分开发工作的过程(通常划分为不同的阶段)就被称为软件开发方法论。

这些不同的工作阶段可能包括:

  • 可交付的产品或工件的规范。需求分析阶段。
  • 根据规范完成代码的开发和验证。研发和测试阶段。
  • 将代码部署到最终客户或生产环境。部署和交付阶段。

瀑布方法论

瀑布方法论或模型是一个项目管理过程,其重点是由这个过程的一个阶段到下一个阶段的串行进程,具体如图:

瀑布模型往往是高度结构化的,大量时间花费在需求和设计阶段,其思想是:如果能够正确的完成这两个阶段,就能大大减少后期可能发现的错误。

敏捷方法论

敏捷宣言的原则

  • 个体和互动 高于 流程和工具
  • 工作的软件 高于 详尽的文档
  • 客户合作 高于 合同谈判
  • 响应变化 高于 遵循计划

在每组对比中,后这并非全无价值,但我们更看重前者。

Scrum

在20世纪90年代,由Ken Schwaber 和 Jeff Sutherland博士提出,重点在于最大化开发团队的能力,从而对项目和客户需求中共的变更快速做出响应。

Scurm使用预定义的开发周期,称为Sprint,通常在一周到一个月之间,每天早上需要开站会,站会中每个团队成员需要回答三个问题:

  • 昨天我做了哪些工作帮助团队实现Sprint目标。
  • 今天我计划做什么来帮助团队实现这些目标。
  • 我发现了哪些问题可能妨碍我或者团队达到这些目标(如果有)。

XP

极限编程,Extreme programming,缩写为XP。

极限编程的主要目标在于降低因需求变更而带来的成本。在传统系统开发方法中,系统需求是在项目开发的开始阶段就确定下来,并在之后的开发过程中保持不变的。这意味着项目开发进入到之后的阶段时出现的需求变更(而这样的需求变更在一些发展极快的领域中是不可避免的)将导致开发成本急速增加。

极限编程透过引入基本价值、原则、方法等概念来达到降低变更成本的目的。一个应用了极限编程方法的系统开发项目在应对需求变更时将显得更为灵活。

原则

组成极限编程基础的原则,正是基于上面描述的那几条价值。在系统开发项目中,这些原则被用来为决策做出指导。与价值相比,原则被描述的更加具体化,以便在实际应用中更为简单的转变为具体的指导意见。

快速反馈

当回馈能做到及时、迅速,将发挥极大的作用。一个事件和对这一事件做出反馈之间的时间,一般被用来掌握新情况以及做出修改。与传统开发方法不同,与客户的发生接触是不断反复出现的。客户能够清楚地洞察开发中系统的状况。他/她能够在整个开发过程中及时给出反馈意见,并且在需要的时候能够掌控系统的开发方向。

单元测试同样对贯彻反馈原则起到作用。在编写代码的过程中,应需求变更而做出修改的系统将出现怎样的反应,正是通过单元测试来给出直接反馈的。比如,某个程序员对系统中的一部分代码进行了修改,而假如这样的修改影响到了系统中的另一部分(超出了这个程序员的可控范围),则这个程序员不会去关注这个缺陷。往往这样的问题会在系统进入生产环节时暴露出来。

假设简单

假设简单认为任何问题都可以”极度简单”地解决。传统的系统开发方法要考虑未来的变化,要考虑代码的可重用性。极限编程拒绝这样做。

包容变化

可以肯定地是,不确定因素总是存在的。“包容变化”这一原则就是强调不要对变化采取反抗的态度,而应该包容它们。比如,在一次阶段性会议中客户提出了一些看来戏剧性的需求变更。作为程序员,必须包容这些变化,并且拟定计划使得下一个阶段的产品能够满足新的需求。

运维方法论

ITIL

ITIL的正式名称:信息技术基础架构库或者IT基础架构库(Information Technology Infrastructure Library
)。这是为管理IT服务定义的一组时间。包括:流程、过程、任务和检查表。

ITIL最早从1989年,五大核心的部分分别包含:服务战略、服务设计、服务转换、服务运营和服务持续改进。

COBIT

COBIT的全称为:信息及相关技术控制目标(Control Objective for Information and Related
Tecnology)。是一个用于信息与技术智力和管理的ISACA框架,最早于1996年发布。COBIT的一个核心原则是:保证企业目标与IT目标一致。

COBIT的5个主要原则包括:

  • 满足利益相关人的需要
  • 全过程覆盖整个行业
  • 应用一个集成框架
  • 支持一个整体方法
  • 区分治理和管理

系统方法论

精益方法

基本原则

  • 价值(Value
  • 价值流(Value stream
  • 流动(Flow
  • 拉动(Pull
  • 尽善尽美(Perfection

消除浪费

  • 不必要的软件特性
  • 通信延迟
  • 过长的应用响应时间
  • 过于繁琐的过程

对应与软件开发的浪费

  • 部分完成的工作
  • 额外的功能
  • 再学习/返工
  • 不必要的交谈
  • 任务切换
  • 延期
  • 缺陷

精益方法关注改进工作流,这也成丰田方法(The Toyota Way)。

开发、发布和部署的概念

##版本控制

版本控制系统会记录系统中存储的文件或文件集的变更。这些文件可能是”源代码、资产以及软件开发项目中的其他文档。设计量个概念,分别为:

  • 提交(Commit
  • 修订版本(Revisions

##测试驱动开发

在测试驱动的开发中代码开发人员先为新的代码功能编写一个测试,当然,这个测试会失败,失败后再编写代码本身,最后确保代码编写完成后,能够通过这个测试。

测试时清晰地定义新功能的一种方法,可以更明确的指出代码应该作什么。

##应用部署

应用部署是计划、维护和执行一个软件版本交付的过程。

##持续集成

持续集成(Continuous Integration, CI
)是一天中频繁地将开发人员编写的新代码与主线或主分支集成的过程。相对的做法是:开发人员分别完成读里的特性分支,可能耗时数周或者数月,只有当这个独立分支完全完成后才将其代码合并岛主分支。由于合并的时间跨度很长,这意味着在此期间可能已经发生更多变化,其中一些变化早晨的破坏性会更大。

##持续交付

持续交付(Continuous
Delivery,CD)是一组通用的软件工程原则,允许通过使用自动化测试和持续集成频繁地发布新软件。持续交付通常认为是持续集成的更进一步。不只是确保可以集成新变化而不会导致回归到自动化测试,持续交付还意味着可以部署这些变更。

##持续部署

持续部署(Continuous Deployment,也称为CD),是通过定义测试页验证来最小化风险。从而持续将变更部署到生产环境的过程,持续交付确保可以部署新变更,持续部署则表示将这些变更能够部署到生产环境中。

##最小化可行产品

最小化可行产品(Minimum Viable
Product,MVP)的思想是用最小的投入创建所提议产品的一个圆形,已确定这个提议是否是一个好的想法。并不是100%的完成所有开发后再把产品交付给用户,MVP的目标是大大减少所做的开发,这样一来,如果需求需要做重大改变,之前所花费的时间和精力不会太多。

与精益和持续交付等想法类似,MVP可以让组织更快第迭代和改进,同时减少成本和浪费。

基础设施概念

配置管理

起源于20世纪50年代,美国国防部开始将配置管理(Configuration Management,CM
)作为一个技术管理准则,现在很多行业中都采用了配置管理。配置管理师建立和维护某个产品的功能和物理特性机器整个生命周期中性能的过程。包括实现这种一直的性能、功能和特性体系所需要的策略、流程、文档,和工具。

云计算

通常称为:“云”,是一种共享的基于互联网的计算。客户可以根据需要购买和使用各个云提供的共享计算资源。避免相应的开销。

工件管理

工件是软件开发过程中某个步骤的输出,取决于开发语言,通常有不同的形式,如JAR包、War包、库、资产、和应用。工件管理一般使用工件仓库(制品库)来完成:

  • 完成二进制文件和以来文件管理的一个中心点。
  • 组织与公共仓库之间的一个可配置的代理。
  • 推广内部开发软件的一个集成点。

容器

软件容器是一种隔离结构,可以相对独立与底层操作系统或硬件进行开发和部署。

类似于虚拟机,容器提供了一种方法, 可以为容器中运行的代码建立沙箱环境。比虚拟机的开销更小,而且对操作系统和银价你的依赖更少。

文化概念

回顾

是项目完成后对项目的讨论,一般会问如下问题:

  • 做了什么
    • 这个项目的范围是什么,最后完成了什么
  • 哪些方面做的好?
    • 项目中的成功做法,有哪些另团队特别骄傲的特性,另外哪些方面还要在将来的项目中使用。
  • 那些方面做的不好?
    • 哪些方面除了问题,遇到的bug。没有满足最后的期限,以及将来项目中要避免的问题。

事后分析

事后分析(postmortem)发生在一个计划外的时间或中断后进行,有些情况下,一个事件会让相关的人感到诧异,至少暴露了系统或者组织的某个失误。时候分析包括如下主题:

  • 发生了什么?
    • 时间从开始到结束的整个时间表,通常包括通信或者系统错误日志。
  • 听取报告
    • 时间中涉及的每个人都发表对这个时间的看法,包括他们在事件中的想法。
  • 补救事项
    • 应当对那些方面做出改变,以提高系统安全行并避免此类事件再次 发生。

无问责

无问责文化不只是让人们摆脱困境,更重要的是可以确保人们很自然的谈到时间的细节,及时他们的行为直接导致了一个负面结果。只有充分了解事情是如何发生的,才能真正开始学习。

组织性学习

组织性学习是手机、发展和分享一个组织知识体系的过程,一个学习行组织会让其学习更全面,把学习设定为一个特定的目标,并采取可操作的步骤不断增加集体学习。

作者

Cyrusky

发布于

2019-07-04

更新于

2024-11-18

许可协议

评论