如何將一個單一的解決方案網站拆分成多個解決方案(而不是多個項目),使獨立開發人員可以在各個解決方案的工作,同時還具有「知名度」到其他那些?例如,我希望能夠直接從Visual Studio運行和測試業務模塊(F5),但登錄模塊位於單獨的解決方案中。有沒有辦法像這樣劃分網站開發?在asp.net拆分單一的解決方案爲多個解決方案
如果沒有,怎麼能多開發者是在同一個解決方案不同項目中工作? (我們是一家小商店,還沒有嘗試Team Foundation Services)。
如何將一個單一的解決方案網站拆分成多個解決方案(而不是多個項目),使獨立開發人員可以在各個解決方案的工作,同時還具有「知名度」到其他那些?例如,我希望能夠直接從Visual Studio運行和測試業務模塊(F5),但登錄模塊位於單獨的解決方案中。有沒有辦法像這樣劃分網站開發?在asp.net拆分單一的解決方案爲多個解決方案
如果沒有,怎麼能多開發者是在同一個解決方案不同項目中工作? (我們是一家小商店,還沒有嘗試Team Foundation Services)。
...來源控制。
我讀了你的問題,來考慮的第一件事是「他們試圖在託管網絡共享源代碼的同一副本的工作」。壞,壞,壞。即使它是一個網站,因此可以在正常運行狀態下從一個地方訪問,但這不是開發它的正確方法
抓住Subversion或Mercurial的副本,檢查代碼庫並確保每個人定期做出改變。 Subversion Server本身免費提供CollabNet;一些用於提供GUI和IDE集成的工具不是(但有些是好的;檢查出TortoiseSVN用於一般基於Windows資源管理器的存儲庫操作,而AnkhSVN是Visual Studio的免費插件,允許在IDE內提交/更新) 。
一旦你設置了這個源碼控制系統,每個人都會將代碼庫的工作副本「檢出」到他們的本地機器上,並且可以對其進行所有更改,然後「檢入」這些更改他們有一個穩定的工作版本,其他人可以通過更新他們自己的工作副本來獲得。顯然,這需要開發人員的機器有足夠的力量來在自己的機器上運行網站的基本副本(大多數最近4年左右的PC應該沒有問題,運行IIS,SQL Server Express和ASP實例.NET網站只有開發者瀏覽它)。要查看最新的工作副本的外觀和行爲,您可以定期將其發佈到模擬您的生產服務器的臨時環境(相同的服務分佈,例如不同機器之間的IIS/SQL Server,除非需要進行負載測試,否則可能功耗更低) 。
SVN通過「合併」的變化將在同一文件的多個提交,並有通常只有一個問題,如果兩個開發者修改了相同的代碼行以不同的方式。如果某人對代碼庫進行了大規模的徹底改變,可能會干擾其他用戶,但仍然想「提交」他的工作副本(通常是一件好事,爲了備份目的,如果沒有其他),他可以根據當前的源代碼,從中更新並提交,然後當他完成時,將他的更改合併到「中繼」中。
基本上,每個在項目上工作的開發人員都應該在同一組源代碼中工作,理想的情況是開發人員可以從版本控制中從頭開始下載,在VS中打開,打開「構建」按鈕並去。你的團隊應該彼此溝通,瞭解他們正在從事哪些項目和源文件,並且應該定期(如每隔一兩個小時)進行變更並讓其他人蔘與。
你可以去整個生豬和實施了「持續集成」服務器。在每一次簽到時,這個系統都會提取最新的源代碼並運行一些自動化任務,比如運行各種測試/指標,推送到分級等。如果你安裝在三個或更少的「構建代理」上,TeamCity是免費的「構建代理」可以運行不同的測試套件,或基於不同的提交工作)。當你密切注意測試驅動的開發實踐時,這通常具有最大的價值;那麼CI服務器將運行單元和集成測試,以確保代碼完成開發人員認爲應該做的所有事情,並加上代碼覆蓋範圍,以確保遵循規則並且代碼已被測試充分行使。
工作在不同的解決方案,揭示不同的,但重疊的項目是不是一個偉大的想法;作爲一種減少託管虛擬機環境中的資源需求的策略(加載大量項目,特別是使用像ReSharper這樣的代碼分析工具,可能真正對舊系統或仿真器/ VPC設置徵稅),我只曾將這種方法看作是一種策略。
我從任何地方都能看到這個想法。我們有另一個(非網絡)asp.net應用程序,我們已經使用多種解決方案開發了多年,這些解決方案運行良好,但Web開發是另一種野獸。非常感謝您的建議。 – user1864728
即使您正在進行WinForms或Windows Service開發,也不應讓人們嘗試將更改保存到一組平面文件。如果有人正在與另一個人在同一個文件上工作會發生什麼?無論誰保存上次都會覆蓋自上次獲得該文件副本以來的任何其他人的更改(並且在IDE告訴他該文件發生更改時未命中「忽略」)。版本控制系統是任何開發團隊最基本的要求。 – KeithS
它是完全獨立的解決方案,只有我們兩個人,所以我們協調得很好,而且決不會同時處於相同的解決方案中。但是你的觀點已經完全被採納,源代碼控制是我們將要走向的方向。再次感謝。 – user1864728