DevOps流程规范1-DevOps关键术语

逃离我推掉我的手 2022-09-06 00:18 192阅读 0赞

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2d1b2Zhbmdza3k_size_16_color_FFFFFF_t_70][]

# 1-DevOps关键术语 #

DevOps代表了应用程序开发的新模式，需要软件开发人员和IT运维之间的深入协作。这种深入的合作表明了一种文化，其重点是定义软件的时候需要考虑可运维性，并且自动化软件交付过程，从而快速，频繁，可靠地构建，测试和发布软件。

## 1.1 定义 ##

以下是与DevOps相关的常用（但在行业中定义不同）的一些基本定义：

表格 1‑1 DevOps术语定义

<table> 
 <thead> 
  <tr> 
   <th><strong>术语</strong></th> 
   <th><strong>定义</strong></th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>DevOps</td> 
   <td>从概念上讲，DevOps是从一开始就通过以最有效和可持续的方式向客户提供想法（功能，代码，文档，无论如何）的必要条件。 DevOps通常在软件交付的上下文中应用，并且指的是面向软件开发人员和IT运维之间深度协作的应用程序开发模型。 也就是说，DevOps模型可以应用于具有不同开发和操作组件的任何开发生命周期 - 例如基础设施或IT服务。</td> 
  </tr> 
  <tr> 
   <td>Continuous Integration （持续集成）</td> 
   <td>持续集成是将源代码（最有可能来自不同开发人员或团队）组合到单个应用程序中的过程，然后通常在生成的应用程序上运行一些自动化测试套件。 该集成过程“连续”运行，即定期间隔查询源码库或由代码提交触发。</td> 
  </tr> 
  <tr> 
   <td>Continuous Delivery （持续交付）</td> 
   <td>持续交付是以连续的方式打包，测试和存储应用单元的过程，以便能够随时准备投入生产。 这扩展了持续集成的过程，以获得具有足够的测试，合规性和验证的应用程序单元，以便生产就绪。</td> 
  </tr> 
  <tr> 
   <td>Continuous Deployment（持续部署）</td> 
   <td>一些组织或应用程序将持续交付扩展到持续部署，将应用程序自动部署到生产环境中。 这通常需要强大的生产验证机制和全面的回滚功能。</td> 
  </tr> 
  <tr> 
   <td>Delivery Pipeline（交付流水线） / DevOps Pipeline（DevOps流水线）</td> 
   <td>交付流水线是指将应用程序交付给生产的过程的阶段。 这将包括至少构建，集成，测试和部署，但也可能需要代码质量扫描，安全性和合规性检查，性能测试以及通过不同的环境进行。</td> 
  </tr> 
  <tr> 
   <td>Delivery Pipeline Tool Chain （交付流水线工具链）</td> 
   <td>交付流水线工具链是基于常见行业模式和环境要求的最佳工具集合，以支持使用C＃，Java，Python，Go或其他编程语言的应用程序开发以及相应的研发流程。</td> 
  </tr> 
  <tr> 
   <td>Cloud Native Applications（云原生应用）</td> 
   <td>云原生应用是指根据按照云平台上最佳运行和管理分布式应用程序的原则架构开发的应用程序。这些原则的一个很好的例子就是现代应用的十二范式（The 12-Factor App）。 DevOps模型是十二因素应用程序管理原则的关键推动因素，它分享了应用程序开发的理想实践，特别注意随着时间的推移，应用程序的有机增长的动态，开发者应用程序的协作动态 代码库，并避免软件侵蚀的成本。 DevOps模型可以被看作是开发云原生应用程序所必须的方法。</td> 
  </tr> 
  <tr> 
   <td>PaaS</td> 
   <td>平台即服务（PaaS）是一种云计算服务，它提供了一个平台，允许组织开发，运行和管理应用程序，而不需要构建和维护通常与开发和启动应用程序相关的基础设施的复杂性。</td> 
  </tr> 
 </tbody> 
</table>

## 1.2 指导原则 ##

以下是一组DevOps指导原则。

表格 1‑2 DevOps指导原则

<table> 
 <thead> 
  <tr> 
   <th><strong>DevOps</strong>指导原则</th> 
   <th><strong>描述</strong></th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>开发运维融合为一个团队</td> 
   <td>传统的开发者和操作人员已经成为“我们和他们”的代名词。开发人员开发软件，并希望通过一些定义的发布流程将其移交给运维部门，用于生产部署和持续运营。 这种做法充满了沟通不畅，对预期不符。通常情况下，运维人员第一次意识到新的应用程序正在投入生产，是在发布审查期间 - 如果有的话。 DevOps要求开发人员和运维人员进行广泛而持续的合作，基本上成为一个团队。在开发和运维必须广泛合作的同时，协作还可以在交付流程中的不同时间积极地包括其他团队（例如安全性）。 这也代表了传统的开发和运营的重大文化转型，转变为基于信任和深度合作的不相互推诿责任的文化。 通过执行交付流程来执行此操作，在单个冲刺计划中采用包括开发和运维活动在内的敏捷方法。</td> 
  </tr> 
  <tr> 
   <td>DevOps team is accountable and responsible （DevOps团队是可依靠的和负责任的）</td> 
   <td>DevOps团队对其运行的应用程序及其运行的环境（即虚拟机和/或容器）全权负责。</td> 
  </tr> 
  <tr> 
   <td>Shift to the left（左移原则）</td> 
   <td>运维活动不仅只关注在部署到生产中并在其上运行软件，而且也将运维活动前移到交付流水线本身。 将功能集成到交付流程中，如早期安全和身份验证测试，以及不仅开放对开发人员的监控，而且运维主动监控应用程序环境影响，并通过交付流水线向开发人员提供反馈。</td> 
  </tr> 
  <tr> 
   <td>Automate the delivery pipeline（自动化交付流水线）</td> 
   <td>最大限度地自动化交付流水线过程的各个步骤，以便可以快速，频繁和可靠地进行构建，测试和发布软件。 自动化可以自动化的所有内容，并在法规或公司政策要求的情况下维护手动步骤。</td> 
  </tr> 
  <tr> 
   <td>Immutable infrastructure（不可变基础架构）</td> 
   <td>基础架构应该从原始源代码（见基础设施即代码）创建一次，而不是在事实之后进行操作，尤其那些容易出错的手动过程。 一个紧密联系的概念，解决相同基础架构（如配置管理）的任何组合过程应该是幂等的，因此重复应用不会导致错误或预期的更改。</td> 
  </tr> 
  <tr> 
   <td>Infrastructure as code （基础架构即代码）</td> 
   <td>基础设施应被视为代码，将基础设施定义与应用程序代码保持在版本控制中，同时提供在整个交付流程阶段部署一致的，类似生产的环境的能力。 这确保一致性并提供审计控制点。</td> 
  </tr> 
  <tr> 
   <td>Smaller more frequent releases（更频繁但是规模小的发布）</td> 
   <td>每个版本都引入了少量更改，因此可以使生产版本更频繁，风险更低。 这也提供了获得最终用户反馈并更快地进行调整的机会。</td> 
  </tr> 
 </tbody> 
</table>

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2d1b2Zhbmdza3k_size_16_color_FFFFFF_t_70]: /images/20220829/bd7c8eb8623b40b39a8e1c842d2f0ede.png