我們如何改進我們的部署和構建系統？

Question

我們有4個不同的環境：

• 分期
• 開發
• 用戶驗收
• 直播

我們使用TFS，拉下最新的代碼和代碼了。
當他們完成某項功能時，開發人員將其更改單獨上傳到暫存。如果網站穩定（由非常寬鬆的測試確定），我們將更改上傳到Dev，然後上傳UserAcceptance，然後進行直播。

我們在源代碼控制中根本沒有使用build/tags。

我應該告訴管理層什麼？據我所知，他們似乎認爲沒有問題。

Answer 1

告訴他們，如果你使用的是一個非常昂貴的軟件的關鍵特性，他們花了很多錢，那麼告訴什麼代碼什麼時候被推出將是微不足道的。這意味着如果引入了一個微妙的錯誤，並通過了用戶驗收測試，那麼就可以通過區分這兩個版本來確定發生了什麼變化。

Answer 2

誰的管理？他們離你多遠？

I.e.如果你只是一名莊家開發人員，而你的經理是高級開發人員，那麼你會找到另一份工作。如果您是高級開發人員，而您的經理是CIO類型，即實際運行業務......那麼您的工作就是改變它。

Answer 3

使用標記最重要的部分之一就是您可以回滾到特定時間點。將其視爲圖像備份。如果部署錯誤，您可以安全地假設您可以「回滾」回到以前的工作版本。另外，開發人員可以快速獲取TAG（dev，prod或其他），並將其部署到他們的開發PC ...我一直使用的功能來調試生產問題。

Answer 4

如果這對你有好處，你可以成爲貴公司的Continuous Integration冠軍。你可以做一些關於CI with TFS的良好流程的研究，寫出一個建議的解決方案，向你的開發者和直接經理人傳授，並用他們的意見對它進行修改，並將其發佈給管理層。或者你可以坐在那裏什麼都不做。

我一直在管理很長一段時間。我總是很感謝能夠識別問題並提出深思熟慮的解決方案的人。

Answer 5

因此，您需要有人告訴其他開發人員，他們必須在每次構建完成時爲其代碼添加標籤並增加版本計數器。你爲什麼不能那樣做？

您還需要告訴管理層您認爲所做測試的級別不足。對於一個組織來說這不是一個獨特的問題，他們可能會說他們已經知道了。雖然沒有提到它，但並沒有等待一個重大問題的到來。

就個人進行構建或自動構建過程而言，這取決於您是否真的需要基於多少開發人員以及您構建的頻率。

Answer 6

什麼是的問題？正如你所說，你不能分辨管理層是否看到問題。也許他們不會！告訴他們你認爲目前的問題以及你會建議如何解決問題。問題的關鍵在於「我們目前的流程已經失敗了3次，實施這個新流程會將這些失敗次數降低到10次之一」。

管理層需要看到改進：降低成本，增加利潤，縮短時間，減少資源使用。 「因爲這是廣泛使用的最佳實踐」還不夠。也不是，「因爲它讓我的工作更輕鬆」。

管理層往往沒有意識到問題，因爲每個人都太害怕說什麼或者認爲他們不可能看不到問題。但你的世界與他們的世界是不同的世界。

Answer 7

我看到至少兩個大問題： 1）開發人員自己加載更改。所有更改應該來自源代碼管理。你有沒有遇到過某些人做了一些改變，但沒有進入源代碼控制，然後在下一次部署時被意外刪除的時間？花了多少時間（金錢）試圖弄清楚那裏出了什麼問題？

2）缺乏明確的促銷模式。看起來你們正在改變環境而不是「構建」。關鍵的區別在於，如果UAT中的兩個變化因爲它們的相互作用而變得很好，那麼如果只有一個變化被提升爲生產，那麼它可能會在那裏發生變化。促進一致的代碼 - 無論是通過標記或僅通過壓縮整個Web應用程序並提升zip文件 - 應該會導致更少的問題。

我致力於持續集成和部署解決方案AnthillPro。我們如何通過TFS解決這個問題，就是根據日期時間戳（當有人按下「Deliver to Stage」按鈕時）從TFS中檢索新代碼。

這給了你大部分（所有？）追蹤你使用標籤的必要性，而不必實際去標記東西。系統只記錄時間戳，並且通過測試環境每次推送代碼都與已知的代碼快照關聯。我們也有將標籤作爲構建過程的一部分的客戶。作爲第一個提到的海報 - CI是一件好事 - 少工作，更多可追溯性。

Answer 8

如果你已經有TFS，那你就快到了。

我正在使用TFS進行源代碼管理。我們與Dev/Stage/Prod有類似的設置。我把它放在自己身上來安裝一個構建服務器。一旦完成，我添加了自動部署到我的項目開發的能力，並告訴其他人一些關於它。最初的招待會溫暖。

後來我加入了TFS部署者，並設置爲自動部署良好的開發版本。

在此期間，主要開發者羣體不斷與「在部署到舞臺或製作之前獲得最新成果？問題;我的東西工作順利。相信我，管理層和其他開發者注意到了。

現在（6個月），我們有一個書面規則，您甚至不允許在Visual Studio中使用Publish命令。一切都通過CI構建和部署。在轉向生產時，我們的生產組從生成服務器中提取適當的副本。我甚至對如何進行網絡測試的QA小組進行了培訓，並且我們正在慢慢地將自動化測試集成到整個文件中。

這個漫遊的一點是它花了一段時間。但更重要的是，它只發生，因爲我願意與它一起運行並顯示結果。

我建議你也這樣做。開始使用它，然後展示讓其他人蔘與的好處。