模块化在前端日新月异的工程化工具的推动下已经摆脱了前端模块加载器（SeaJS、RequireJS）的束缚，现在通常的方案是使用 browserify 或 webpack 来将模块化的文件打包，然后直接在浏览器端使用。
但是通常的打包策略是将整个项目打包成一个文件 bundle.js，默认情况下 bundle.js 中囊括了所有的依赖，包括第三方的从 node_modules 中加载的文件，这会造成 bundle.js 非常臃肿，而且在生产环境中不能很好的利用静态资源的缓存策略。这些打包技术在国外非常火，生产环境提供一个 bundle.js 的做法在国外的网络环境下毫无压力，但是国内的网络环境和国外的没法比，为了下载的性能还是建议分开打包。
分开打包还有一个好处就是，目前的前端开发环境现在都流行使用监测文件的变化而使用 livereload 技术，这也意味着会存在实时动态打包的需求，分开打包对于实时打包的速度有质的影响，对于基本不会变化的第三方模块没有必要每次做实时动态打包的时候都包含进去。
在 前端自动化构建和发布系统设计（一）中主要介绍了使用 gulp 来构建，本篇将主要介绍发布部分。
先来看一个完整的静态资源的 URI，http://a0.jmstatic.com/5d4f23234a51261e/common.css，这个 URI 由三部分组成，依次为 静态随机资源域名/文件 md5 值/原文件名 。
前端的业务逻辑和交互效果越来越复杂，代码量也随之越来越大，伴随着越来越大的代码量而来的还有代码的管理和部署的问题。模块化和预处理框架大行其道，新框架的出现让前端的开发环境越来越高大上了，但是部署到线上就越来越费劲了。在开发环境中模块化会将原本的大型应用分割成很多小模块，但是在上线的时候考虑到这些静态资源对 HTTP 请求数和请求体积的开销，很多小模块都需要合并然后再进行压缩。在 node.js 火起来之前，比较常见的处理工具有 ant，但是 ant 是基于 java 的，对于前端工程师来说使用起来很费劲。
node.js 火起来之后，出现了很多用于处理前端静态资源的优秀模块，还有专门用于前端静态资源构建的框架，如鼎鼎大名的 grunt，但是 grunt 由于其基于配置的设计模式和构建模式基于文件的限制，对于复杂一点的构建逻辑配置起来就会比较繁琐。
