版本控制

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

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

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

开发

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

自动化测试

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

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

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

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

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

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

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

自动化构建与依赖管理

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

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

代码生成

汇编

打包

元数据定制

以及其他

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

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

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

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

Java：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即代码”的技术出现。但我们要记住一点，这些技术都是自动化与抽象。我们在了解新工具时，应当搞清楚其自动化软件生产的确切领域，以及是否包含任何创新。

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

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

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

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

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

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

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