距离 RailsConf 差不多还有一段时间，我们决心在那之前发布 Rails 5.2 的最终版本。所以，这应该是最后一个正式发布前的候选版本。我们投入了大量的精力来解决 Active Storage 中的所有问题，特别是现在越来越多的应用程序开始在生产环境中使用它。
你可以查看自年初以来近 200 次提交，了解所有已修复的内容。
如果你正要开始一个新项目，我对这个版本非常有信心，建议你基于这个 RC2 版本来开发。如果你喜欢跟进最新版本，现在也是更新现有应用程序的好时机。
你可以在 刚刚完成的 Rails 5.2 发行说明中 了解更多关于 Rails 5.2 新特性的详细信息。
尽情享受 Rails 5.2 吧，希望一个月后在 RailsConf 上能见到大家！
在 Rails 中处理文件上传问题已经持续太久了。当然，一直有很多不错的插件可用，但将其集成到框架中已经势在必行。现在我们做到了！
在 Rails 5.2 的新 Active Storage 框架中，我们解决了直接将文件上传到云端的现代方法。开箱即用，支持 Amazon S3、Google Cloud Storage 和 Microsoft Azure Cloud File Storage。
如果您处理图像，可以实时创建变体。如果您处理视频或 PDF，可以实时创建预览。并且无论什么类型，都可以异步分析上传内容以提取元数据。
Active Storage 是由 George Claghorn 和我本人从 Basecamp 3 中提取出来的。因此，该框架不仅已经在生产环境中使用，而且诞生于生产环境。这无疑是一枚“提取设计”的保证印章！
说到提取，Jeremy Daer 已经解决了我们在 Basecamp 使用 Redis 进行通用部分、片段和其他 Rails 缓存工作的长期混杂做法。现在有一个全新的 Redis 缓存存储，它将多年来积累的经验整合到一个统一的单元中，供任何人使用。
这个新的 Redis 缓存存储支持 Redis::Distributed，用于跨 Redises 进行类似 Memcached 的分片。它具有容错性，会将故障视为缓存未命中，而不是通过异常中断请求。它甚至支持分布式的 MGETS，以实现完整的片段集合缓存功能。
配合 密钥回收 和 压缩 这两项默认提供的功能，缓存效率有了巨大的飞跃。对于 Basecamp 来说，这意味着缓存生命周期提高了两个数量级！我们从缓存只能维持一天变成可以维持数月。如果您使用片段缓存和嵌套策略，这两项改进将大大延长您的缓存生命周期。
通过 Aaron Patterson 和 Eileen Uchitelle 的工作，我们还通过 早期提示拥抱了 HTTP/2 的精髓。这意味着我们可以自动指示 Web 服务器尽早发送所需的样式表和 JavaScript 资源。这带来了更快的整页加载速度，谁不想要呢？
在性能方面，Rails 现在默认在 Gemfile 中包含了由我们的朋友 Shopify 开发的 Bootsnap。它通常可以将应用程序启动时间缩短 50% 以上。
Rails 一直走在让 Web 应用程序更安全的the forefront，通过内置的 CSRF 和 XSS 保护引领潮流，在 Rails 5.2 中，我们通过添加一个新的 DSL 进一步增强了这一点，该 DSL 允许您为应用程序配置 内容安全策略。您可以配置一个全局默认策略，然后按资源基础覆盖它，甚至可以使用 lambda 来将每个请求的值注入到标头中，例如多租户应用程序中的帐户子域。
但这并非全是新的光鲜亮点。在 Rails 5.1 中，我们添加了 加密密钥。这些密钥就像旧密钥一样，但，嗯，更秘密，因为，您知道，是加密的！令人困惑？是的。为什么您会想要不那么秘密的密钥？嗯，您不会。
在 Rails 5.2 中，我们纠正了这个混乱，弃用了两种不同类型的密钥，并引入了一个新的共享概念，称为 Credentials。Credentials，例如 AWS 访问密钥和其他形式的登录凭据和密码，是密钥的主要用例，所以为什么不直接称其为“凭据”呢？所以就是凭据！
Credentials 始终是加密的。这意味着将它们提交到版本控制是安全的，只要您不将密钥也提交进去。这带来了原子部署、无需处理大量的环境变量，以及其他将应用程序所需的所有凭据集中在一个安全地方的好处。
此外，我们还公开了 Credentials 的底层 API，以便您可以轻松处理其他加密配置、密钥和文件。
自 Rails 5.1 以来，我们在 Webpacker 方面也取得了长足的进步。因此，Rails 5.2 将与新的 Webpacker 3.0 版本完美搭配。Rails 已通过由 Webpack 运行的预配置构建管道完全拥抱了现代 JavaScript。我们将继续加强这种关系。