“一切即代码”究竟意味着什么？

以代码驱动的科技世界中，越来越多的场景实现了自动化。在一定程度上，又可以将 基础设施视为代码 ，而这一句话该如何理解？其中又将包含哪些设施？

作者 | Mitch Pronschinske

译者 | 弯月， 责编 | 屠敏

出品 | CSDN（ID：CSDNnews）

以下为译文：

你可能不太理解人们常说的“xxxx即代码”或“一切即代码”，其实你只需要知道我们讨论的是自动化：我们利用自动化来处理繁琐的工作，或者在某个任务过于庞大和复杂无法手动处理时，就可以考虑自动化。

“xxxx即代码”的说法源自“基础设施即代码”，以及开发运维运动——IT运营/系统管理员与开发人员共同努力，通过可重用的代码来实现IT环境变更的自动化，并对代码进行版本控制，就像多年前开发人员就采用这种方式来处理应用程序的代码变更一样。

开发人员实现软件交付流程的自动化已经有一段时间了，但是IT基础架构运营/系统管理员在过去的十年中才赶上来。系统管理员也会使用自动化，但通常是通过一系列手动触发的脚本进行的，其中有些脚本的组织性较差。而如今开发人员帮助运维推动了这一发展，目的是减少开发中的瓶颈，同时还可以自动化大多数软件生产过程，摆脱大量的手动管理。

那么，这些代码都是从哪里来的呢？为了了解这一点，首先让我们来看一看软件生产的每个阶段，看看哪些部分已经实现了“xxx即代码”的自动化。我希望通过本文来介绍软件开发生命周期中的哪些领域已经实现了良好的自动化和抽象化，并思考还有哪些领域有待新颖的自动化，以及了解“一切即代码”适用于何处。我希望你可以通过本文了解“xxx即代码”这个概念，并区分哪些工具很新颖且有实用价值，而哪些工具只是虚有其表。

计划/需求/设计

这个阶段位于编程工作开始之前。在这个阶段，我们需要根据业务和技术利益相关者建立需求，制定软件计划，并绘制架构和UI设计图以及线框设计图。

架构即代码

通过代码创建软件架构模型的做法已经有一段时间了。你可以利用Structurizr之类的工具以这种方式构建图表，并运用到版本控制中。但是几十年来，开发人员尝试了各种方法来构建应用程序模型，结果却各异。

在10-20年前，模型驱动开发的概念曾一度非常热门，但从未运用到主流开发中。这个概念的基本前提是，你可以利用UML或EMF之类的建模语言对软件组件进行建模，并根据编程要求生成整个初始应用程序。

虽然模型驱动的开发在很大程度上被主流开发圈子忽视，因为通常这种模式需要大量的预先设计，但是有些需要提前设计的领域仍然在使用，比如NASA。

请注意有关术语“架构即代码”的新兴用法： AWS以及其他开发用这个术语来描述高级基础架构即代码的模式。很显然，这与我在上面提到的应用程序级架构不同。AWS的架构即代码指的是基础设施的架构，例如容器协调器配置、负载均衡器、安全组和IAM角色等，这些架构都是通过可重复使用的模板定义的，而这些模板则面向特定的服务类型，例如负载均衡器后台的API服务、队列中的工作或预定的工作等。

这些模板可以通过预先制定的配置自动提供组件，例如容器协调器配置、负载平衡器、安全组和IAM角色等。Terraform模块、Kubernetes自定义资源定义以及主流云供应商提供的各种结构中都包含这种含义下的架构即代码。

项目即代码与脚手架项目

然而，由模型驱动开发生成代码的概念与编程本身一样有年头了。将Ruby、Python或Java转换为C代码的编译器都是生成器。如今甚至是新手前端程序员都明白代码生成的重要性，因为它可以为你节省编写样板代码的时间。

在运行Ruby on Rails脚手架处理时，你运行的代码都是在其他代码（模板或框架应用程序）的基础之上经过改编而成，因此你不必从零开始。热门的流行前端框架（比如Bootstrap和Foundation）是响应式UI模板框架，它们之所以风靡整个网络，是因为现成的CSS组件以及与移动设备兼容的动态组件可以减少建设网站的工作量。

这个类别中有很多自动化的空间，在过去几年中，“项目即代码”（面向应用程序的代码库与交付管道设置）填补了开发运维运动中未能覆盖的空白。有些工具（比如面向JavaScript项目的Yeoman，以及面向Java项目的JHipster）提供了最基本的功能和灵活的框架，你可以分别使用Node.js和Spring Boot + Angular建立项目。微软的Azure等云供应商正在创建设置交付流水线的工具。还有一家公司realMethods已经构建了一个工具，它可以获取数据库模式或建模需求，而且你可以利用这些数据生成特定技术栈的框架代码，以及构建和配置文件、CI/CD的清单文件YAML、Docker文件和镜像、Kubernetes集群配置和Terraform的配置文件。

“项目即代码”适合于不断发展的崇尚生产的流派，他们主张建立极端版本或强调最低可行产品的概念：虽然你不希望部署代码库中仅有一个帮助文档的应用程序，但是也不需要构建功能完整的应用程序。你只需要自动化模式和管道的设置，就可以快速地部署简单的框架应用程序，比如Web应用生产中的一个端点，且该端点能返回200状态码的响应。

应用程序环境即代码

多年来，虚拟机、容器以及其他各种软件生产环境的抽象都是开发人员的福音，因为这些技术不断发展，更易于管理。当你可以自动启动模板环境，然后舒服地开始写代码时，怎么可能还有人愿意尝试和调试手动设置操作环境可能引发的100种问题呢？

Vagrant以及后来的Docker（和一般容器）等技术简化了开发环境的设置。容器和容器编排器（比如Kubernetes或Nomad）都成为了流行的工具，它们利用敏捷、隔离、正确配置的组件部署环境。

你可以将这些工具视为以代码的形式提供系统依赖性。Dockerfile是这种依赖关系（比如编程语言的版本或数据库的版本）中的代码和模板，而Docker是运行和满足这些依赖关系的工具。

版本控制

版本控制是包罗万象的阶段，从最初完成的代码一直到几年后的最终产品补丁，版本控制贯穿始终。即使是大多数新手开发人员也很快开始认识到，对于现代开发来说，版本控制不可或缺。版本控制将跟踪、开发管理、竞赛条件管理以及许多其他功能都变成了代码。

如今，GitHub、GitLab和BitBucket之类的版本控制系统已成为大多数软件生产管道的中枢神经系统，提供集成的持续集成（CI）、文档生成、部署等功能。

将软件生产的不同元素代码化的最大原因之一在于，我们可以将代码放入版本控制，智能地管理。许多组织发现版本控制非常实用，以至于他们经常将版本控制扩展到应有的范围之外。

开发

这个阶段从第一次代码提交到版本控制开始，一直持续到软件步入维护。请注意，计划-开发-部署-收集反馈的周期可能非常迅速（通常理应如此），因此这个阶段的涵盖面非常广，大到整个项目的创建，小到一行代码的变更。

自动化测试

测试是大多数开发工作流程中的关键部分，而测试框架的需求在编程历史的早期就凸显出来了。尽管并非所有类型的测试都需要自动化，而且你也不想为每种可能出现的UI用户流程编写测试，但无疑几乎每个开发团队都采用了自动测试。

通常，单元测试都是由开发团队编写，而且还名列自动化测试的榜单。在代码提交后，集成测试和UI测试通常会与单元测试打包一起运行。有些测试需要在构建之前运行，而有些则在构建之后运行。测试框架提供的自动检查、错误捕获以及代码审查功能在现代软件开发中是必不可少的。

每种编程语言生态系统都有一些自己的测试框架，其中有些利用语言本身来实现“测试即代码”，而有些则使用特定的语法。

• 流行的JavaScript测试框架包括Jest和Mocha

• 流行的Java测试框架包括JUnit和Spock

• 流行的Ruby测试框架包括RSpec和Minitest

• 流行的浏览器自动测试框架包括Selenium和Cypress

自动化构建与依赖管理

自动化构建的发展已有很长一段历史了，其基本思路是方便开发人员快速掌握构建，并从构建项目版本时面临的一系列繁杂的手动工作中解脱出来，开发人员可以利用工具运行代码编写的检查列表，并自动化构建过程，且不会造成意外遗漏。

在需要构建涉及以下工作的复杂环境时，自动化构建非常具有帮助性：

• 代码生成

• 汇编

• 打包

• 元数据定制

• 以及其他

在Java环境中，这可能意味着根据你的配置创建DAO，或生成类映射代码（如JAXB）。

自动化构建还有助于弥补不同环境下的差异——即使通过本地传递，仍然有可能因为缺少依赖项或由于其他原因而导致在生产环境中运行失败。这些自动化构建工具会整理好所有的库以及其他构建部分，提供另一种形式的依赖管理。

开发人员只需运行一个命令，或单击一个按钮即可完成自动构建。在有些情况下，自动化构建甚至会建立一个自动的事件链，开发人员无需执行任何操作，只需提交代码，构建管理器就会自动运行。

大多数主流编程语言都有社区推荐的自动化构建工具：

• JavaScript：Node.js + npm + Webpack

• Java：Gradle和Maven

• Ruby：Rake

• C#：MSBuild

• C：Make

持续集成/持续交付（CI/CD）

通常，我们用CI/CD来描述包罗万象的工具和实践，随着代码合并到生产的频率越来越高，这些工具和实践将构建、测试和部署自动化的实践整合到一起，每天都要执行很多次。

持续集成是利用CI专用服务器将代码分支频繁合并到应用程序源代码主线版本的实践，如果在合并时发生错误则标记相应的代码。持续交付的概念是指通过一套自动化，将新提交的代码反映到应用程序最新部署的版本中。这种部署工具会自动运行自动化测试、CI、自动化构建以及为应用程序构建新容器等其他部署工作。

如今大多数的CI工具在功能上都超越了CI的范围。开发或发布工程团队可以将构建步骤代码化，甚至将构建的输出作为代码。然后，利用CI/CD配置，针对应用程序的代码进行版本控制和监视。目前最流行的CI平台是Jenkins，Jenkinsfile是它的代码。YAML是这类CI平台上常见的配置语言，虽然有人并不怎么待见它。

最流行的四大CI引擎包括：Jenkins、TravisCI、CircleCI和TeamCity。

运营  

在软件生产的各个阶段中，运营阶段是由另一部分人负责的（尽管在小组织中并非如此），而通常这些人具备的技术力与开发人员有所不同。从事运营工作的人员包括系统管理员、运营工程师、开发运维工程师以及其他职位。

这个阶段的工作包括管理和提供运行应用程序所需的物理和虚拟硬件。现如今，许多专业操作人员只需要处理物理计算机之上的抽象。

配置管理

这个类别的工作听起来很宽泛，但是在大多数软件工程界中，配置管理指的是编写各个机器定义的工具。这些工具负责在现有服务器上安装和管理操作系统配置。

主流的四大配置管理工具包括Chef、Puppet、Ansible和Salt。它们是制定IT基础架构管理的首要工具（就像开发人员编写测试、构建、CI实践以及版本控制范围内的那些文件），它们构成了“基础架构即代码”和开发运维运动的首要推动力。

它们的优点在于能够创建不可变的基础架构：这意味着操作人员无需不断更新现有的计算机配置，而是每次只需停止现有的计算机，然后启动新的计算机，并将更新后的模板从配置管理工具移植到新启动的计算机上，因此每次变更都需要重启。这听起来很极端，但是在复杂的IT运营环境中，在添加或更新信息的时候消除潜在的出错可能，这才是更为稳妥的做法。

基础架构即代码

基础架构即代码提供了很多工具，这些工具除了提供配置基础设施组件的模板之外，还可以服务于基础设施本身。随着越来越多的组织开始采用一键即可搞定的云基础架构，基础架构即代码也变得更加容易。

提供这类工具的系统包括适用于AWS的CloudFormation，仅适用于Azure的ARM和Terraform，后者是更为流行的开源工具，因为它提供了面向所有主流云提供商的设置。由于这些系统能够大规模管理基础架构的复杂性，因此它们已成为操作人员与基础架构进行交互的主要界面之一。

关于开发人员使用“一切即代码”的说法，尽管本文介绍了该新兴术语的表面意思，但实际上其更为普遍的含义表述了开发人员对基础设施即代码这一类灵活的状态引擎充满了浓厚的兴趣，尤其是Terraform，它可以自动化的方面远不止基础设施。它可以通过类似插件的程序，自动化1Password、Google Calendar等办公工具，还可以使用GitHub提供的程序自动执行CI/CD管道操作。我们可以借助这类工具，将多个自定义的自动化集中到一处。

容器/集群编排器

容器编排器可以利用容器的优势，轻松地扩展部署和管理。虚拟机也可以得益于这种方法。

容器编排器的核心是集群调度程序，它们是一种智能系统，可以优化云/虚拟基础架构的使用，而你的应用程序就好像俄罗斯方块一样。本质上，调度器会读取配置文件设置的规则，然后根据你的参数，按照最适合基础设施的方式，将任意数量的应用程序、服务或组件（如负载均衡器等）部署到容器或虚拟机上。

编排器包括具有许多其他功能的Kubernetes，以及更侧重于调度的Nomad。

安全与合规

我们不应该将安全放到开发后，然而，很多组织往往会将安全放到最后。IT安全领域的领导者普遍认为，安全与合规应该贯穿软件生产生命周期，无论是手动还是自动。

安全即代码

从字面意思上看，安全即代码有点宽泛，但是我们应该在软件生产的各个领域中贯彻自动化的安全措施。这些可自动执行的操作包括：

规划与设计

• 生成最初的危险模型

• 构建自动生成安全测试的模板

开发与测试

• 专注于安全的静态分析：SonarQube、FindBugs、Checkmarx

• 动态安全测试自动化，比如DAST和渗透测试：FindBugs、Checkmarx、OWASP ZAP、ThreadFix

• 第三方组件风险分析和警报：Snyk、BlackDuck、WhiteSource

• 凭证/机密数据管理：HashiCorp Vault、AWS Secrets Manager

部署与生产

• 应用程序和基础结构代码的配置检查：Burp、Hardening.io

• 监视和警报：Snort、OSSEC

• 生产混沌测试和渗透测试：Gauntlt、Mittn和Simian Army

上述提到的“xxx即代码”的实践也可以提高安全性，因为这些自动化操作会创建经过授权、可重复以及可审核的操作，所以可以消除很多人为错误，减少创建安全漏洞的机会。

政策即代码/合规即代码

政策即代码类似于CI/CD管道的大门，如果某些测试失败或构建中断，那么CI/CD管道将停止代码合并。实际上，大多数政策即代码的框架都直接集成到了版本控制系统中。有些政策即代码涉及大规模的安全管理以及与安全相关的合规，因此从某种意义上讲，它也属于安全即代码。但是，政策即代码也可用于其他各种工程管理规则。

有时，你希望限制某些用户能够提供的基础架构的类型或数量。有时，你希望工程师给创建的资源加上标签。政策即代码的用途有无数种可能性。

开源的政策即代码框架包括Open Policy Agent和Chef InSpec等。一些公司将政策即代码构建到了基础结构管理产品中，比如HashiCorp的Sentinel框架，这种方式可以创建更深入、更专业的政策。

“xxx即代码”的目的是提高效率、安全或洞察力

毋庸置疑，未来会有更多“xxx即代码”的技术出现。但我们要记住一点，这些技术都是自动化与抽象。我们在了解新工具时，应当搞清楚其自动化软件生产的确切领域，以及是否包含任何创新。

利用一段配置代码自动执行操作的好处非常多。在实现自动化时，你需要：

• 通过组织、静态分析和警报，加强大型组织中的代码一致性。

• 通过测试确保自动化工作的可靠性。

• 选择一种通用语言，供所有了解自动化语言的人使用。

• 通过预先打包好的最佳实践自动化模块，减轻非自动化专业团队的负担。

• 通过模型，了解自动化管道作业的整体概念。

我希望通过本文的阅读，你开始考虑在工作中引入一些自动化。

原文： https://hackernoon.com/everything-as-code-explained-0ibg32a3

本文为 CSDN 翻译，转载请注明来源出处。

【End】

热 文推 荐 

☞ CSDN创始人蒋涛： 开发者是泛终端生态的第一推动力

☞ 中国工程院院士评选结果公布，阿里王坚当选

☞ 程序员需要了解的硬核知识之操作系统和应用

☞ 小米 9 年，雷军开启 AIoT 与 5G 超级互联网时代！

☞ 程序员正在消失？

☞ 5G套餐到底该不该换？看完你就明白啦！

点击阅读原文，参加中国开发者现状调查！

你点的每个“在看”，我都认真当成了喜欢