rod.pl

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