然而，交付静态资源的过程并不都是如此顺利的。在开始持续部署静态资源之前，你的团队必须注意托管和交付中的陷阱。 以下是一些有关高效部署静态托管应用的技巧，帮助你实现持续、安全，以及最重要的，高效的交付流程。
一旦你的构建和测试过程不受服务器框架限制，也就释放了交付过程。一旦前端应用通过了集成测试，ci 服务器就可以构建一个正式版(参见技巧2)，直接交付并进行发布(参见技巧5)。
鉴于最近的趋势是将视图组件与样式定义放在一起，这一点可能稍有争议。但是，你需要权衡样式和代码捆绑后的利弊。
虽然多个文件会使交付过程稍显复杂，但文件缩小后带来的性能优势是值得我们这样做的。
除非你是个极端的纯粹主义者，每个打包应用都应该是由库模块和应用代码组成的。通常，你的应用代码比库模块更改得更为频繁。当你提供巨大的级联包时，客户端被迫下载每一次更新，哪怕改动很小。应用程序包通常推送3mb 的数据量，这又需要下载大量的代码，而仅仅是因为几行应用代码的更改。
使用内容分发网络发布静态应用。只要保留语义缓存，cdn 就允许客户端继续指向相同的 url。此外，在发布新代码时，即使缺乏资源指纹，也支持执行主动失效。主动失效会更新每个边缘服务器（也就是向客户端发布应用的服务器）上缓存的应用版本。
不要期望用户会重新加载浏览器。假设一些用户会运行旧版本的应用，并做好准备，处理一些已弃用功能的请求。将版本发布看作是一个连续的变化，并决定你的发布周期。
总会某一阶段，继续支持所有旧版本及它们可能包含的各种错误，是不切实际的。除非你部署的是一台自助服务机，更新周期非常不频繁，你可以放心地假设用户会每周重新加载一次。
在发布服务器端代码时，通常也会使用同样的方法，但是静态托管单页应用的风险更高。循序渐进的方法是至关重要的，因为回滚代码的速度取决于 cdn 的失效期。这意味着你若是发布了一个错误版本，它至少在生产环境中运行10分钟以上，而无法立即撤销。
应用资源和服务器代码若是绑定，部署单页应用就变得既简单又稳定。此外，你可以利用原生javascript 工具的优势，而不管应用框架是什么。核心是，服务器/浏览器的关系是一个简单的分布式系统。通过在服务器端单独部署单页面应用，你的团队可以获得微系统架构带来的灵活性，专注度以及优先度。