在前端错误报告方面，Sentry已经成了许多团队的默认选项。Sentry提供了一些便利的功能，比如错误分组，以及使用适当的参数定义错误过滤规则，可以极大地帮助处理来自终端用户设备的大量错误。通过将Sentry集成到持续交付流水线中，你可以上传源码映射文件，从而更高效地调试错误，并能很容易追踪到是在哪个版本的软件中产生了这些错误。我们很欣赏尽管Sentry是一个SaaS产品，但它的源代码是公开的，这样就可以免费用于一些较小的用例和自托管中。

让网络具有包容性，就需要重视在软件交付的所有阶段都考虑并验证它的可访问性。许多流行的可访问性测试工具，都是为对完成后的Web应用程序进行测试而设计的。结果问题往往发现得较晚，并且更难解决，最终累积成为债务。最近在ThoughtWorks网站上工作时，我们将开源可访问性（a11y）测试引擎 axe-core 纳入了构建流程。它为团队成员提供了关于遵守无障碍规则的早期反馈，即使在早期增长阶段也是如此。但是，并非每个问题都可以通过自动检查发现。商业版的axe DevTools扩展了axe-core的功能，其中包括可以指导团队成员针对大多数可访问性问题进行探索性测试。

自从上一次介绍dbt以来，我们在一些项目中使用了它。例如，我们倾向于使用dbt完成ELT管道中转换部分的工作，使其更容易被数据消费者访问，而不是仅由数据工程师构建ELT管道。dbt通过鼓励良好的工程实践，如版本控制、自动化测试和部署，来实现这一点。SQL仍然是数据世界(包括数据库、仓库、查询引擎、数据湖和分析平台)的通用语言，大多数系统都在一定程度上支持它。这就使得这些系统可以通过构建适配器来使用dbt进行转换。原生连接器的数量不断增长并囊括了Snowflake、BigQuery、Redshift和Postgres，社区插件的范围也在扩张。我们看到像dbt这样的工具正在帮助数据平台变得更加“自助”。

我们一直渴望找到可以缩短软件开发反馈周期的工具。 esbuild就是这样一个工具。 随着前端代码库逐渐变大，我们经常会遇到打包时间过长的问题。esbuild 是一个对打包速度进行了优化的 JavaScript 打包器，它可以将打包时间减少 10 到 100 倍。它是用 Golang 编写的，并且使用了更高效的方式进行解析、打印和生成 sourcemap，构建速度远远超过了 Webpack 和 Parcel 这样的工具。esbuild 可能在 JavaScript 语法转换方面没有它们全面，但这并不妨碍我们很多团队将 esbuild 作为默认的打包工具。

Flipper是可扩展的移动应用程序调试工具。它开箱即用，支持profiling，交互式布局检查，日志查看器以及适用于iOS，Android和React Native应用程序的网络检查器。与其他用于移动应用程序的调试工具相比，我们发现Flipper轻量级，功能丰富且易于设置。

在之前的技术雷达中，我们就关注到了Great Expectations，我们继续看好它，并在本期技术雷达中将它挪入试验阶段。Great Expectations这个框架可以搭建内置控件，来标记数据流水线中的异常或质量问题。正如单元测试在构建流水线中运行一样，Great Expectations在执行数据流水线时也会进行断言。它的简单性和易用性深得我们喜爱——断言的规则用JSON文件存储，可以由我们的数据科学家来修改，所以不需要数据工程技能。

自从第一次将k6放入技术雷达中，我们对使用k6进行性能测试有了更多经验，使用结果也很不错。我们的团队很喜欢这种关注开发人员体验并且很灵活的工具，虽然k6很容易上手，但它真正的亮点在于很容易集成到开发人员的生态系统当中。比如 Datadog 适配器，团队能快速可视化分布式系统中的性能，并在将系统发布到生产环境之前识别重大的问题。再比如另一个团队使用k6的商业版本，可以使用Azure流水线插件商店将性能测试集成进他们的持续交付流水线中，并可以轻松获得Azure DevOps报告。由于k6支持允许自动化测试断言的阈值，因此在流水线中添加一个阶段来检测新增代码是否会导致性能下降会变得更轻松，从而为开发人员添加强大的反馈机制。

MLflow 是一款用于机器学习实验跟踪)和生命周期管理的开源工具。开发和持续进化一个机器学习模型的工作流包括，一系列实验（一些运行的集合），跟踪这些实验的效果（一些指标的集合），以及跟踪和调整模型（项目）。MLflow 可以通过支持已有的开源标准，以及与这个生态中许多其他工具的良好集成，来友好地辅助这个工作流。在 AWS 和 Azure 中，MLflow 作为云上 Databricks 的受管服务，正在加速成熟，我们已经在我们的项目中成功使用过它。我们还发现 MLflow 是一个模型管理，以及跟踪和支持基于 UI 和 API 交互模型的很棒的工具。唯一的担忧在于，MLflow 作为单一平台，一直在尝试交付太多的混淆关注点，比如模型服务和打分。

OR-Tools 是用于解决组合优化问题的开源软件套件。 这些优化问题有很多可能的解决方案，而OR-Tools之类的工具对于寻求最佳解决方案非常有帮助。 你可以使用任何一种支持语言（Python，Java，C#或C++）对问题建模，然后从几种支持的开源或商业选项中选择解决方案。 我们已经在整数和混合整数编程的多个优化项目中成功使用了OR-Tools。

Playwright允许你使用同一套API，为Chromium，Firefox和WebKit编写Web UI测试。由于对所有主流浏览器引擎的支持（包括Firefox和WebKit的修复版本），这个工具已经引起了一些关注。我们持续听到关于Playwright积极的使用体验和反馈，尤其是它的稳定性。一些团队发现从Puppeteer迁移到Playwright也非常容易，因为它们的API非常相似。

我们很高兴看到基础设施配置扫描工具的可用性和成熟度都越来越好：Prowler帮助团队扫描AWS基础设施配置，并根据扫描结果提高安全性。 尽管Prowler已经存在了一段时间，但在过去的几年中，它有了长足的进步，我们也发现了通过一个较短的反馈闭环来提升项目安全性的价值。 Prowler将AWS CIS benchmarking分为几类（身份和权限管理，日志，监控，网络，CIS Level 1，CIS Level 2，EKS-CIS），其中包括许多检查，可以帮助你深入了解PCI DSS和GDPR合规性。

尽管 鸭子类型 很自然地被许多Python程序员看作是一个功能，但有时类型检查仍然很有用，尤其是在一些大型的代码库中。基于这个原因，许多类型注解被作为Python增强建议（PEP）而提出，Pyright就是一个可以与这些注解协同工作的类型检查器。此外，它还提供了一些类型推断和类型保护，来理解条件代码流的构造。由于设计时考虑到了一些大型的代码库，Pyright运行速度很快，它的“监视”模式允许它在修改文件时执行快速增量更新，以进一步缩短反馈周期。Pyright可以直接通过命令行使用，但也同样可以与VS Code，Emacs，vim，Sublime以及其它一些编辑器集成使用。在我们的经验中，相比mypy之类的替代方案，我们更青睐Pyright。

采用“谁构建，谁运行”的DevOps理念，意味着团队已经增加了对技术和业务指标的关注，这些指标可以从他们部署的系统中提取出来。我们经常发现，分析工具对于大多数开发人员来说都很难使用，所以捕获和呈现指标的工作就留给了其他团队——而这已经是在交付功能给最终用户很久之后的事了。我们的团队发现，Redash 可以让普通开发人员以自助的方式创建仪表板，这对于查询产品指标非常有用，它缩短了反馈周期，并让整个团队专注于业务产出。

Terratest 在过去曾经作为基础设施测试的一个选项，吸引了我们的注意。从那时候起，我们的团队就一直在使用它，并且对它的稳定性及它所提供的体验感到非常兴奋。Terratest是一个Golang库，用来简化基础设施代码的自动化测试编写。通过基础设施即代码的工具，例如Terraform，你可以创建真实的基础设施组件(如服务器、防火墙或负载均衡器)，在它们之上部署应用程序，并使用Terratest验证预期的行为。在测试结束后，Terratest可以取消应用的部署并清理资源。对于基础设施在真实环境中的端到端测试，该工具非常有用。

Tuple是一个相对较新的远程结对编程工具，它希望能够填补Slack放弃Screenhero后留下的市场空白。虽然它现在还有比如暂时只能在Mac OS上使用（即将支持Linux），以及一些界面问题需要解决。但即使有这些限制，我们也已经在使用中拥有了很好的体验。和类似Zoom这种通用的视频屏幕共享工具不同，Tuple支持有两个鼠标光标的双侧控制；也和其他的选择比如Visual Studio Live Share不同，它不需要受限于IDE内。Tuple支持语音和视频通话、剪切板共享和相对其他工具较低的延迟；你还可以轻松的在另一方的屏幕上画画和擦除。这些特性让Tuple成为了一款十分方便直观和对开发者友好的工具。

使用React开发时，我们经常会遇到的情况是：因为某些组件进行了不必要的重复渲染而导致页面性能很差。Why Did You Render是一个能够帮助侦测组件重新渲染的库。它是通过对React的猴子补丁实现了这一点。我们在一些项目中使用它来调试性能问题，并取得了很好的效果。

尽管Docker已经成为容器化的默认选项，这个领域的新玩家还是吸引了我们的注意Buildah和Podman就是这种情况，它们是在多个Linux发行版中使用rootless 方法构建映像(Buildah)和运行容器(Podman)的互补项目。Podman引入了一个无守护进程的引擎，来管理和运行容器，与Docker相比，这是一个有趣的方法。事实上，Podman可以使用Buildah或Docker创建的OCI (Open Container Initiative) 镜像，这样工具变得更有吸引力，也更容易使用。

在我们的工具箱中，CI服务器与构建工具最为古老，使用也最广泛。其工作范围包括简单的云托管服务，一直到复杂的、由代码定义的、支持大型构建机群的流水线服务。鉴于市面上已经有大量的同类产品，当另一个用于管理构建与集成工作流 GitHub Actions 出现时，基于经验我们起初抱有怀疑的态度。但是 GitHub Actions 为开发者提供了小步启动并可以轻松自定义的行为，并逐渐成为小型项目的默认选项。将构建工具直接集成到源代码库实在很方便，因此社区也很活跃。大量用户贡献了工具以及工作流，便于快速上手。工具供应商也可以通过 GitHub Marketplace 提供服务。但是，我们仍然建议你保持谨慎。因为尽管代码和 Git 历史记录可以导出到其他服务器中，但是基于 GitHub Actions 的开发工作流程却不能。另外，你也需要自行判断何时项目会变得足够大或足够复杂，而需要使用有独立支持的流水线工具。但对于初创而需要快速运行的、较小的项目，仍然值得考虑 GitHub Actions 及其不断发展的生态系统。

Graal原生镜像是一种以静态链接可执行文件或共享库的形式，将Java代码编译为操作系统本机二进制代码的技术。原生镜像经过优化，减少了应用程序的内存占用和启动时间。我们的团队已经成功地在serverless架构中，将Graal原生镜像作为小型Docker容器执行，减少了启动时间。尽管Graal原生镜像是为与Go或Rust等编程语言一起使用而设计的，这些编程语言需要本机编译，需要更小的二进制文件尺寸和更短的启动时间，但对于有其他需求并希望使用基于jvm的语言的团队来说，Graal原生镜像也同样有用。

Graal原生镜像构建器，native-image，支持基于jvm的语言——如Java、Scala、Clojure和Kotlin——并能在多个操作系统上构建可执行文件，如Mac OS、Windows和众多Linux发行版。由于它需要一个封闭的假设，即所有代码在编译时都是已知的，因此需要对诸如反射或动态类加载这样的特性进行额外的配置，因为不能在构建时仅从代码推断出类型。

在代理访问你的主机和服务的场景下，安全网络和身份管理的能力是不可或缺的，HashiCorp Boundary将这些能力合并在一处，如果需要，还可以连接多种云服务和本地自行部署的资源。密钥管理可以通过集成你选择的密钥服务来实现，无论是云厂商提供的密钥服务，还是诸如HashiCorp Vault这样的工具。HashiCorp Boundary支持越来越多的身份认证提供方，并且可以集成到你的服务整体架构当中，来帮助定义主机甚至是服务级别的权限。比如说，它可以用来实现对Kubernetes集群的细粒度访问控制。HashiCorp Boundary也正在继续开发以支持更多功能，诸如从不同的来源动态拉取服务目录。所有这些实现都被封装在HashiCorp Boundary当中，对作为终端用户的、习惯于shell使用体验的工程师来说是不可见的，这一切都是通过Boundary的网络管理层安全地进行连接。

还记得在研究项目pix2code中，如何通过图形用户界面的截图自动生成代码吗？现在这个技术已经出现了产品化的版本— imgcook，它是阿里巴巴旗下的软件即服务产品。它可以通过智能化技术把不同种类的视觉稿(Sketch/PSD/静态图片)一键生成前端代码。在双十一购物狂欢节期间，阿里巴巴需要定制大量的活动广告页面。经常会有一次性页面需要被快速开发完成。通过深度学习方法，用户体验设计师的设计，首先被处理为前端代码，然后由开发人员进行调整。我们的团队正在评估这项技术：尽管图像处理是在服务器端进行的，主页界面却在网页上，imgcook提供可以集成软件设计及开发生命周期的 工具 。imgcook可以生成静态代码，如果你定义了领域专用语言，它也可以生成数据绑定模块代码，该技术还没达到完美的程度，设计人员需要参考某些规范，以提高代码生成的准确性（此后仍需开发人员的调整）。我们对于魔术代码生成一直十分谨慎，因为从长远看，生成的代码通常很难维护，imgcook也不例外。但是如果你限定它用于特定的上下文，例如一次性活动广告页，这项技术值得一试。

Longhorn 是Kubernetes的分布式块存储系统。 Kubernetes有很多持久性存储选项，但是，Longhorn与大多数存储选项不同，它是从头开始构建的，提供了增量快照和备份，从而减轻了在非云托管的Kubernetes上运行复制存储的痛苦。随着Longhorn最近对ReadWriteMany（RWX）的实验性支持，你甚至可以挂载相同的存储卷，来进行跨多个节点的读写访问。为Kubernetes选择合适的存储系统是一项艰巨的任务，我们建议你根据需求评估使用Longhorn。

Operator框架是一套开源工具，可简化Kubernetes operators的构建和生命周期管理。Kubernetes operator模式最初由CoreOS引入，是一种使用Kubernetes原生能力来封装操作应用程序知识的方法；它包括要管理的资源和确保资源与其目标状态匹配的控制器代码。这种方法已被用于扩展Kubernetes，以原生化管理众多应用程序，特别是有状态的应用程序。Operator框架有三个组件：Operator SDK，简化了Kubernetes operators的构建、测试和打包；Operators生命周期管理器负责operators的安装、管理和升级；以及发布和共享第三方operators的目录。我们的团队发现Operator SDK在快速开发kubernetes原生应用程序时特别强大。

大型云服务供应商的服务数量持续增长，对应工具的便利性和成熟度也在不断提高。Recommender 是谷歌云的一项服务，可以分析现有资源，并根据实际使用量给出如何优化的建议。该服务包含了针对安全、计算使用以及节省成本等方面的一系列 Recommender。例如，IAM 角色 通过指出未曾使用过的可能过于宽泛的权限，来帮助更好地实现最小权限原则。

在过去的几年里，我们曾经讨论过几次 Windows Subsystem for Linux (WSL)。尽管我们欣喜于看见WSL的进步，比如WSL2的改进，却一直没有将它收录在技术雷达中。这一期里，我们想要着重介绍一个Visual Studio Code插件，它能够显著提升WSL的使用体验。Windows中的代码编辑器虽然可以访问WSL文件系统，但是并不能感知隔离的Linux环境。然而有了 Remote - WSL 插件，Visual Studio Code 不仅可以感知WSL，还允许开发者启动Linux shell，并且支持在Windows下调试WSL里运行的二进制代码。在 WSL支持 中可以看到，Jetbrains的IntelliJ也在这方面做出了稳步的改进。

我们在本期技术雷达中反复看到的一种模式是，当一种新的语言变得流行以后，静态错误和样式检查工具会迅速浮现出来。这些工具通常被称作linters——以经典且深受欢迎的可以静态分析C代码的Unix工具 lint命名。我们喜欢这些工具，因为它们会更早捕获异常，甚至在代码未编译之前。这个模式最新的例子是关于YAML和JSON的linter Spectral。尽管Spectral可用作这些文件格式的通用检查工具，但它的主要目标是OpenAPI（Swagger和AsyncAPI的演化版本）。Spectral为这些规范提供了全面的开箱即用的规则，帮助开发者们在设计和实现API或事件驱动协作中避免麻烦。这些规则可以检查API参数规范或者规范中存在的许可声明等。虽然这个工具成为API开发工作流中广受欢迎的补充，它仍然提出了一个问题：即非执行文件的规范是否应该如此复杂，以至于需要为编程语言设计专门的错误检查技术。也许开发者们应该写的是代码而非规范？

Yelp detect-secrets是一个用于检测代码库中存储的密码的Python模块；它会扫描一个路径下所有的文件寻找密码。它可以被用作Git预提交钩子或在CI/CD流水线的适当位置来进行扫描。它的默认配置上手十分容易，如果有需要也可以进行自定义配置。你还可以安装自定义插件去扩充它默认的启发式搜索。与其他相似的工具比较，我们发现这款工具光以开箱即用的配置，就可以检测到更多种类的密码。

随着API规范生态系统的成熟，我们看到了更多可以自动化检查样式的工具。Zally是一个简便的基于OpenAPI的代码扫描工具，它有助于确保API遵循团队制定的API样式指南。以开箱即用的方式，Zally会针对为Zalando的API样式指南开发的规则集进行验证，同时它还支持基于Kotlin扩展机制开发自定义的样式规则。Zally提供了直观的UI界面，展示样式违规的地方，同时也提供了命令行工具，这样可以轻松地集成到持续交付流水线中。

根据ThoughtWorks多个团队的使用经验，我们建议你谨慎使用AWS CodePipeline。 具体来说，我们发现一旦团队的需求超出简单的流水线范畴，此工具就会变得难以使用。尽管初次使用AWS时，像是赢得了“快速的胜利”，但我们建议你后退一步，评估AWS CodePipeline是否可以满足你的长期需求，例如流水线的fan-out和fan-in，或者是更复杂的部署，以及具有特殊依赖关系及触发条件的测试场景。