㈠ 大公司里怎樣開發和部署前端代碼
雖然美團不是大公司，但在這里寫一下我們的情況，僅供參考。開發時的和部署時類庫的引用和存放是一致還是不同?開發環境和部署環境的類庫代碼都是相同的，但物理位置不同。部署環境的類庫在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項技術元素都直接或間接的對前端開發工具設計產生一定的影響，因此能否串聯其他技術要素，使得前端開發形成一個連貫可持續優化的開發體系，工具的設計至關重要。