Commitizen是一款提升GIT提交过程效率的小工具。它会提示你提供任何必要字段，还会恰当地格式化提交信息。Commitizen内置了对多种提交规范的支持，同时还允许你定制自己的提交规则。这个简单的工具能够节约时间，而不必等待提交钩子运行检查再驳回提交。

我们在许多项目中都使用ESLint作为标准。作为JavaScript的代码检查工具，它提供了很多规则集、推荐规则和插件，可以扩展为不同的框架或JavaScript风格。我们发现，通过在开发时对代码进行实时分析，Eslint可以极大地帮助团队在开发过程中建立和遵循代码规范。Eslint不仅可以通过实施最佳实践和代码规范，对编码实践进行标准化，还能识别代码中的漏洞。这是因为ESLint与大多数IDE都能很好地集成，并可以在编码过程中提供实时反馈。特别是它的样式规则可以自动修复代码错误，持续有效并且不会产生额外的开发成本。ESlint社区的文档很好地解释了它的编码模式，可以帮助开发人员快速掌握规则。随着ESLint变得越来越通用和强大，它已经被行业所认可。例如TypeScript团队就选择支持ESLint并与其合作，而非TSLint。

React Styleguidist是React组件的开发环境。它提供带有热重载功能的开发服务器，并可以生成HTML样式指南以便与团队进行共享。这个样式指南可以展示所有组件的最新版本，以及组件的使用文档和参数列表。我们之前在UI开发环境中介绍过React Styleguidist。而现在，相比与其他类似工具，React Styleguidist已成为我们的默认选择。

移动应用的构建、测试和部署，尤其是将流水线从代码仓库打通到应用商店的时候，会涉及许多复杂的步骤。虽然这些步骤可以由脚本或普通CI/CD工具提供的流水线自动完成，但我们团队发现，Bitrise这个专注移动应用的持续交付工具对于不需要集成后端流水线的团队来说会更有用。它配置简单，还预置了丰富的部署步骤，可以满足绝大多数移动应用开发所需。

使代码库的依赖保持最新是一件很麻烦的事，但是出于安全考虑，及时响应依赖的更新还是很重要的。你可以使用工具让这个过程尽可能轻松和自动化。我们的团队在实际使用Dependabot时觉得不错。它可以与GitHub仓库集成，自动检查依赖的版本更新，并在必要时提交一个升级依赖的PR。

Detekt是用于Kotlin的静态代码分析工具。Dekekt可以基于高度可配置的规则集提供代码坏味道以及复杂度的检查报告。可以通过命令行运行，也可以通过Gradle、SonarQube或IntelliJ以插件方式运行。我们的团队发现了使用Detekt来维护高质量代码的巨大价值。将分析及生成报告集成到构建流水线上后，显而易见，重要的是定期检查报告，并给团队留出时间解决所发现的问题。

交互和视觉设计的一大痛点是缺乏用于协作的工具，Figma就是为此而生的。它不仅具有与Sketch和Invision等设计程序相同的功能，而且还支持与其他人实时协作，帮助多人一起探索新的想法。我们的团队发现Figma非常有用，特别是它支持与简化了远程和分布式的设计工作。除了协作功能之外，Figma还提供了有助于改善DesignOps流程的API。

构建容器化应用程序可能需要在开发环境和构建代理上进行复杂的配置。如果你要构建Java应用程序并使用Docker，则可以考虑使用Google的Jib。Jib是同时支持Maven和Gradle的开源插件。Jib插件使用构建配置中的信息，将应用程序直接构建为Docker镜像，而不需要Dockerfile或Docker守护程序。Jib也针对镜像分层进行了优化，可以提升后续构建的速度。

Loki是一个配合Storybook使用的可视化回归工具，我们在UI开发环境中提到过Storybook。只需几行配置，就可以使用Loki测试所有UI组件。推荐在Docker容器中使用Chrome，以避免在不同的环境中运行测试时出现的1像素差异问题。我们的经验是测试非常稳定，但是Storybook的更新往往会由于细微的差异而导致测试失败。Loki似乎也无法测试使用position：fixed的组件，但可以使用fixed包装组件来规避这个问题。

我们应该在生成和部署容器的构建流水线中引入容器安全扫描。我们团队特别喜欢Trivy——一款用于容器的漏洞扫描器。它提供独立的二进制文件，相比于其他工具更容易安装和配置。而且Trivy是开源软件，并支持Distroless容器。

Twistlock是提供构建时和运行时安全漏洞检测和预防功能的商业产品，可以保护VM、容器调度程序和容器，以及应用程序依赖的各类注册中心和存储库。Twistlock帮助我们的团队加快了受监管应用程序的开发，这些应用程序的基础设施和架构需要遵循一定的规范，例如支付卡行业（PCI）标准和《健康保险可移植性和责任法案》（HIPAA）。我们的团队很享受Twistlock带来的开发人员体验：能够以代码形式管理资源，可以轻松地与其他常见可观察性平台进行集成，以及根据行业共识最佳实践来衡量基础架构的，直接可用的基准测试。我们在例行的运行时扫描过程中，尤其是在有合规性要求的情况下，使用Twistlock对云原生应用程序进行扫描。

我们可以看到，越来越多强大的IOT设备选择运行Linux而不是运行一个定制的嵌入式系统。然而为了节省资源并减少攻击面，仍然有必要创建一个自定义的Linux版本，其中只包含运行设备程序的相关工具和依赖。在这种情况下可以考虑使用Yocto。它可以针对具体的需求裁剪并创建自定义的Linux发行版。Yocto的学习曲线陡峭，并且由于它的灵活性很高，很容易出错。但是经过多年发展，Yocto已经建立起了一个活跃的社区，可以起到一些帮助。与同类工具相比，它更容易被集成至持续交付的工作流。而且与Android Things和Ubuntu core不同，Yocto并没有绑定在一个指定的生态系统上。

我们的软件大厦变得越来越复杂，也越来越难以理解。Aplas是一个新的软件映射工具，可以用地图的形式可视化软件布局。Aplas首先会获取当前系统的元数据，然后在地图上投影各种视图。可以手动或通过API自动获取元数据。我们很高兴看到该产品不断发展，也看到自动收集元数据所带来的种种可能性。例如，通过公开运行成本等架构适应度函数，应该可以可视化呈现云基础设施的成本。我们经常面临的另一个问题是想要了解哪些系统用何种技术与其他系统进行通讯，这一点也可以使用Aplas帮助我们进行可视化。

asdf-vm是一个按项目管理多语言运行时版本的命令行工具。它与Ruby的rvm和Node的nvm等其他命令行版本管理工具类似，但更可以通过可扩展的插件体系架构支持多语言。当前插件列表包括多种语言，以及Bazel或tflint等可能需要针对每个项目管理其运行时版本的工具。

AWSume是一个方便的脚本，用于在命令行中管理AWS会话令牌及担任角色凭证。当需要同时使用多个AWS账号时，AWSume就很有用武之地。这个脚本可以从CLI缓存中读取配置，省去了在每条命令中分别指定配置的麻烦。AWSume还可以将配置输出至环境变量，这样命令与AWS SDK都能够获取到正确的凭证。

数据转换是数据处理工作流的重要组成部分：筛选、分组或组合多个数据源，将它们转换为适合分析数据或机器学习模型使用的格式。dbt既是一个开源工具，也是一个商业化的SaaS产品，为数据分析师提供了简单高效的转换功能。现有的数据转换框架和工具，要么过分专注于功能强大和灵活性，却也要求对编程模型及语言框架有深刻的理解，例如Apache Spark；要么就只提供一些死板的界面拖放工具，而无法使用可靠的工程实践，如自动化测试和部署。dbt填补了这个空白：它使用被广泛理解的接口，SQL，对简单的批处理转换进行建模。同时dbt也提供了命令行工具以支持版本控制、自动化测试和部署等良好的工程实践。实际上，dbt基于SQL实现了转换模型即代码。目前，dbt支持包括SnowflakeSnowflake和Postgres在内的多种数据源，并提供Airflow及Apache自己的云服务等多种运行方式。dbt的转换能力受限于SQL，在撰写本文时还不支持实时的流式转换。

Docker Notary是对镜像、文件及容器等资产进行签名的开源工具，用于验证资产的来源。对于受控的环境来说这是超级有用的功能，而对于其他环境来说也是很好的实践。容器在创建时，会使用代表发布者身份的私钥及哈希进行签名，并存储至元数据。对于已经发布的容器（或其他资产），就可以用镜像的哈希以及发布者的公钥对其来源进行验证。虽然已经有Docker Trusted Registry这样可公开访问、可信任的注册中心，但也可以运行自己的注册中心。我们的团队在本地运行Notary服务时发现还有些问题，并建议使用其他支持Notary的注册中心。

不论是直接使用还是作为机器学习模型的训练输入，越来越多的重要决策源自于大数据集。因此了解数据中的差距、缺陷和潜在偏见十分重要。Google的Facets项目在此领域提供了两个有力工具：Facets Overview和Facets Dive。Facets Overview对数据集中的特征分布进行可视化，可以展现训练和验证集的偏斜，并且可以用于比较多个数据集；Facets Dive用于在大数据集中挖掘和可视化单个数据点，并使用不同的可视维度来探究属性之间的关系。它们都是进行道德偏差测试的有力工具。

随着人们普遍使用Kubernetes作为容器编排器，与容器和Kubernetes相关的安全工具也在快速发展。Falco就是一个专注运行时安全的容器原生工具。它利用Sysdig的Linux内核监控和系统调用性能数据，可以深度洞察系统的行为，进而帮助我们发现应用程序、容器、主机或者Kubernetes编排器自身的异常行为。我们喜欢Flaco，因为它不需要植入第三方的代码或者附加其他容器就能工作。

我们注意到，越来越多的地方，尤其是在受监管的行业，为了确保软件的供应链安全会使用二进制验证。当前主流的做法，或是构建一个定制的二进制验证系统，亦或是依赖于某个云厂商提供的服务。我们高兴地看到出现了开源的in-toto项目。In-toto是一个框架，能够以密码学的方式验证软件制品生产路径上的每个组件和步骤。该项目可以与众多广泛使用的构建工具、容器审计工具和部署工具进行集成。由于软件供应链工具是一个组织的安全设施中至关重要的部分，因此我们非常喜欢in-toto。作为一个开源项目，它的行为是透明的，并且其自身的完整性和供应链也可以由社区进行验证。至于它是否会赢得足够多的用户和贡献者以在这个领域竞争，我们拭目以待。

Kubeflow之所以令人感兴趣，是因为两个原因。首先，它是Kubernetes Operators的创新应用，我们在2019年4月版的技术雷达中对Kubernetes Operators进行了重点介绍。其次，它提供了一种对机器学习工作流进行编码和版本控制的方法，使它可以更容易地从一个执行环境移植到另一个环境。Kubeflow由几个组件组成，包括Jupyter notebooks、数据流水线和控制工具。其中一些组件被打包成为Kubernetes Operators，以利用Kubernetes响应Pod产生的事件的能力，而Pod可以实现工作流的各个阶段。通过将程序和数据打包为容器，可以将整个工作流程从一个环境移植到另一个环境。这有利于将有用但是计算能力要求极高的工作流，从云上转移到自定义超级计算机或者张量处理器（TPU）集群中。

如果应用程序将敏感信息（例如加密密钥）以纯文本的形式存储在内存中，很可能会被人利用成为攻击媒介而导致信息泄露。大多数基于云的解决方案通常使用HSM（hardware security modules，硬件安全模块）以避免受到此类攻击。但如果是自托管服务且无法使用HSM时，仍然希望避免这类攻击，MemGuard就非常有用了。MemGuard可以作为软件安全区，在内存中存储敏感信息。尽管MemGuard不能替代HSM，但它也实现了许多安全策略，如防止冷启动攻击，避免垃圾收集的干扰，并使用防护分页技术加固以减少泄露敏感数据的可能性。

横跨多个技术领域统一定义和实施安全策略很有挑战。即使对于简单的应用程序，也必须使用其组件内置的安全策略配置和实施机制，来控制对容器编排器、保存服务状态的服务及数据存储等组件的访问。

我们对开放策略代理（OPA）这个尝试解决此问题的开源技术感到非常兴奋。OPA可以使用Rego策略定义语言，以代码的方式进行细粒度的访问控制与灵活的策略定义。Rego在应用程序代码之外，以分布式且不干扰用户的方式实施策略。在撰写本文时，OPA以统一而灵活的策略定义及执行实现，确保了通过Envoy边车和Kafka访问Kubernetes API和微服务API的安全性。它也可以用作任何服务的边车，用以验证访问策略或过滤响应数据。OPA背后的公司Styra针对分布式策略的集中可见性提供提供商业化的解决方案。我们希望OPA可以通过CNCF孵化计划成熟起来，并继续为多样化的数据存储等更具挑战性的策略执行场景提供支持。

Pumba是Docker的混沌测试和网络仿真工具。Pumba可以终止、停止、删除或暂停docker容器，还可以仿真网络并模拟不同的网络故障，例如延迟、数据包丢失和带宽速率限制。Pumba使用tc工具进行网络仿真，因此在容器中需要安装tc，或者需要在带有tc的边车容器中运行Pumba。在对运行在多个容器中的分布式系统做混沌测试时，无论是从本地还是在构建流水线中都可以使用Pumba。

Google为我们带来了Skaffold——用于自动化本地开发工作流程的开源工具，同时也支持部署至Kubernetes。Skaffold会检测源代码的变更，触发工作流以构建，标记和部署到K8s集群中，并捕获应用程序日志返回命令行。工作流程支持将不同的构建和部署工具以插件化形式引入，并且还提供默认配置，使入门变得更容易。

机器学习世界的研究重点稍微从探索“模型能够理解什么”，转向了研究“模型是如何理解的”。由于人们担心引入偏差，或者过度泛化模型的适用性，因此开发出了What-If Tool（WIT）这样的工具。这个工具可帮助数据科学家深入研究模型的行为，并将各种功能和数据集对输出的影响进行可视化。WIT由Google引入，简化了比较模型、切片数据集、可视化构面和编辑单个数据点等任务，并可以在Tensorboard或Jupyter notebooks中使用。尽管WIT可以帮助执行分析，但研究者仍然需要对模型背后的数学和理论有深刻的理解。WIT只是数据科学家用来深入了解模型行为的工具，对于使用不当或缺乏训练不佳的算法，初级用户不应奢望有任何工具可以消除或减轻其风险或造成的损害。

Azure数据工厂（ADF）是Azure目前默认的用于编排数据处理流水线的产品，可以用于数据提取，在使用不同存储类型的自有产品或者Azure服务之间复制数据，以及执行数据转换逻辑。尽管我们在使用ADF做简单的自有服务数据上云的迁移时感觉还可以，但我们不推荐使用Azure数据工厂来编排复杂的数据处理流水线。我们使用ADF的体验一直很不好，原因包括：可以通过代码实现的功能有限，因为ADF似乎优先考虑的是实现低代码开发平台的功能；可调试性和错误报告差；整个流水线的可观察性有限，因为ADF的日志记录功能无法与其他产品（如Azure Data Lake Storage或Databricks）集成，因此开发者难以实现流水线的端到端可观察性；以及只有部分地区能够使用数据源触发机制。因此，目前我们推荐使用其他开源编排工具（例如Airflow）来处理复杂的数据流水线，而仅使用ADF进行数据复制或数据快照。我们期望ADF未来会解决这些问题，以支持更复杂的数据处理工作流，并可以通过代码使用新功能。