菜单

工具

采纳?

  • Airflow仍然是我们广泛采用的最喜欢的开源工作流管理工具,用于构建作为有线无环图(DAGs)的数据处理流水线。这是一个蓬勃发展的领域,开源工具有 LuigiArgo,厂商工具则有 Azure Data Factory 或者 AWS Data Pipeline。然而 Airflow 特别之处在于它对工作流的程序化定义,而非低代码配置文件,以及对自动化测试的支持,开源并支持多平台,对数据生态丰富的集成点还有广泛的社区支持。不过在像数据网格这样的去中心化数据架构中,Airflow 的劣势在于它是一个中心化的工作流编排。

    历史信息
  • Bitrise,一款用于移动应用的领域特定 CD 工具,仍然是移动开发工作流中很有用的一部分。每个团队都应该去使用它。Bitrise 能够构建,测试和部署移动应用,从开发者的笔记本电脑一直到应用商店的发布。它易于配置,并提供了一整套预构建的步骤,来满足大多数移动开发的需要。

    历史信息
  • 在所有帮助保持依赖更新的可选工具中,Dependabot 一直是我们认为可靠的默认选择。Dependabot 跟GitHub 的集成平滑,并能自动发送你的pull request,更新依赖到最新的版本。它能在整个组织级别启动,这样所有团队接收到这些 pull request 要容易得多。即便你没有在使用 GitHub,也仍然可以在构建流水线中使用 Dependabot库。如果选择替代品,你可以考虑 Renovate,它支持更多的服务,包括 GitLab,Bitbucket 以及 Azure DevOps

    历史信息
  • Helm 是用于 Kubernetes 的包管理器。它附带一个专为 Kubernetes 应用甄选过的仓库,维护于Charts 的官方库中。之前我们提到过 Helm,现在 Helm 3已经发布,其中最显著的变化是 Helm 2的服务器端组件 Tiller 的移除。去掉 Tiller 的设计好处在于,你只能从客户端对 Kubernetes 集群作出修改,也就是说,你只能依据作为 Helm 命令行用户的权限来修改集群。我们已经在许多客户项目中使用了 Helm,它的依赖管理、模板以及钩子机制都极大简化了 Kubernetes 的应用生命周期管理。

    历史信息
  • 用来创建和部署容器的流水线,应该包含容器安全扫描这个步骤。我们的团队尤其喜欢 Trivy ——一个针对容器的漏洞扫描器。在这个领域的工具中,我们尝试过 ClairAnchore Engine。跟 Clair 不一样,Trivy 不止会检查容器,而且会检查代码库中的依赖。同时,由于它是一个独立的二进制包,所以更容易在本地设置和运行。Trivy 的其他好处还有,它是开源软件,并支持 distroless containers 容器。

    历史信息

试验?

  • Bokeh 是 Python 中最重要的库之一,通过 JavaScript 在浏览器中的渲染,它可以用于科学绘制和数据可视化。与创建出静态图像的桌面工具相比,这样的工具更易于在 web 应用探索中重用代码。Bokeh 尤其擅长这一点。这个库已经足够成熟,功能齐全。我们喜爱 Bokeh 之处在于:它保持对于作为展示层工具的专注,不会越界到比如数据聚合(参照 ggplot)或者 web 应用开发(参照 Shiny或者 Dash)。所以当分离关注点对你来说很重要时,使用 Bokeh 就是件很愉悦的事情了。Boken 提供了web UI 小部件,并能运行于服务器模式,但你可以伺机使用或者放弃这些特性。Bokeh 很灵活,使用方式很直白,它也没有那么多依赖(比如 pandas或者 notebooks)。

    历史信息
  • 要实现可持续跨多环境构建和部署生产软件的持续交付流水线,需要一种将构建流水线和工件视为一等公民的工具。当我们初次接触 Concourse 时,就喜欢上了它简单灵活的模型,基于容器的构建原理以及它迫使你定义 流水线即代码的事实。自那以后,Concourse 的可用性得到了改善,其简单的模型也经受住了时间的考验。我们的许多团队以及客户已经成功地将 Concourse 长时间用于大型流水线设置中。我们还经常借助 Concourse 的灵活性在例如硬件集成测试需要本地设置这种情况下随地工作。

    历史信息
  • 这一期雷达引入了一些新的工具,它们可以创建出帮助终端用户可视化并与数据交互的 web 应用。虽然还有更多简单的可视化库比如 D3,但它们在构建独立的可以操作既有数据集的分析应用上,还是减少了可观的工作量。来自 Plotly 的 Dash 在数据科学家中获得越来越多的关注,它可以用 Python 创建出功能丰富的分析应用。Dash 增强了 Python 数据类库,就像 Shiny 之于 R。这些应用有时会被认为是仪表盘,但它们可能涉及的功能,要远远超过这个名词所暗含的部分。Dash 尤其适合构建可伸缩的,随时可上线的应用,这跟同门类中另一个工具 Streamlit 不同。当你需要为商业用户呈现更复杂的分析功能时,请考虑使用 Dash,如果只是少量甚至零代码的方案,你可以选择 Tableau。

    历史信息
  • 维护大规模的 JavaScript 代码库从来不是一件容易的事情,而迁移重大的变更更是极具挑战。在简单的场景中,带有重构能力的 IDE 也许能帮得上忙。但是,如果代码库依赖广泛,每次想要做出重大的变更时,你都不得不遍历客户端代码库,才能做出合适的更新。这需要人工的监管并手工完成。jscodeshift,一个可以重构 JavaScript 和 TypeScript 的工具,能帮助减轻这种痛苦。它能把你的代码分析成抽象语法树(AST),并提供 API 通过不同的变换(也就是在既有的组件上添加、重命名以及删除属性)操作这棵树,然后把这棵树导出成最终源代码。jscodeshift 还附带一个简单的单元测试程序,它能用测试驱动开发的方法编写迁移 codemods。我们还发现 jscodeshift 对于维护设计系统尤其有效。

    历史信息
  • Kustomize 是一个管理和定制 Kubernetes 清单文件的工具。它能让你在把 Kubernetes 基础资源应用到不同环境之前,选择和修补它们。它现在已经获得了 kubectl 的原生支持。我们很喜欢它,因为它可以帮助你的代码遵守 DRY 原则。与 Helm(想干的事情太多——包管理、版本管理等等)相比,我们发现 Kustomize 遵循Unix哲学:把一件事情做好,以及每个程序的输出都可以成为另一个程序的输入。

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

    历史信息
  • 传统的测试方法通常聚焦于评估我们的生产代码是不是在做该做的事情。然而,我们也可能在测试代码中犯错,比如引入了不完整或者无用的断言,导致盲目的自信。这就是变异测试的由来;它会评估测试自身的质量,发现很难意识到的临界情况。我们的团队使用 Pitest 已经有一阵子了,现在推荐在 Java 项目中使用它,用于衡量测试套件的健康程度。简而言之,变异测试会给生产代码引入一点变化,然后再次执行相同的测试;如果测试仍然是绿色的,意味着测试不够好仍然需要改进。如果你在使用 Java 以外的语言,那 Stryker 是个好的选择。

    历史信息
  • Sentry 是一款跨平台应用监控工具,并聚焦在错误报告。像 Sentry 这样的工具,区分像 ELK Stack 那样传统的日志解决方案之处在于,它们重点关注发现、研究以及修复错误上。Sentry 已经面世有一阵子了,它支持多个语言和框架。我们在许多项目中使用过 Sentry,它在跟踪错误、发现某个提交是否真实修复了问题、以及警告我们有没有出现回归问题等方面帮助很大。

    历史信息
  • 尽管基础设施领域的工具已经得到了极大的改进,在某些情况下编写一些 shell 脚本仍然是有价值的。但是由于 shell 脚本的语法非常晦涩难懂,再加上我们现在对编写shell 脚本疏于练习,我们已经开始乐于使用 ShellCheck 来简化 shell 脚本的编写。ShellCheck 可以用于命令行,或者作为构建的一部分,甚至作为很多流行的集成开发环境的扩展来使用。它的 Wiki 页面包含了数百个 ShellCheck 可以识别的问题的详细描述,而且绝大多数的工具和集成开发环境在发现问题的时候,都提供了非常方便地方式来访问该问题对应的 Wiki 页面。

    历史信息
  • Stryker 是变异测试领域中一个较新的条目。与 Pitest 相似,Stryker 可以让你评估测试质量。我们已经在 JavaScript 项目上非常成功地使用了它,但是它也支持 C# 和 Scala 项目。Stryker 的用户友好性以及高度可定制性很强,这使得我们能提高代码覆盖率以及对我们为客户交付的应用程序的信心。

    历史信息
  • 我们已经广泛地使用 Terraform 来创建和管理云基础设施。根据我们的经验,在建立较大规模的基础设施时,代码往往会被拆分为若干个模块,并通过不同的方式被引入到基础设施的创建中,但是这种做法缺乏灵活性,进而会导致无法避免的代码重复,并最终会使团队停滞不前。我们通过使用 Terragrunt 来解决这个问题, 它是基于 Terraform 的一个很薄的包装层,它实现了 Yevgeniy Brikman 的 Terraform: Up and Running 倡导的实践。我们发现 Terragrunt 非常有用,它鼓励多环境的版本化模块和可复用性。生命周期钩子作为另一个非常有用的特性提供了更多的灵活性。在打包方面,Terragrunt 与 Terraform 具有相同的局限性:即没有一个合适的方式来定义包以及包与包之间的依赖关系。但是我们可以使用模块并指定一个与 Git 标签相关联的版本号来解决这个问题。

    历史信息
  • 安全是每个人都关心的问题,而防微杜渐永远都好过亡羊补牢。在基础设施即代码 领域,Terraform 已经成为管理云环境的不二之选,而且我们现在还有了 tfsec,一个可以用来扫描 Terraform 模板并发现潜在安全问题的静态分析工具。我们的团队在 tfsec 的使用上已经积累了非常成功的经验。tfsec 非常易于安装和使用,这使得它对于任何决心通过规避安全风险避免漏洞产生的开发团队而言,都是最佳的选择。针对不同的云提供商 tfsec 都预设了扫描规则,包括AWSAzure。对使用 Terraform 的团队而言,tfsec 实在是一个福音。

    历史信息
  • Yarn 仍然是许多团队在包管理器上的默认选择。我们对 Yarn 2的面世感到兴奋,它是一次全新的发布,包括大量的更新和改进。除了可用性优化和工作区的改进外,Yarn 2还引入了 zero-installs 的概念,它可以让开发者在克隆项目后直接运行项目。但是,Yarn 2也带来一些破坏性的变化,这让升级过程并不简单直白。而且它默认是即插即用(PnP)环境,同时不支持 React Native PnP 环境。当然,团队可以选择退出 PnP 环境,或者停留在 Yarn 1。但他们应该意识到,Yarn 1目前已经处于维护模式。

    历史信息

评估?

  • 在之前的雷达中,我们提到将机器学习的持续交付作为一种技术,而在这一期中,我们想重点推出一个极具前景的新工具——持续机器学习(或者叫 CML),它的创造者也创造了 DVC。CML 致力于把持续集成和持续交付的最佳工程实践引入到 AI 和 ML 的团队,同时帮助你在传统的软件工程技术栈之上,组织你的 MLOps,而不是创建单独的 AI 平台。我们对他们能优先支持 DVC 感到欣慰,认为这是新工具正在急速发展的好兆头。

    历史信息
  • 只要场景允许,我们一直信赖使用静态网站生成器来避免复杂性,并提升性能。虽然 Eleventy 出现已经有年头了,但它日渐成熟,最近重获我们的关注。而我们之前的喜好比如 Gatsby.js 出现了一些伸缩性的问题。Eleventy 学习起来很快,可以很容易构建出网站。我们还喜欢它的模板功能,可以方便地创建出语义标签(自然可访问性也更高),以及它对翻页简单又智能的支持。

    历史信息
  • 服务网格和 API 网关为流量路由到不同的微服务提供一个方便的方法,只要这些微服务都实现了相同的 API 接口。Flagger 利用这个特性,可以做到动态调整路由到某个新版本服务的部分流量。这对于金丝雀发布或者蓝绿部署是一项通用的技术。Flagger 和各种流行的代理(包括 Envoy 和 Kong)结合使用,可以逐步增加对于某个服务的请求,并报告负载的指标,从而为新的发布提供快速反馈。我们很高兴 Flagger 简化了这个极具价值的实践,从而可以被广泛采纳。虽然 Flagger 由 Weaveworks 赞助,但你可以独立使用 Flagger,无需捆绑使用 Weaveworks 的其他工具。

    历史信息
  • 当你想要连接到 AWS 上的某个服务器实例时,我们通常推荐要经由一个堡垒机,而不是直接连接。然而,仅仅因此而预置一台堡垒机的过程会让人崩溃掉,这也是为什么AWS 的系统会话管理器提供了管道来更容易地连接到你的服务器。Gossm 是一个开源的 CLI 工具,它可以更方便地使用会话管理器。Gossm 让你通过 ssh 或者 scp 这样的工具,在终端直接利用会话管理器的安全机制和 IAM 策略。它还有一些 AWS CLI 不具备的能力,包括服务器发现和 SSH 集成。

    历史信息
  • 随着 CD4ML 的兴起,数据工程和数据科学的运维方面获得了更多的关注。自动化数据治理是发展的结果之一。Great Expectations 是一款可以帮助你在数据流水线中,编制内建控件用于标记异常和质量问题的框架。就像运行在构建流水线中的单元测试,Great Expectations 在数据流水线的执行过程中作出断言。这不仅对于为数据流水线实现某种 Andon,或是确保基于模型的算法保持在训练数据决定的操作范围内,都有帮助。像这样的自动化控件可以帮助分发以及民主化数据访问和保管。Great Expectations 还配有一个探查工具,帮助理解特定数据集的质量,并设置合适的约束。

    历史信息
  • 我们对 k6 的出现感到很兴奋,它是性能测试生态环境中比较新的一款工具,尤其注重开发者体验。k6 命令行运行器执行 JavaScript 编写的脚本,并让你配置执行时间和虚拟用户的数目。它的命令行有一系列高级特性,比如可以在测试执行完成前,让你看到当前的统计数据,动态伸缩最初定义的虚拟用户数量,甚至暂停和继续一个运行中的测试。命令行输出提供了一套带有转换器的可定制指标,能让你在 Datadog 和其他观察工具中可视化结果。为你的脚本添加 checks,可以很容易将性能测试集成到你的CI/CD流水线中去。如果要加速性能测试,可以看看它的商业版本 k6 Cloud,它提供了云伸缩以及额外的可视化能力。

    历史信息
  • Katran 是一款高性能的 layer 4 负载均衡器。它并不适合所有人,但如果你需要 layer 7负载均衡器(比如 HAProxy 或者 NGINX)的替代品,或者你想要伸缩负载均衡器到两台及更多的服务器上,那我们推荐你评估一下 Katran。相对于 L7 负载均衡器上的循环 DNS 技术,或者网络工程师通常用于解决类似挑战的 IPVS 内核模型,我们把 Katran 看作一个更灵活和有效的选择。

    历史信息
  • 考虑到服务网格越来越多被用来部署大量的容器化微服务,我们期待看到能自动化并简化此类架构风格相关的管理工具的出现。Kiali 就是这样的工具。Kiali 提供了一个图形化用户界面,用于观察和控制使用 Istio 部署的服务网络。我们发现 Kiali 对可视化网络中的服务拓扑结构,并理解它们彼此之间的路由流量,尤其有帮助。比如,当和 Flagger 结合使用时,Kiali 可以显示出那些路由到某个金丝雀服务发布的请求。我们特别喜欢 Kiali 的一个能力,它能让我们向某个服务网格人工注入网络错误,以测试面临网络中断时的弹力。因为配置以及在复杂的微服务网格中运行错误测试带来的复杂度,这个实践经常会被忽略掉。

    历史信息
  • 编写安全的代码十分重要,但是开发人员还有很多其他事情需要考虑,不能把时间全花在这里。LGTM 不仅为开发人员提供了一道安全防护网,也是一个安全代码实践的知识库。这是一个专注于安全的静态代码分析工具,以 CodeQL 查询语言实现了(部分开放源代码的)安全编码规则。LGTM 适用于Java、Go、JavaScript、Python、C#及C/C++,并可以将白盒安全检查集成到持续集成流水线中。LGTM 与 CodeQL 都来自于 Github 安全实验室

    历史信息
  • Litmus 是一个低门槛的混沌工程工具。它可以用很低的代价往你的 Kubernetes 集群中注入各种各样的错误。除了随机干掉某些 Pod 之外,它提供的众多功能尤其让我们感到兴奋,比如仿真各种网络问题、CPU 问题、内存问题和 I/O 问题等。Litmus 还支持一些量身定制的试验,来仿真 Kafka 和 Cassandra 等常见服务中的错误。

    历史信息
  • 差分隐私的概念最初出现在2016年的雷达中。虽然通过系统模型推断查询来破坏隐私的问题在当时可以被识别出来,但因为几乎没有补救措施,它在很大程度上还是个理论性问题。整个行业都缺少能预防它发生的工具。Opacus 是一个 Python 的新库,可以结合PyTorch 使用,来帮助阻挡某种类型的差分隐私攻击。虽然这是很有前景的进展,但发现正确的模型以及能应用其上的数据集,一直颇具挑战。这个库仍然很新,所以我们拭目以待未来人们对它的接受度会变成什么样。

    历史信息
  • 能够识别出应用系统的依赖是否含有已知漏洞,对于开发团队来说是很重要的事情。OSS Index 可以帮助到这一点。OSS Index是一套免费的开源组件目录,以及设计用来帮助开发者识别漏洞、了解风险并确保软件安全的扫描工具。我们的团队已经通过不同的语言,把这份索引集成到流水线中,比如 AuditJSGradle plugin。它的运行速度很快,定位漏洞精准,并且几乎没有误报。

    历史信息
  • Web UI 测试一直是一片活跃的疆域。 Puppeteer 的部分缔造者在转向微软后,开始将所学投用在 Playwright。它可以让你通过相同的API,为Chromium、Firefox以及 WebKit 编写测试。因为对所有主流浏览器引擎的支持,Playwright 成功获得了一些关注,并作为补丁版本包含在 Firefox 和 Webkit 中。其他工具将如何赶上,让我们拭目以待,毕竟现在 Chrome DevTools Protocol 作为自动操作浏览器的通用 API,正在获得越来越多的支持。

    历史信息
  • pnpm 是一款很有前途的 Node.js 包管理器,它相对于其他包管理器的快速和更高的效率吸引了我们的密切关注。所有依赖被保存在磁盘上的唯一位置,并链接到各自的node_modeles目录。pnpm 还支持文件级别的增量优化,并提供了可靠的 API 来扩展和定制化,它还支持存储服务器模式,这可以更进一步加速依赖的下载。如果你的组织有大量的项目拥有相同的依赖,也许你需要关注一下 pnpm。

    历史信息
  • 来自 Secure Code Warrior 的 Sensei 是一款可以很容易地创建和分发安全代码质量规则的 Java IDE 插件。在 ThoughtWorks,我们通常提倡“工具胜过规则”,也就是说,要更容易地做正确的事情,而不是遵守像检查列表那样的治理规则和过程,而 Sensei 就符合这个哲学。开发者可以创建出很容易跟其他团队成员共享的代码片段。它们被实现成针对 Java AST 的查询,可以很简单,也可以很复杂,这样的例子包括对于 SQL 注入和加密漏洞的警告,以及其他。另外一个我们喜欢的特性是,Sensei 在 IDE 中一旦发现代码变化就开始执行,因此它比其他传统的静态分析工具提供了更快的反馈。

    历史信息
  • Zola 是用 Rust 编写的静态网站生成器。它是一个没有依赖的可执行文件,执行速度非常快,并且支持你期望的所有常用功能,例如,支持 Sass、markdown 和热加载。我们已经成功地使用 Zola 构建了静态网站,并欣赏它的易用性。

    历史信息

暂缓?

    无法找到需要的信息?

    每期技术雷达中的条目都在试图反映我们在过去六个月中的技术洞见,或许你所搜索的内容已经在前几期中出现过。由于我们有太多想要谈论的内容,有时候不得不剔除一些长期没有发生变化的条目。技术雷达来自于我们的主观经验,而非全面的市场分析,所以你可能会找不到自己最在意的技术条目。

    新的,移进/移出 ,没有变化