日常開發維護項目中，可能會遇到發佈後出現bug，或者忘記改配置文件等等問題，這個時候，可能就需要重新進行下發佈，有的開發小伙伴可能會把編譯後的代碼文件整個替換。這樣做雖然也可以實現發佈，但是有幾個弊端，一個是速度慢，二個是會造成不穩定，假如不關閉站點的話，前端發出請求到後端後，將會出現異常信息。 換 ...
日常開發維護項目中，可能會遇到發佈後出現bug，或者忘記改配置文件等等問題，這個時候，可能就需要重新進行下發佈，有的開發小伙伴可能會把編譯後的代碼文件整個替換。這樣做雖然也可以實現發佈，但是有幾個弊端，一個是速度慢，二個是會造成不穩定，假如不關閉站點的話，前端發出請求到後端後，將會出現異常信息。
換過來想，如果我們發佈的代碼文件少，是不是就會影響小一點呢。所以我們如果只發佈有變更代碼的類庫編譯的dll文件，是不是就能把影響降到最低呢？
那麼問題就來了，我們怎麼才能確定修複bug的時候，改了哪些文件，涉及到哪些項目類庫呢？
通過版本管理工具就可以很好地查看這些問題，前提是要養好勤提交代碼，勤拉取代碼的好習慣，這樣才能確保代碼是最新的，不會漏代碼。
像svn、git這些主流的版本管理工具，都有查看日誌，查看影響文件的列表功能。以下我拿svn的做例子
通過上圖我們可以發現，此類改動的內容影響到的類庫有 ClearSite.Common、ClearSite.Model、ClearSite.WebApi 這三個類庫
那麼發佈的時候，我們只需要把編譯後的這三個類庫對應的dll文件（ClearSite.Common.dll、ClearSite.Model.dll、ClearSite.WebApi.dll）去替換生產環境bin目錄下對應的dll即可
