㈠ 大公司里怎样开发和部署前端代码
虽然美团不是大公司，但在这里写一下我们的情况，仅供参考。开发时的和部署时类库的引用和存放是一致还是不同?开发环境和部署环境的类库代码都是相同的，但物理位置不同。部署环境的类库在CDN上，开发环境的类库在开发服务器上。模块放在项目中还是放在 CDN 之类服务器?模块放在项目中，部署时都在CDN上。渲染网页用 Nginx 还是其他动态语言的 Web 服务器?前面用ngnix做负载均衡，后面用apache做web服务器。制作网页的流程, 是现有设计师的稿, 还是先看模块?先有设计师的稿再写模块，但很多时候并不需要设计师，因为架子已经搭好了，界面规范和基础元素都有，一般的界面前端工程师都能搞得定。会选择用自己写的模块还是从社区寻找模块?基础框架用的YUI3，大部分二次开发的底层模块，还有和业务紧密结合的UI模块都是自己写的。当然也会用社区写的模块，比如上传组件、highcharts、Ace等。如果说怎么选择模块的话，那就是具体情况具体分析了，总体原则有两个：能不自己写，就不自己写；选择最符合需求的，一般来说，要么选最好的，要么选最快出结果的。
㈡ 怎么开发和部署前端代码
先部署页面，再部署资源：在二者部署的时间间隔内，如果有用户访问页面，就会在新的页面结构中加载旧的资源，并且把这个旧版本的资源当做新版本缓存起来，其结果就是：用户访问到了一个样式错乱的页面，除非手动刷新，否则在资源缓存过期之前，页面会一直执行错误。
先部署资源，再部署页面：在部署时间间隔之内，有旧版本资源本地缓存的用户访问网站，由于请求的页面是旧版本的，资源引用没有改变，浏览器将直接使用本地缓存，这种情况下页面展现正常；但没有本地缓存或者缓存过期的用户访问网站，就会出现旧版本页面加载新版本资源的情况，导致页面执行错误，但当页面完成部署，这部分用户再次访问页面又会恢复正常了。
- 总之，前端性能优化绝逼是一个工程问题！
好的，上面一坨分析想说的就是：先部署谁都不成！都会导致部署过程中发生页面错乱的问题。所以，访问量不大的项目，可以让研发同学苦逼一把，等到半夜偷偷上线，先上静态资源，再部署页面，看起来问题少一些。
但是，大公司超变态，没有这样的“绝对低峰期”，只有“相对低峰期”。So，为了稳定的服务，还得继续追求极致啊！
这个奇葩问题，起源于资源的 覆盖式发布，用 待发布资源 覆盖 已发布资源，就有这种问题。解决它也好办，就是实现 非覆盖式发布。
<img src="https://pic4.mg.com/50/_hd.jpg" data-rawwidth="631" data-rawheight="456" class="origin_image zh-lightbox-thumb" width="631" data-original="https://pic4.mg.com/_r.jpg">
好了，目前我们快速的学习了一下前端工程中关于静态资源缓存要面临的优化和部署问题，新的问题又来了：这™让工程师怎么写码啊！！！
要解释优化与工程的结合处理思路，又会扯出一堆有关模块化开发、资源加载、请求合并、前端框架等等的工程问题，以上只是开了个头，解决方案才是精髓，但要说的太多太多，有空再慢慢展开吧。或者大家可以去我的blog看其中的一些拆解：fouber/blog · GitHub
以上不是我YY的，可以观察 网络 或者 facebook 的页面以及静态资源源代码，查看它们的资源引用路径处理，以及网络请中静态资源的缓存控制部分。再次赞叹facebook的前端工程建设水平，跪舔了。
建议前端工程师多多关注前端工程领域，也许有人会觉得自己的产品很小，不用这么变态，但很有可能说不定某天你就需要做出这样的改变了。而且，如果我们能把事情做得更极致，为什么不去做呢？
另外，也不要觉得这些是运维或者后端工程师要解决的问题。如果由其他角色来解决，大家总是把自己不关心的问题丢给别人，那么前端工程师的开发过程将受到极大的限制，这种情况甚至在某些大公司都不少见！
㈢ 前后端分离的前端是怎么部署到生产环境中的，直接通过 nginx 吗
1>>前端离意思前端通 JSON 交流... 同意其几位JSON 种选协议唯未必前端通信佳案 2>>组件化、工程化需要依赖端实现...哪些处或弊端 前端组件化、工程化js 等代码越越胖点类似于 C/S 代 fat client所问题相于计算主要放 client server Fat client
㈣ 如何高效部署前端代码，如css，js
1.利用浏览器的304缓存，但是304叫协商缓存，还是需要与服务器通信一次
2.强制使用浏览器使用本地缓存（cache-control/expires），但是问题来了，不让浏览器发资源请求，资源怎么更新。
3.使用版本号，类似于a.css?v=1.0，b.css?v=1.0，做了更改的时候都变成a.css?v=2.0，b.css?v=2.0，有时候a.css改变了，b.css没有改变，不是多此一举吗？
4.使用数据摘要算法，类似于a.css?v=0abc23，b.css?v=65ao1j，如果a.css做了更改的话，a.css=v=1asd2j，b.css还是b.css?v=65ao1j。
5.很多企业，现在都静态文件cdn部署了，类似于http://static.cdn.com/css/a.css?v=0abc23，与页面分开部署了，
a.如果先部署页面，再部署资源：在二者部署的时间间隔内，如果有用户访问页面，就会在新的页面结构中加载旧的资源，并且把这个旧版本的资源当做新版本缓存起来，其结果就是：用户访问到了一个样式错乱的页面，除非手动刷新，否则在资源缓存过期之前，页面会一直执行错误。
b.如果先部署资源，再部署页面：
在部署时间间隔之内，有旧版本资源本地缓存的用户访问网站，由于请求的页面是旧版本的，资源引用没有改变，浏览器将直接使用本地缓存，这种情况下页面展现正常；但没有本地缓存或者缓存过期的用户访问网站，就会出现旧版本页面加载新版本资源的情况，导致页面执行错误，但当页面完成部署，这部分用户再次访问页面又会恢复正常了。
解决方法：改变命名方式，改成a_0abc23.css，上线的时候先部署静态资源，再部署页面。
㈤ 前端怎么把网页部署到tomcat 怎么启动tomcat
首先配置下Myeclipse里Tomcat服务 在Windows-->Preferences-->MyEclipse-->Application Servers 中选择你的tomcat版本，在右侧的面板里指定tomcat的安装路径后，点击Apply或OK保存
㈥ 一个前端页面如何部署
一个前端页面，在本地直接打开就能访问。另外如果是要放到服务器下的话，可以装个nginx，或者apache，或者tomcat，直接放到网页路径下，就行。
㈦ 前端通过gulp编译后的文件，怎么部署到服务器
服务器上写部署脚本，从代码库里拉项目代码，跑gulp自动化。或者打包传给后端让他搞。
㈧ 如何把webpack前端工程部署到tomcat上
几种方法：
1、在myeclipse里部署
这个直接在myeclipse里配置好tomcat的根路径。
在server里可以看到tomcat，选择部署你的工程就行了。
2、把自己的web工程放在tomcat的webapps下
2.1 把你的工程达成war包，放进tomcat的webapps下；
2.2 把你工程的webroot下的内容用你的工程名称（其实是你想要的在啊浏览器访问的应用路径名）作为文件夹包住webroot下的内容（要保证你的classes有东西，lib有东西）
3、把描述自己工程的context放在webapps下
context里可以描述你的工程的名称，工程存放的路径
4、在tomcat的conf/server.xml配置相应的context元素
这个和3的作用差不多，只是这个是在tomcat的server启动时加载的
以上都能让tomcat知道自己有多少应用要部署，将会进行相应的部署动作。部署完后，就可以在浏览器访问了。
㈨ 前端的代码怎么部署到服务器
1、安装护卫神主机大师，一键配置全能网站环境
2、用主机大师开设网站，并绑定域名
3、解析域名到服务器IP
4、FTP上传前端代码到服务器
5、输入域名即可访问前端代码了
㈩ 常见的前端集成部署方案有哪些各自的优缺点是什么
前端行业经历了这么长时间的发展，技术元素非常丰富，这里列举出一般web团队需要用到的技术元素：
开发规范：包括开发、部署的目录规范，编码规范等。不要小瞧规范的威力，可以极大的提升开发效率，真正优秀的规范不会让使用者感到约束，而是能帮助他们快速定位问题，提升效率。
模块化开发：针对js、css，以功能或业务为单元组织代码。js方面解决独立作用域、依赖管理、api暴露、按需加载与执行、安全合并等问题，css方面解决依赖管理、组件内部样式管理等问题。是提升前端开发效率的重要基础。现在流行的模块化框架有requirejs、seajs等。
组件化开发：在模块化基础上，以页面小部件(component)为单位将页面小部件的js、css、html代码片段放在一起进行开发、维护，组件单元是资源独立的，组件在系统内可复用。比如头部(header)、尾部(footer)、搜索框(searchbar)、导航(menu)、对话框(dialog)等，甚至一些复杂的组件比如编辑器(editor)等。通常业务会针对组件化的js部分进行必要的封装，解决一些常见的组件渲染、交互问题。
组件仓库：有了组件化，我们希望将一些非常通用的组件放到一个公共的地方供团队共享，方便新项目复用，这个时候我们就需要引入一个组件仓库的东西，现在流行的组件库有bower、component等。团队发展到一定规模后，组件库的需求会变得非常强烈。
性能优化：这里的性能优化是指能够通过工程手段保证的性能优化点。由于其内容比较丰富，就不在这里展开了，感兴趣的同学可以阅读我的这两篇文章 [1] [2]。性能优化是前端项目发展到一定阶段必须经历的过程。这部分我想强调的一点是性能优化一定是一个工程问题和统计问题，不能用工程手段保证的性能优化是不靠谱的，优化时只考虑一个页面的首次加载，不考虑全局在宏观统计上的优化提升也是片面的。
项目部署：部署按照现行业界的分工标准，虽然不是前端的工作范畴，但它对性能优化有直接的影响，包括静态资源缓存、cdn、非覆盖式发布等问题。合理的静态资源资源部署可以为前端性能带来较大的优化空间。
开发流程：完整的开发流程包括本地开发调试、视觉效果走查确认、前后端联调、提测、上线等环节。对开发流程的改善可以大幅降低开发的时间成本，工作这些年见过很多独立的系统（cms系统、静态资源推送系统）将开发流程割裂开，对前端开发的效率有严重的阻碍。
开发工具：这里说的工具不是指IDE，而是工程工具，包括构建与优化工具、开发-调试-部署等流程工具，以及组件库获取、提交等相关工具，甚至运营、文档、配置发布等平台工具。前端开发需要工具支持，这个问题的根本原因来自前端领域语言特性（未来我会单独写一篇文章介绍前端领域语言缺陷问题）。前端开发所使用的语言（js、css、html）以及前端工程资源的加载与定位策略决定了前端工程必须要工具支持。由于这些工具通常都是独立的系统，要想把它们串联起来，才有了yeoman这样的封装。前面提到的7项技术元素都直接或间接的对前端开发工具设计产生一定的影响，因此能否串联其他技术要素，使得前端开发形成一个连贯可持续优化的开发体系，工具的设计至关重要。