DevOps和软件配置管理之间的区别

开发运营和软件配置管理有什么区别？

对我来说，只要DevOps和软件配置管理都专注于：

1. 建立开发基础架构 -负责版本控制，构建管理，部署管理，依赖项管理，持续集成和交付等。
2. 使用最佳实践来组织开发人员环境。
3. 开发过程的质量保证 -收集开发有效性的度量标准，消除开发过程的瓶颈（运行单元测试，评估单元测试覆盖率，运行检查等）
4. 基础架构管理 -目标平台及其详细信息。
5. 发布管理 -确保发布已及时交付给客户。

也许我想念什么？此链接显示以“软件配置管理”一词为准。但是，您仍然希望使用什么单词组合来描述所列的活动范围：开发操作或软件配置管理？

这些术语描述了非常相似的概念和职责，通常它们有些同义。“ DevOps”一词是一个相对较新的词，在2009年根特Devopsdays会议和随后的Devopsdays活动中得到了普及。最好在此图中描述：

另一方面，“软件配置管理”在行业内是一个更为成熟的术语，它源于非软件特定术语“ 配置管理”。通常在软件工程环境中引用软件配置管理，Roger Pressman在“软件工程：从业者的方法”中给出了一个简单的定义：

是一组活动，旨在通过识别可能更改的工作产品，建立它们之间的关系，定义用于管理这些工作产品的不同版本的机制，控制施加的更改以及对所做更改进行审核和报告来控制更改的活动。

尽管您引用的所有术语都含糊不清，但DevOps似乎只是一种非正式形式，用于描述与配置管理或软件配置管理（如果从软件开发人员的角度来看）大致相同的一组原则，尤其是优先考虑紧密联系的团队：

DevOps是对日益增长的认识的一种回应，这种认识是传统上认为开发活动与传统上认为操作活动之间存在脱节。这种脱节常常表现为冲突和低效率。

在同一文章中，指出了与SCM的相似之处：

开发和运营工具中普遍存在的不匹配问题更加令人困惑。看一下开发人员每天需要和使用的流行工具。然后看一下系统管理员每天需要和使用的流行工具。除了一些值得注意的例外，例如错误跟踪器和SCM之外，令人怀疑的是，您会发现对使用彼此的工具或它们之间的显着集成非常感兴趣。即使工具类型有所重叠，但在每个组中实现通常也将有所不同。

至于术语的用法，您的比较实际上没有任何意义：

1. SCM是CM的子集，而不是竞争术语，
2. DevOps是一个相当新的术语，与既定术语相比毫无意义，
3. DevOps（显然）源自开发人员运营，但很少如此扩展。

我作为高级软件配置经理已经有很多年了（10+），我听到在各种现实生活中这些术语不匹配。由于职位的相对性质，对于非技术人员来说并不少见。两者都有相似的特定角色，需求和要求，但在我看来仍然可以明确区分。

我认为描述这些角色划分的最好方法是着眼于它们与交互的相对性。这就意味着，软件配置管理将重点放在内部系统和环境以及源代码的集成，部署，发布和管理上。开发人员运维（DevOps）将更多精力放在面向外部的应用程序体系结构的运维方面，同时对要使用的代码及其环境的实践保持清晰的了解。如果机器的性能显示出降级的迹象，多个应用程序之间的通信出现故障，企业对企业（BtB）的通信和/或与生产环境有关的体系结构限制，那么您将寻求开发人员运营部门的诊断和解。

通常，以我的经验来看，软件配置管理器也可以执行这些操作，但是这偏离了其跟踪，管理和部署环境配置和软件修订版的核心重点。管理允许职责分离，错误和缺陷跟踪，项目跟踪以及软件开发生命周期和工作流程分离的软件。这些任务不是开发人员运营的核心重点，因此势在必行，但仍然可以完成。

我已经看到了许多混淆的例子，并且每种情况都有一些有限的交叉。但是，最重要的是考虑每个独立职位相对于其主要重点的职责之间的差异。主要是在处理内部使用的系统和硬件以管理环境配置和产品发布时，您需要寻找一个软件配置管理器。另一方面，在处理系统性能，监视，研究和诊断客户使用的系统时，应考虑开发人员运营或DevOps。

现在，这并不是要a之以鼻，也不是一个明确的答案，而是个人识别每个职位的差异。我想知道我是否能力不足，或者此答案是否使事情变得更清楚。

您将很难为DevOps找到一个可靠的定义。这比完成工作更是一个主意。而且，每个人都无法就其确切含义达成共识是一个新想法。尽管如此，这是我的看法。

DevOps实际上只是配置管理的一个新术语，但它被选择来表明该角色不是一个人的角色，它是开发团队和运营团队之间的协作。

从历史上看，配置管理将仅由开发团队完成，然后移交给操作人员，他们将对此深表怀疑。老实说，这很公平。他们对此负责。发生错误时，他们是第一个在凌晨4点接到电话的人。他们确实应该参与其发展。

这是对问题的简单说明：DevOps是用于描述开发（在开发环境中开发程序代码）与运营（确保生产环境的最大正常运行时间）之间的协调或关系的术语。

软件配置管理是实现这种协调的一种方式。SCM涉及用于管理从开发到生产（运营）流程自动化的工具和技术

总而言之，SCM将Dev和Ops连接起来。

我看到DEVOP处于运营执行端-部署自动化脚本，环境构建等。另一方面，SCM与产品完整性以及产品变更的有效管理和可追溯性有关。我一直将ALM视为SCM的一部分-毕竟，如果您不知道更改的驱动程序或更改的源头，那么如何管理一个产品的更改？部署框架可能会落在一边-哪一边总是取决于您所服务组织的法规需求-毕竟，您是否希望开发人员能够进行快速黑客攻击，这意味着您的透析机只能正常工作99.99％有时，还是您需要这种情况，因为您的开发人员已经对IP地址进行了硬编码，因此您可以入侵网站代码？