Jakie pliki projektu ASP.NET MVC powinny znajdować się w repozytorium?

Question

background: Ja i moi współpracownicy pracujemy nad projektem asp.net mvc ... mamy komputer, który działa jak serwer, na którym projekt będzie przechowywany ... każdy z nas ma kopię projektu i mamy ustawione cvs tortoise.

pytania: kiedy chcesz coś zatwierdzić, jakie pliki dokładnie zatwierdzasz? .. asp.net zgłasza wiele plików dll, plików csproj, cs i sln, które wyglądają inaczej niż na serwerze.

Może moje pytanie nie jest właściwym pytaniem, więc powinienem docenić najlepsze podejście do pracy w grupach.

Answer 1

Podstawowym plik csproj powinna być zaangażowana w dowolnym momencie dodać lub usunąć rzeczy z projektu, w celu zapewnienia, że ​​projekt ma wszystkie poprawne pliki. Rozwiązanie (sln) jest dobre do popełnienia, z tego samego powodu, chociaż widziałem to bez niego. W naturalny sposób chciałbyś też zatwierdzić pliki cs, ponieważ są one głównym tematem.

Pliki DLL powinny być zatwierdzone tylko wtedy, gdy znajdują się poza referencjami - wewnętrzne biblioteki DLL do projektu można zignorować, ponieważ będą one tworzone przez każdy komputer po kolei. Również chcesz uniknąć plików .user jako niepotrzebnych. Zignoruj ​​foldery "bin" i "obj" dla każdego katalogu, jeśli chodzi również o zatwierdzanie.

Answer 2

Naprawdę nie powinieneś sprawdzać niczego, co projekt może sam wygenerować. Więc nie ma potrzeby sprawdzania folderów bin lub obj, ani niczego w tym stylu, a także ignorowanie plików preferencji użytkownika.

Obejmuje biblioteki dll, , chyba że są plikami DLL innych firm, następnie należy je sprawdzić, aby upewnić się, że wszyscy pracują przeciwko tej samej wersji i w ten sposób nie trzeba zmieniać ścieżek referencyjnych.

Answer 3

Przechowujemy wszystko oprócz folderów BIN/OBJ w SVN. Wszystkie biblioteki stron trzecich znajdują się w oddzielnym folderze, do którego są przywoływane.

Dobroć,

Dan

Answer 4

Nie pracuję w asp.net, więc odpowiem w sposób ogólny. Mamy repozytorium kodu subversion dla naszego systemu wersji, cvs również działa. Programiści pobierają cały zaktualizowany kod z repozytorium, wykonują pracę, upewniają się, że działa on poprawnie, wykonują, pobierają, ponownie kompilują, testują, a następnie zatwierdzają zmiany kodu źródłowego w repozytorium. Regularnie możesz mieć narzędzie lub ręcznie zbudować aplikację z repozytorium i wdrożyć na serwerze testowym. Żadnego skompilowanego kodu nie należy umieszczać w repozytorium.

-Jay

Answer 5

Używamy następującą strukturę projektu w SVN (ale dotyczy to także CVS).

+ tags 
+ branches 
> trunk 
    + build (build scripts) 
    + lib (external libraries) 
    > src (source code)  
    >> Organization.App (solution name) 
    >> Organization.App.Core (code library) 
     + Config 
     > Domain 
      > Model 
      > Persistence 
      > Queries 
      > Services 
     > Persistence 
     > Services 
    >> Organization.App.Web (mvc web app) 
     > Assets 
      + Images 
      + Scripts 
      + Stylesheets 
     + Controllers 
     + Views 
     + ViewModels 

Wszystkie zależności od innych firm umieszczamy w folderze lib. W tym MVC, który może być wdrożony w bin. See this article by Phil Haack. Kiedy więc nowy programista wchodzi do sieci, musi to sprawdzić w bagażniku i powinien mieć wszystko, czego potrzeba, aby zacząć działać. Używanie serwera CI jest cinch, ponieważ wszystkie zależności projektów są enkapsulowane przez folder lib, a wszystkie projekty Visual Studio odwołują się do tych bibliotek dll w tym folderze lib.

Czy to ma sens?

Nie zwracaj uwagi na folder główny i folder internetowy. Właśnie w ten sposób tworzymy projekty w ramach rozwiązania. Ale to jest whole other conversation. :)

Answer 6

Jeśli używasz narzędzia do zarządzania zmianami w bazie danych, takiego jak Tarantino, będziesz również chciał sprawdzić skrypty zmiany SQL i/lub zapełnić skrypty. Mamy folder w naszym rozwiązaniu "Core", w którym je przechowujemy, tj. "Core/Database/Updates". Używamy SQL Compare do znajdowania zmian w naszej bazie danych, następnie sprawdzamy te skrypty zmiany SQL, aby inni programiści mogli je uruchomić lokalnie. Mamy nant konfigurację zadania, aby wywołać Tarantino, aby zsynchronizować inne środowiska kompilacji (Dev, QA) i uruchomić dowolne nowe skrypty zmian.