软件行业的大部分对话都是围绕开发人员体验展开的。从衡量生产力的新方法到减少重要但繁琐的工作，组织正在寻求让开发人员的生活更加快乐。
越来越受到关注的一个领域是使用构建包为云原生环境创建应用程序。尽管不是一个新概念（buildpack 已经存在了大约 15 年），但它们可以通过简单地获取源代码并将其转换为功能齐全的应用程序来减轻开发人员的负担。
Cloud Foundry 首席布道者 Ram Iyengar 表示，回顾一下历史：Heroku 在 2010 年提出了从源代码创建不可变对象的概念，无论编程语言或平台如何。Cloud Foundry（开源项目）正在努力做到这一点大致相同的事情，但是是开源的。 Pivotal 是 Cloud Foundry 项目作为商业工具的早期支持者和开发者，这两个项目都在 2015 年发布了 v2。但是当 Pivotal 于 2019 年被 VMware 收购时，成立了 Cloud Foundry 基金会来引导该项目，即现在由云原生计算基金会赞助。
Pivotal 的路径是利用提供的源代码制作容器，而 Heroku 的愿景不包括容器。在云原生与非云原生的争论中，存在着一种分歧，即所有内容都在容器中运行，以及并非所有内容都在容器中运行。因此，Heroku 和 Pivotal/Cloud Foundry 联手创建了与云原生生态系统兼容的云原生 Buildpack，Iyengar 表示，这意味着“它必须是开源的，必须遵守 OCI 规范，并且它必须准备好在 Kubernetes 上部署并利用云原生结构。”
Iyengar 表示，非 Kubernetes 版本 2 的构建包在可预见的未来将继续存在，而“针对容器和 Kubernetes 的构建包则有更新、更闪亮的版本”。
Iyengar 表示，Heroku 继续其闭源商业实施（此后已开源），而 Cloud Foundry 基金会于 2020 年创建了 Paketo 构建包，该构建包是开源且可投入生产的。
关于开发者体验的一切
当我们回顾过去时，构建包的好处之一是改善开发人员体验。 Iyengar 说，虽然 Javascript 开发人员可以通过六七种方式获得工具从源代码为您提供功能性应用程序的体验，但如果您不使用 Javascript，那么该工具基本上毫无用处。 Packeto 构建包使开发人员能够获得相同的构建体验，无论源代码语言如何。
“构建包可能实现的同质性是惊人的，这就是我所说的开发人员体验的真正含义，”艾扬格说。 “它允许开发人员引入任何语言或框架，并为他们提供同质且完整的用户界面，以便为他们提供尽可能一流的开发体验。”
Iyengar 还指出，buildpack 可以克服使用 Docker 等技术时存在的自动化障碍。他说：“对于开发人员或软件工程团队来说，维护 Docker 文件以进行本地开发和生产，创建这些 Docker 文件并维护它们很快就会变成一个巨大的开发地狱。”Buildpack 使用户不必编写这些文件元文件并维护它们。”他解释说，在基于 Docker 的构建过程中，如果您想为 GitHub 操作编写不同的 Docker 文件，而不是在预生产机器上运行它们，则有不同的要求。这不是最优的。”他说，无论您运行的基础设施如何，Buildpack 都可以使流程统一。
Iyengar 表示，SBOM（软件物料清单）也是如此，今后，您将能够在 x86 映像和 ARM 映像之间进行选择，并在构建过程中指示您想要哪种映像并使它们全部可用。 “构建包社区对自动化的关注是巨大的。”此外，他指出，该项目提供了可用于生产的 Buildpack，这些 Buildpack 也与 CI/CD 集成（例如 CircleCI、Gitlab、Tekton 等）兼容。
由于 buildpack 可以透明地显示图像中的内容以及图像可以包含和不能包含的内容，因此这就是 buildpack 和 AI 的交叉点。 “任何能够读取和解析构建包元数据的人工智能都可以非常方便地查看需要设置哪些策略，并且您可以创建规则，例如如果容器包含特定版本的 Go，则不要创建容器或将其推送到生产环境过时或存在漏洞，”艾扬格说。“而且，如果检测到新漏洞，人工智能引擎基本上会遍历所有构建包层并说，‘这些是受影响的层，让我们替换它们立即地。'他补充说，缓解措施变得非常微不足道。
Iyengar 表示，buildpacks 社区的重点是“填补基于 Docker 的生态系统留下的许多空白，但真正重要的是在部署镜像时了解镜像内部的内容。”他说，Buildpacks 使在我们现代的、安全第一的云原生环境中，可以轻松证明和创建图像所需的来源，未来，内置 SBOM 将不仅仅是一种便利，而且将成为一项合规性要求。
