個人第一個python web開發框架（19）——產品發佈相關事項

　　好不容易小白將系統開發完成，對於發佈到服務器端並無什麼經驗，因而在下班後又找到老菜。

　　小白：老大，很差意思又要麻煩你了，項目已經弄完，但要發佈上線我還一頭霧水，有空幫我講解一下嗎？

　　老菜：嗯，系統上線並不一件簡單的事情，它可大可小。若是準備不充分，有可能會不少問題出現。你認爲寫好代碼後要怎麼發佈？

　　小白：呃，完成開發後，上傳到服務器，而後瀏覽器能夠正常訪問...

　　老菜：看來得普及一下上線的相關知識才行。

　　正規的產品上線通常能夠按下面幾個步驟來進行：

　　1. 開發人員自測（開發環境）

　　2. 測試人員測試（測試環境上）

　　3. 預生產環境測試

　　4. 生產環境測試

　　但根據我所接觸的衆多公司來看，沒有測試人員的公司就佔了多數，各公司的BOSS們甚至技術負責人都沒有測試的意識，將產品測試交給開發人員或業務人員進行，其產生的後果怎麼樣就不得而知了。往小方面說用戶體驗很差，往大方面說可能更新後形成數據丟失，生產環境停機一段時間的狀況。

　　對於開發人員自測，不少程序員都沒有這個習慣，多數都是寫完代碼，本身覺得確定沒有問題，而後往服務器上一扔就完事了，等其餘同事或客戶使用時進行測試，不少時候會出現500或各類bug，問起來都是由於粗心、沒注意到或不當心形成的，有時等獲得反饋時已通過上好長一段時間了，系統掛了多久都不知道。之前所在公司就遇過有技術人員一個小問題用了超長時間纔開發出來，提交了不知多少次到測試環境都不經過，bug反覆出現，被測試經理罵的狗血淋頭的狀況，我在旁邊看着都差點忍不住上去懟上一份。能夠看得出來，沒有自測也是形成測試與開發矛盾的重要緣由之一。

　　固然包括我在內，之前也沒有養成自測的習慣，沒有測試人員的約束，寫好代碼就往生產環境上扔，出現故障就在生產環境上調測或還原代碼，再慢慢改的狀況。之前也覺得有沒有測試都無所謂，最近幾年一直待在有測試團隊的公司裏就不同的，有了約束之後，雖然更新效率和速度打大折扣，但代碼質量和穩定獲得了飛躍性的提高。平時碼代碼也會習慣性完成後用各類參數跑一下，而使用測試的思惟去寫代碼之後，代碼的安全性、嚴謹性獲得了很大的提高。

　　自測它是一種態度，它也是一種習慣。

 

　　通常有測試崗位的公司，都會建立一套測試環境專門給測試人員來進行測試，由於測試與開發共用一個環境時，數據不少時候就會形成混亂，其中一方辛辛苦苦建的數據，另外一方拿來就用，又或者技術人員習慣直接打開數據庫改數據，某些數據狀態忽然改變了，而測試人員覺得是bug，形成沒必要要的困擾。通常來講，開發人員在開發環境上自測沒有問題之後，纔會將代碼打包提交給測試人員更新到測試環境上。這個更新頻率通常都在固定時間，而不是很是頻繁，除非有重大bug測試人員沒法繼續下去，由於每個版本的更新，測試人員都會從頭至尾，按寫好的測試用例所有從新跑一次，頻繁的更新會形成測試人員工做量很是大。

　　測試前，標準來講測試人員通常分制定測試規範，作好測試計劃和寫測試用例，測試階段會分爲功能測試（可能會有功能一、功能二、功能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配置的。

　　python服務器環境搭建（1）——本地服務器準備

　　python服務器環境搭建（2）——安裝相關軟件

　　python服務器環境搭建（3）——參數配置

 

 

版權聲明：本文原創發表於 博客園，做者爲 AllEmpty 本文歡迎轉載，但未經做者贊成必須保留此段聲明，且在文章頁面明顯位置給出原文鏈接，不然視爲侵權。

python開發QQ羣：669058475（本羣已滿）、733466321（能夠加2羣）    做者博客：http://www.cnblogs.com/EmptyFS/