Automatyzacja projektu z MSBuild-em - 1. Struktura

Jul 13, 2008 - 3 minute read -

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: stem 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 >>>