請問大家都使用什麼方案進行生產環境的代碼發布？

01-27

有時候會出現研發提交錯文件版本，導致更新包的文件版本比生產環境舊的情況，有沒有方案可以解決這個問題？

建立一個team，每次需要release的時候就告訴他們去source control那裡拿第幾個版本的代碼，然後自己編譯，跑測試，寫config上傳伺服器，on call，剩下的Windows Cluster會自己搞定。

總之不能讓開發來干，兩邊機器的許可權要隔離，這是最重要的。

謝邀。我不明白什麼叫研發提交錯版本？

是說遇到代碼衝突之後，就沒解決，直接拿舊版本覆蓋了嗎？無論你們用git還是用svn，都應該沒有這個可能啊！

—————等你評論一下具體問題再補充，下面我要說說運維—————

你如果看過我回答的其他問題，應該能發現我反對設立運維崗位。因為運維如果只是做代碼發布，這個崗位就沒有創造價值。沒有價值的崗位就不應該存在。

做系統級別的運維應該有，因為這是一個足夠抽象足夠隔離的領域，就好像資料庫有獨立崗位一樣。

如果運維的存在只是為了隔離生產環境，那應該用規則和程序來實現，並不是人。

寫手機程序的工程師，寫好程序一定要到實際硬體上去測試。為什麼不能模擬器跑成功就交付？因為要負責。

同樣道理，寫一個網路程序憑什麼就測到開發環境就不管了？既然這個程序是7*24跑的，你就要對它7*24的負責。說人不能7*24小時盯著那是架構太爛，冗餘都沒有。

不同類型的程序難點和平衡都不一樣。運維的存在就讓一部分沒有能力做網路開發的人進入了這個圈子。

如果有機會做決策，我強烈建議不要設立運維崗位。

公司：開發完畢-》把更新文件製作補丁包(tar包寫一個 install uninstall 的makefile)-》發給測試或自己測試-》發給運維安裝。

個人項目：拉分支-》開發完合併到相應版本-》直接在生產環境git pull。

目前沒有遇到過版本、文件搞錯的問題。

輪子哥說的辦法，是換了另一撥人來弄。也許會有作用，但是沒有從根本上杜絕這撥人也會犯錯的可能。

所以，不如考慮考慮go或者Jenkins ，做個部署流水線？用它們來部署，每次去想部署的那個版本上點一下按鈕，就好了。

當然了，你也可以說點錯了怎麼辦？我也沒辦法…

至少在那倆工具的界面上，有比較明顯的標誌，你說的那種，把比產品環境上更老的版本部上去，會極大概率避免掉…

提交到黑盒有人從黑盒拿到白盒然後發布

然而執行並不嚴格