基于DevOps平台构建自己博客：4-DevOps入门介绍

什么是DevOps?

DevOps 是一种软件开发方式，开发人员和运维人员协同合作，灵活、快速地开发软件。DevOps 通过将人员、方法和工具联系起来，消除了开发和运维团队之间的孤岛。这种方法可以加速应用程序和服务的开发。此外，通过加快对IT基础设施管理的响应，可以在应对当前瞬息万变的市场的同时引入和更新IT产品。

DevOps 的目的是弥合为应用程序创建代码的软件开发 (Dev) 和运行应用程序并将其提供给最终用户进行维护的 IT 操作 (Ops) 之间的差距。它从敏捷开发和精益制造方法演变而来. 敏捷开发是一种提高 IT 开发组织响应能力的技术，它专注于将工作分解成小块并在较短的时间间隔内重复它们。精益制造是一种减少浪费和最大化工厂生产力的方法。

DevOps 集成并简化了以前孤立的软件开发、质量保证和 IT 运营团队。

DevOps 消除了与敏捷开发相关的瓶颈。在敏捷开发中，开发人员经常创建新软件和更新代码。然而，传统的运维团队发现很难快速测试并将软件投入生产，失去了高速开发的真正价值。然而，虽然敏捷开发的流行增加了软件设计和构建的可重复性和灵活性，但它并没有成为跨越软件开发生命周期（SDLC）的方法。

DevOps 是一种文化或哲学方法，强调持续开发、协作和透明度。DevOps 对 IT 运维的看法是全面且以价值为导向的。我们的目标不是专注于单个业务孤岛，而是通过查看从创意到提供产品和功能的整个流程，并优化其间的一切，从而快速获得更大的业务价值。当 DevOps 运行良好时，它不仅可以加快编码迭代和部署，还可以缩短新想法的上市时间、减少错误并提高基础设施的稳定性。

DevOps：开发和运维

敏捷软件开发的开端是2001年17位开发者发表的简短的一句话《敏捷软件开发宣言》 。该宣言提出了四项基本原则：

• 与个人对话，而不是流程和工具。

• 比综合文档更好的软件。

• 与客户合作而不是合同谈判。

• 响应变化而不是遵循计划。

2008年，比利时的 Patrick Debois 和美国的 Andrew Clay Shafer 开始讨论将“敏捷”引入IT基础设施的挑战。一年后，Debois在比利时根特首演了“Dev Ops Days”活动。自此事件以来，“DevOps”一词便用于IT领域。

DevOps 的以下三个基本原则首先由DevOps 支持者 Gene Kim 编写。参考：The Three Ways: The Principles Underpinning DevOps

• 系统思考：更全面的 IT 方法。从开发人员到测试人员、基础设施经理、代码和软件用户，我们关注整个系统的性能，而不是单个孤岛的性能，例如运维和部门。

• 反馈循环增强： Kim 指出，“大多数过程改进活动的目的是缩短和增强反馈循环，以便可以持续进行必要的修改”。

• 持续试验和学习：敏捷软件开发宣言强调响应和协作，而 DevOps 的重点是持续改进：发现更好的新方法。Kim说，有必要创造一种“鼓励不断尝试、冒险和从失败中学习的文化，并理解重复和实践对于成熟至关重要”。

DevOps和敏捷的区别

DevOps 将软件开发的敏捷原则扩展到软件部署。敏捷软件开发宣言的转变旨在改进软件的开发方式，而 DevOps 将敏捷开发扩展到版本，并在整个软件开发生命周期中应用类似的原则。换句话说，范围的不同就是敏捷和 DevOps 的不同。

DevOps的持续发展

持续开发包含持续集成和持续交付 (CI/CD) 以及持续实施的 DevOps 概念。与其每年（或更少）批量发布大型版本，不如频繁地进行、发布和评估小改进，以便 IT 团队可以不断改进他们的产品和服务。在市场上，创新型初创企业压倒整个市场的情况并不少见，更别说是顶级企业了。无论是来自 Netflix 或 Instagram 等基于软件的公司的核心产品，还是改进您的网站或 IT 服务，DevOps 的持续发展让您在这些市场中保持竞争力。

DevOps中的持续集成

DevOps 中的持续集成是一种在每个任务之后将新代码合并到主源代码中的技术。当您将新代码提交到中央共享存储库时，它将自动在那里构建以测试和验证您的更改。这样，您可以快速发现问题，为开发人员提供即时反馈，并让他们立即着手进行所需的更改。

DevOps中的持续交付

DevOps 中的持续交付是一种以集成方式测试新代码的方法，利用了持续集成的速度。持续交付会自动测试和暂存新代码，使其为部署做好准备。

这个过程包括单元测试、集成测试、功能测试和回归测试，视情况而定。一旦代码获得批准，它将自动进行部署。但是，持续的软件交付并没有自动部署检查的代码。它将持续进行。

DevOps中的持续部署

通过持续集成和持续交付集成和批准新代码然后自动发布它的过程是 DevOps 中的持续部署。一旦在自动化交付过程中通过测试的代码被分阶段并发布到生产环境中，最终用户就可以使用新功能。

持续部署是有风险的，因为在代码从开发人员到达最终用户之前没有人工干预。基本上，持续部署是针对低风险产品和功能的。由于敏感数据处理、高安全风险、监管义务和重大财务风险，DevOps 实践很少是持续部署。尽管有这些考虑，但持续部署通常被认为是 DevOps 的关键目标之一，因为它可以加速并最大限度地缩短价值实现时间。

持续交付和持续部署通常缩写为“CD”，并且经常被混淆。但是，持续交付是指交付已准备好发布的软件。而持续部署（或手动部署）将新软件置于最终用户的生产环境中。持续交付中的交付物通常是我们的可部署软件，在目前的行业实践中，大多为docker镜像。持续部署则是将持续交付中的软件部署到指定环境，这里的环境可以是生产环境，也可以是测试环境。通常CD是镜像+目标环境。

DevOps架构：云、虚拟化等

DevOps 架构通常是指有助于实现 DevOps 文化目标的基础设施。DevOps 没有特定的架构，因此 IT 组织在部署 DevOps 时不必丢弃现有的架构。但是，您的 DevOps 组织架构有一些关键原则和最佳实践。

随着 DevOps 的出现和云平台的同时出现，云和其他虚拟化技术对 DevOps 的成功做出了重大贡献。支持 DevOps 并帮助组织部署和实践 DevOps 的常用技术包括云平台、虚拟化和微服务。

• 云：云平台允许您在虚拟环境（云）而不是本地配置资源，为用户提供快速和极大的灵活性（请参阅下面的“云在 DevOps 中的作用”）。

• 虚拟化：在虚拟化出现之前，服务器都是真实世界的硬件，如果你需要第二台服务器，你必须购买真实的东西。虚拟化允许您创建虚拟服务器（或虚拟桌面等），因此软件团队可以在现有的本地或云服务器上创建虚拟环境，而不是安排另一块硬件。所以对于想要敏捷工作的团队来说，这个大瓶颈已经被消除了。自动配置还减少了开发人员在几分钟内访问所需资源的时间。

• 微服务：微服务的架构由数量有限的松散耦合的功能单元组成，它们共同构成了整个系统。对于大型系统和应用程序，如果它们由这些单一功能、可重用的模块组成，则更容易构建和修改。借助这些独立组件，DevOps 从业者可以部署更新，对其依赖项的影响较小，从而使他们能够更快地移动，同时降低更改失败的风险。在 DevOps 书籍DevOps:  A Software Architect's Perspective 中，作者 Len Bass、Ingo Weber 和 Liming Zhu 说：“微服务的架构风格是 DevOps 的开端。它旨在解决许多问题。”

什么是DevSecOps?

DevSecOps 是一个包含安全措施的 DevOps 流程。每个人都对安全负责，而不是在流程结束时将代码传递给另一个安全团队。DevSecOps 可快速提供安全软件，同时防止在最后阶段发现缺陷以及由此产生的返工。

总的来说，DevSecOps 的三个基本原则是：

• 从开发过程开始就引入安全措施。

• 将安全视为一项重要的开发责任，而不仅仅是团队问题。

• 自动化您的安全流程，以保持 DevOps 的高效流程。

2012年发布的DevSecOps宣言详细定义了DevSecOps的原则。

DevOps 的最初倡导者 Damon Edwards 和 John Willis 开始使用缩写 CAMS，它代表关键开发原则。CAMS 代表文化、自动化、测量和共享。

此外，DASA（DevOps 敏捷技能协会）公布了 DevOps 的六项原则。大纲如下：

• 以客户为中心的活动：一个简短的反馈循环，用于理解和接受客户的观点。

• 目标意识创建：与其严格定义每个人的角色，不如鼓励整个组织思考如何为组织内外的客户创建 IT 产品。

• 端到端责任： DevOps 消除了这些孤岛，而不是让每个人只对自己的角色负责（开发人员不参与基础设施故障，运营团队不负责代码故障）。我们的目标是达到目的以及整个团队的责任。

• 跨职能自治团队：需要建立拥有所有技能和职责的团队，通过改进周期涵盖每个 IT 产品的发明、提供和处置过程。

• 持续改进：实践 DevOps 的团队始终致力于提高速度、质量和消除浪费。

• 将所有可以自动化的东西自动化：为了提高业务的速度、效率和有效性，尽可能利用 IT 自动化至关重要。这样做可以为团队成员提供更多空间来从事更有价值的任务并减少人为错误。

开发运维工具