Witaj na Zine.net online Zaloguj się | Rejestracja | Pomoc

Automatyzacja projektu z MSBuild-em - 1. Struktura

Tym postem chciałbym zapoczątkować krótki, a może dłuższy cykl na temat organizacji struktury projektu oraz automatyzacji jego: budowy, testowania, instalacji etc etc. Przedstawię w nim sposoby, które do tej pory wykorzystywałem do próby stworzenia jak najlepszej organizacji struktury projektu. A czym powinna się charakteryzować najlepsza organizacja i automatyzacja projektu ? Osobiście staram się dążyć aby:

  • Struktura katalogów i gałęzi w repozytorium kodu powinna być czytelna bez potrzeby zapoznania się dodatkową dokumentacją.
  • Powtarzające się czynności, takie jak budowa, testowanie itd. powinny być zautomatyzowane.
  • Czynności powinny być możliwe do wykonania dla całej aplikacji lub pojedynczo dla poszczególnych projektów.
  • Rozwiązanie powinno być jak najbardziej samowystarczalne podczas wykonywania powtarzających się czynności. Przykłady:
    • Użytkownik lub proces Continuous Integration, który nie posiada np. Visual Studio mógł bez problemu zbudować i przetestować aplikację.
    • Inna wersja biblioteki zainstalowanej w systemie nie powinna być wykorzystywana. Np. projekt korzysta np z NUnit 2.2 i obecność wersji 2.4 w systemie nie powinna mieć wpływu na sposób wykonania testów.
  • Wspólne parametry, takie jak numer wersji, powinny być scentralizowane.
  • ... ( jakieś inne propozycje ?) ...

Repository tree

Zacznijmy od nazewnictwa struktury gałęzi w repozytorium kodu. Tutaj wybór może być uzależniony od wybranego oprogramowania do zarządzania wersjami.

Przyjęło się np. że SVN w drzewie posiada następującą strukturę

  • trunk
  • branches
  • tages

Microsoft natomiast proponuje w How To: Structure Your Source Control Folders in Team Foundation Server następującą strukturę

  • Main - jako trunk
  • Development - jako branches
  • Releases - jako tags

Nie jest to nazewnictwo obligatoryjne. Tak naprawdę te gałęzie możemy nazywać jak chcemy. Tutaj chodzi o pewną standaryzację, wspólny język, aby członkowie zespołu wiedzieli do czego służą katalogi w naszej strukturze. Równie dobrze można używać nazewnictwa SVN-owego w repozytoriach na TFS.

 

Jeżeli zamierzamy korzystać z kodu źródłowego innych producentów i przewidujemy do nich robić niezależne poprawki warto pokusić się jeszcze o tzw. vendor branch. Wiecej na ten temat można dowiedzieć się tutaj Vendor Branching in SVN Book.

A to moja wersja

  • trunk
  • branches
  • tags
  • vendors - dla "vendor branches"
  • nontrunked - wszystko to co związane jest z projektem a nie musi być ani tagowane ani branchowane

Project tree

Fizyczna struktura katalogów w projekcie zależy od kilku czynników m.in. czy wszystkie podprojekty będą korzystały z tych samych bibliotek innych producentów, jaki rodzaj testów bedziemy chcieli implementować, czy nad projektem będzie pracować kilka czy tylko jeden zespół programistów.

Zgodnie z "Visual Studio Team System Guidance" - Structure Your Source Tree to Support Branching można przyjąć następująca strukturę

  • Main
    • Source
      • Code
      • Shared Code
      • Unit Tests
      • Lib
    • Docs
    • Installer
    • Tests

Spora część projektów open source posiada następująca strukturę

  • trunk
    • lib
    • src
    • tools

Podobną strukturę opisuje Jean-Paul S. Boodhoo w  Directory Structure For Projects i ją właśnie stosuję z pewnymi modyfikacjami

  • trunk
    • doc - dokumentacja
    • lib - binaria bibliotek wymaganych do budowy aplikacji
      • net
        • 2.0
        • 3.5
      • mono
        • 2.0
    • src
      • app  - źródła aplikacji
      • tests - żródła testów
    • tools - narzędzia pomocnicze takie jak frameworki do testowania

Część 2 - Wybór narzędzia >>>

Opublikowane 13 lipca 2008 16:55 przez rod
Filed under: ,

Komentarze:

14 lipca 2008 10:46 by arkadiusz.wasniewski

# re: Organizacja projektu i automatyzacja z wykorzystaniem MSBuild-a - 1. Struktura

Dorzucę coś od siebie.

  • trunk
    • data - dane pomocnicze
    • db - skrypty baz danych
    • doc - dokumenty
    • externals - źródła projektów zewnętrznych
    • lib - biblioteki potrzbne do uruchomienia aplikacji np.
      • nlog
        • net
        • netcf
    • src - źródła
    • tools - narzędzia np.
      • nunit
      • rhino
14 lipca 2008 12:23 by rod

# re: Organizacja projektu i automatyzacja z wykorzystaniem MSBuild-a - 1. Struktura

Oj zapomniałem o skryptach do bazy danych. Zazwyczaj robię katalog "sql", ale "db" też jest dobrym rozwiązaniem. Chociaż najlepszym rozwiązaniem na db jest "Rail migrations". Ale o tym będzie troszkę w nastęnpnej części, która ukaże się niebawem.

Niektóre katalogi dodatkowe w projekcie mogą powstawać ze względu na specyfikę samego projektu. Mam projekt integracyjny gdzie klient przysyła mi pliki wejsciowe jako probki danych do przetworzenia. Mam wiec dodatkowy katalog w projekcie

  • inputsFromClient
    • 20080213
    • 20080302

Teraz w testach podaję tylko datę przysłanej próbki danych. Potem w rozmowach z klientem łatwo stwierdzić, że "niestety ale dane od Państwa, które dostaliśmy w lutym są poprawne a te z początku marca są złe".

13 sierpnia 2008 23:37 by rod.pl

# Dynamiczne referencje do bibliotek w Visual Studio

Często, w trakcie korzystania z zewnętrznych bibliotek w naszym  projekcie, pojawia się pewien dylemat.

Komentarze anonimowe wyłączone