1. 首頁
  2. 問答
  3. 想出一個更好的ASP.NET部署策略

想出一個更好的ASP.NET部署策略

2011-10-04 61 views
10

在工作中，我們目前使用以下部署策略：想出一個更好的ASP.NET部署策略

  • 運行一個批處理腳本清除所有臨時ASP.NET文件
  • 運行的批處理腳本編譯每 ASPX文件到自己的DLL（的ASP.NET Web站點，不是Web應用程序）
  • 複製的每個單獨改變的文件（ASPX和DLL）到現場服務器上的相應文件夾。
  • 打開Deployment Scripts文件夾，在生產數據庫上手動運行每個SQL腳本（表格修改，存儲過程等）。
  • 在睡覺前說一聲祈禱（也許是在這個開玩笑吧）
  • 第二天早上測試第一件事物，並希望最好的 - 修復出現的錯誤。

我們一直咬在過去幾次，因爲有人會忘記運行一個腳本，或者認爲他們跑的東西，但沒有，或改寫，因爲有兩個文件相關的一些模塊存儲過程（一個在Sprocs文件夾中，在[ModuleName]相關文件夾中），或複製錯誤的DLL（因爲它們可以具有相同的名稱，就像由.NET生成的隨機字母數字編號一樣）。

這對我來說似乎效率很低 - 很多手動的東西，而且很容易出錯。由於所有的手動步驟，開發人員有時需要2-3個或更多的時間才能執行部署（我們在深夜執行，例如午夜），並記住需要複製哪些文件以及需要複製的文件，需要什麼要運行的腳本，確保腳本以正確的順序運行等

必須有了比服用兩個小時複製並粘貼個人ASPX頁面，DLL文件，圖像更簡單的方法，樣式表等，並手動運行30多個SQL腳本。我們使用SVN作爲我們的源代碼控制系統（主要是爲了更新/提交，雖然我們不做分支），但沒有單元測試或測試策略。是否有某種工具可以幫助我們使部署更順暢？

來源

2011-10-04 Wayne Molina

回答

8

我沒有經歷所有這些，但Troy Hunt的You're deploying it wrong系列可能是一個很好的看點。

分的系列討論：

  • 配置轉換
  • 構建自動化
  • 持續集成

來源

2011-10-04 13:17:01

3

我們有四個階段，它可以部署之前。

  • 發展
  • QA
  • UAT
  • 生產

我們構建腳本（竹構建服務器內）對QA和反對UAT運行。我們的DBA是唯一可以針對QA，UAT和PROD運行創建腳本的人員。從QA - > UAT發生的任何事情都像測試運行部署一樣。通過再次複製生產系統，可以恢復UAT。

當我們發佈到生產環境中時，我們只需創建一個全新的網站並將其指向UAT數據庫並測試環境是否正常。然後，當這個工作正常時，我們按下'switch'並將生產IIS記錄指向下一個站點，並將數據庫連接更改爲指向Prod DB。

由於我們使用的是完全不同的文件夾結構，因此我們所有的文件都會被複制，因此不會丟失任何文件。因爲我們已經進行了部署到UAT中的測試運行，所以我們知道我們沒有錯過一個數據庫腳本（DB腳本通常被合併爲一個）。因爲我們已經測試了IIS網站的影子副本，所以我們知道它對環境應該起作用。然後，我們可以在白天完成所有這些設置 - 然後在午夜或任何時候做最後一次切換 - 減少對開發者的影響。

tl; dr;自動構建和部署;用於測試運行部署的UAT系統;工作時間部署;輕彈切換/在午夜運行數據庫更新。

來源

2011-10-04 13:22:28

0

有一個用戶驗收測試（UAT）環境，這是完全從你的開發環境中分離，只有進入到UAT經理。

設置UAT構建，您可以在每次發佈時手動觸發，當觸發時，應將所有部署文件以及部署清單發送給UAT管理器，UAT管理器將重新部署所有文件到UAT環境，並運行任何數據庫升級腳本。

一旦應用程序用戶和測試人員簽署了UAT版本，UAT管理員就可以被授權使用與UAT版本完全相同的過程和核對清單部署到PRODUCTION環境。這將保證您不會錯過任何部署步驟，並在將其部署過程轉入生產之前對其進行測試。

來源

2011-10-04 13:45:52

+0

您認爲我們**擁有** UAT經理或UAT ......或QA。開發人員是我們自己的質量保證。 –

+0

術語UAT Manager是爲了清楚起見，只要他們遵循正確的程序，您可以讓開發人員承擔這個角色。我鼓勵你考慮UAT環境，使你的部署更加流暢和靈活。 –

0

Caveats-我的環境下，我們不能使用MSI，批次等，爲最終部署

件事幫助：

，做一個全力打造編譯構建服務器服務器並運行所有單元測試和集成測試。爲什麼發現你在aspx頁面中有東西不能在部署之夜進行編譯？（我承認，如果在部署之夜進行編譯，你的Q沒有說清楚）

我有一個管理員可以訪問該練習環境和部署失敗點的頁面，例如，連接到數據庫，連接到報告服務，發送電子郵件，讀取和寫入臨時文件夾。

此外，將管理員需要更改的所有內容從web.config中更改爲外部文件。連接字符串和應用程序設置部分本身支持一種方法來做到這一點（即不要重新創建web.config系統只是爲了創建一個單獨的文件）

這裏是一篇關於如何做更好的集成測試的文章：http://suburbandestiny.com/Tech/?p=601 There是如何進行單元測試的大量優秀文獻，但是如果您的應用程序已經存在，您將不得不重構，直到單元測試成爲可能。如果這不是一種選擇，那麼不要成爲一個純粹主義者，並且儘可能快速和可重複地進行一些集成測試。

將您的依賴關係保存在bin而不是GAC中，因爲更容易告訴管理員複製文件，而不是教他們管理GAC。

來源

2011-10-04 14:21:35 MatthewMartin

3

我是BuildMaster的一名開發人員，這個工具可以非常容易地自動執行上面概述的步驟，並且我們有一個由5個開發人員組成的團隊免費的有限版本。

當您設置部署自動化時 - 主要是批處理腳本執行和逐個文件複製，您的大部分難題都將消失。一旦完全自動化，您甚至可以安排夜間部署，只需要擔心流程中是否存在錯誤（您可以爲失敗的構建設置通告程序）。

在數據庫方面，您也可以將數據庫與BuildMaster集成，並且如果您將腳本上載到工具中，它將跟蹤哪些數據庫在哪個數據庫上運行。

要了解如何設置簡單的Web應用程序部署計劃，您可以運行包含的示例應用程序之一。您也可以查看：http://inedo.com/support/tutorials/lunchmaster/part-1，看看如何自己創建一個 - 它的稍微有點已過時，因爲我們已經使得開箱即用更容易，但主要概念是相同的。

來源

2011-10-13 19:26:20

相關問題

 相關問題