好不容易小白將系統開發完成，對於發布到服務器端並沒有什么經驗，於是在下班后又找到老菜。
小白：老大，不好意思又要麻煩你了，項目已經弄完，但要發布上線我還一頭霧水，有空幫我講解一下嗎？
老菜：嗯，系統上線並不一件簡單的事情，它可大可小。如果准備不充分，有可能會很多問題出現。你認為寫好代碼后要怎么發布？
小白：呃，完成開發后，上傳到服務器，然后瀏覽器可以正常訪問...
老菜：看來得普及一下上線的相關知識才行。
正規的產品上線一般可以按下面幾個步驟來進行：
1. 開發人員自測（開發環境）
2. 測試人員測試（測試環境上）
3. 預生產環境測試
4. 生產環境測試
但根據我所接觸的眾多公司來看，沒有測試人員的公司就占了多數，各公司的BOSS們甚至技術負責人都沒有測試的意識，將產品測試交給開發人員或業務人員進行，其產生的后果怎么樣就不得而知了。往小方面說用戶體驗不好，往大方面說可能更新后造成數據丟失，生產環境停機一段時間的情況。
對於開發人員自測，很多程序員都沒有這個習慣，多數都是寫完代碼，自己以為肯定沒有問題，然后往服務器上一扔就完事了，等其他同事或客戶使用時進行測試，很多時候會出現500或各種bug，問起來都是因為粗心、沒注意到或不小心造成的，有時等得到反饋時已經過上好長一段時間了，系統掛了多久都不知道。以前所在公司就遇過有技術人員一個小問題用了超長時間才開發出來，提交了不知多少次到測試環境都不通過，bug反復出現，被測試經理罵的狗血淋頭的情況，我在旁邊看着都差點忍不住上去懟上一份。可以看得出來，沒有自測也是造成測試與開發矛盾的重要原因之一。
當然包括我在內，以前也沒有養成自測的習慣，沒有測試人員的約束，寫好代碼就往生產環境上扔，出現故障就在生產環境上調測或還原代碼，再慢慢改的情況。以前也以為有沒有測試都無所謂，最近幾年一直待在有測試團隊的公司里就不一樣的，有了約束以后，雖然更新效率和速度打大折扣，但代碼質量和穩定得到了飛躍性的提升。平時碼代碼也會習慣性完成后用各種參數跑一下，而使用測試的思維去寫代碼以后，代碼的安全性、嚴謹性得到了很大的提升。
自測它是一種態度，它也是一種習慣。
一般有測試崗位的公司，都會創建一套測試環境專門給測試人員來進行測試，因為測試與開發共用一個環境時，數據很多時候就會造成混亂，其中一方辛辛苦苦建的數據，另一方拿來就用，又或者技術人員習慣直接打開數據庫改數據，某些數據狀態突然改變了，而測試人員以為是bug，造成不必要的困擾。一般來說，開發人員在開發環境上自測沒有問題以后，才會將代碼打包提交給測試人員更新到測試環境上。這個更新頻率一般都在固定時間，而不是非常頻繁，除非有重大bug測試人員無法繼續下去，因為每一個版本的更新，測試人員都會從頭到尾，按寫好的測試用例全部重新跑一次，頻繁的更新會造成測試人員工作量非常大。
測試前，標准來說測試人員一般分制定測試規范，做好測試計划和寫測試用例，測試階段會分為功能測試（可能會有功能1、功能2、功能3等多次測試）、UI測試、兼容性測試、性能測試、安全性測、UAT測試等，完成后會提交一份測試報告。不過很多時候測試規范、計划和報告都會被省略了，測試用例有時也可能會被略過，每家公司根據自己的需要也會進行對應的調整。
專業的測試是一個枯燥、重復、非常有耐心且敬業的職位，也是我很佩服的一個崗位。
很多公司產品開發完后是直接上線的，並沒有預生產環境進行測試，好多一些重大的安全事故就是這樣造成的。比如說沒留意sql語句，不小心將生產環境的數據表給清空了；比如說更新后生產環境直接崩潰等情況在工作中時有發生。今年我在的公司也試過發生比較嚴重的問題，合作公司的小伙伴開發時代碼循環寫錯了，沒有經過全面測試就直接發布，APP發版后造成我方生產環境業務接口訪問量暴增，短短幾天訪問量暴漲到6千萬，服務器流量、CPU、內存等全部滿負荷運行，影響到了其他合作公司業務的正常運行，由於生產環境不能停，服務器端只能通過快速擴容服務器組為高可用群組解決，客戶端通過快速發布新版替換。
如果服務器並不是太多的影響下，通常預生產環境和生產環境放在一個服務器里，它只是一個數據庫與程序的拷貝。條件充足時，會在本地搭建一個和生產環境一模一樣的環境，來做發布前測試。預生產環境測試，可以幫我們避開很多服務器環境因素（配置或包不一致等情況）、數據庫結構或配置因素（數據庫結構調整未更新或記錄參數改變后未同步等情況）和sql語句缺陷等問題造成的重大錯誤。
對於重大版本或變更更新時，預生產環境測試是有嚴格的更新步驟要求的。在整個預發布測試過程中，必須實時記錄下每一個步驟的操作。對於重大更新，下面的步驟有時可能需要反復操作多次，這樣才能保障更新到生產環境是完全無誤的。
1)本地測試環境上測試通過，准備好更新代碼包、數據庫更新腳本、服務器配置更新腳本和修改說明文檔；
2)清空預生產測試舊的數據庫與程序（對於小版本更新可以直接在舊環境上進行，不必做這一步操作；另外如果數據庫數據量比較大時，可繼續使用舊環境數據）；
3)備份預生產測試環境里的代碼、數據庫與相關配置文件；
4)獲取生產環境中的代碼、數據庫與相關配置文件，並將它們更新到預生產測試環境中，搭建好可以正常運行；
5)開始發布，新服務器配置文件；
6)更新數據庫腳本；
7)更新代碼包；
8)運行前后端程序，進行全面測試（所有功能都必須跑過一次），檢查程序是否可以正常運行；
9)如果此次更新不會對原系統產生破壞性變更，程序正常后就可以按預發布部署到生產環境上。
10)如果需要錄入或變更相關配置數據，可以讓相關維護人員登陸操作錄入或修改內容，並測試通過；
11)導出維護人員錄入的數據腳本；
12)再次還原生產環境的代碼、數據庫與相關配置文件到預生產測試環境中；
13)執行第5步到第7步的操作，並將第11步導出的數據腳本更新到數據庫中；
14)執行第8步操作，確認沒有問題后，發布到生產環境中。
正常來說，更新到生產環境的代碼是測試過沒有問題的，但有可能有些功能只能在生產環境上才能進行測試，所以一般發布都會選一個晚深人夜，沒有什么客戶使用時來進行的。更新以后需要快速進行測試，保證系統上線后運行正常沒有問題。
常見的更新是熱更新，即直接上傳更新；也有使用svn等自動化工具進行同步更新，更新完成后，svn的勾子自動將代碼同步到其他服務器上，並重啟指的服務；還可以關閉高可用其中一個對外訪問的節點來更新測試，等這個節點內部測試沒有問題，再自動同步到其他節點上；如果是微服務架構，還可以使用微服務自動安裝發布，自動同步注冊更新的功能......不同的企業，服務架構不一樣，更新的步驟與方式也不同。
前面的內容聽起來好像有點復雜，有點多，不過對於你這個小站點來說，就不用那么操作了。你首先要做的是購買好域名，做好域名備案相關工作；然后購買一台雲服務器，按我博客里的教程安裝配置好服務器；最后將你的代碼發布到服務器上去就可以了。
你按下面鏈接去搭建的話，你的程序大體上運行不會出現什么問題，下面配置是bate版的服務器環境搭建，是我研究運維配置好的服務器自己學習后寫的，配置好后能正常的訪問不會有太大的問題。如果想要應對高並發，需要在這個基礎上進行調優處理，另外uwsgi最好使用xml配置，因為xml和ini所使用的包是不一樣的，運行時效率和穩定性相差比較大，我們服務器處理每秒7百多並發就是使用xml配置的。
版權聲明：本文原創發表於 博客園，作者為 AllEmpty 本文歡迎轉載，但未經作者同意必須保留此段聲明，且在文章頁面明顯位置給出原文連接，否則視為侵權。
python開發QQ群：669058475（本群已滿）、733466321（可以加2群） 作者博客：http://www.cnblogs.com/EmptyFS/