Budowanie projektu ASP.NET z FAKE

21

Wspominałem już kiedyś o FAKE – F# Make. Jest to narzędzie do wykonywania buildów, tak jak MSBuild, nAnt, Rake, psake czy wiele innych. Przez krótki czas (przy jednym projekcie) miałem okazję się nim pobawić, i bardzo przypadło mi do gustu. Dzisiaj pokażę jak można z niego skorzystać.

Na początek jednak kilka linków:

Wychodzę z założenia, że wszystko co związane z systemem powinno wraz z nim wędrować do repozytorium. Trochę zależy to pewnie od projektu i przyjętych praktyk, ale na swoim build serwerze nie chciałbym mieć niczego poza standardowymi bibliotekami: czyli najlepiej jeśli wystarczy Windows z .NET. Dlatego też struktura mojego projektu wygląda tak:

fake-proj-structure

  • /Build – skrypty z logiką poszczególnych kroków procesu budowania aplikacji; w tym przypadku są to skrypty w F# interpretowane przez FAKE
  • /src/LogicLib, /src/Web – dwa projekty wchodzące w skład przykładowego systemu
  • /src/Tests/* – projekty testów jednostkowych
  • /tools – katalog z wszelkimi narzędziami używanymi w projekcie, w tym przypadku: FAKE
  • dodatkowo root posiada plik Build.bat wywoływany przez build serwer w celu przeprowadzenia… buildu:) (nawet Bob Budowniczy nie użył tyle razy słowa "build" w jednym zdaniu)

Tyczy się to maszyny deweloperskiej, gdzie mam zainstalowane Visual Studio z F#. Na serwerze CI (Team City) nie mam VS, więc do katalogu /tools dojdzie jeszcze paczka z kompilatorem, interpreterem i bibliotekami F#.

Podczas procesu budowania aplikacji serwer powinien wgrać do jednego katalogu (u mnie będzie to /Output) strukturę, którą można bezpośrednio wrzucić na serwer (np. przez FTP) w celu wdrożenia aktualnej wersji. (Oczywiście to może być jeden z kroków wykonywanych na tymże serwerze.)  Będą to zatem dllki powstałe w wyniku kopiowania projektów LogicLib i Web oraz pliki aspx/ascx/js/css/png/config…  z projektu Web.

Zerknijmy na zawartość katalogu /Build (bo to ona jest w całym tym poście najciekawsza):

fake-proj-build-structure

Punktem wejścia do procesu buildu jest skrypt build.fsx. Słowo "skrypt" jest tu niezwykle ważne – FAKE wykorzystuje interpreter F# do wykonywania instrukcji (polecam sekcję F# Interactive (fsi.exe) Reference na MSDN).

Właściwie odpowiedzialność pliku Build.bat ogranicza się do uruchomienia FAKE z instrukcjami zawartymi w build.fsx:

"tools\FAKE-1.42.23.0\Fake.exe" "Build\build.fsx"

Cóż więc takiego kryje się w naszym "głównym skrypcie"? Czy będzie tak szaleńczo przytłaczający jak milion-liniowe punkty wejścia w procesy MSBuild, od których może zakręcić się w hałowie? Spójrzmy:

  1:  #I @"..\tools\FAKE-1.42.23.0"
  2:  #r "FakeLib.dll"
  3:  open Fake
  4:  
  5:  let outputDir = @".\Output"
  6:  let deployDir = outputDir @@ "wwwroot"
  7:  let srcDir = @".\src"
  8:  let webAppName = "Web"
  9:  let webAppDir = srcDir @@ webAppName
 10:  let webAppProjFile = webAppDir @@ webAppName+".csproj"
 11:  
 12:  #load @".\clean.fsx"
 13:  #load @".\compile.fsx"
 14:  #load @".\pre-deploy.fsx"
 15:  
 16:  For? Compile <- Dependency? Clean
 17:  For? PreDeploy <- Dependency? Compile
 18:  
 19:  Run? PreDeploy

Proste. Spójne. Zwięzłe. Po prostu piękne. Ani jeden znak nie jest zmarnowany, nic nie odwraca naszej uwagi od tego co jest faktycznie potrzebne. Po krótkim wyjaśnieniu wszystko będzie zrozumiałe nawet dla osoby niemającej wcześniej styczności z F#.

Linia 1: dyrektywą #I wskazujemy interpreterowi F# katalog w którym ma szukać potrzebnych dllek

Linia 2: dyrektywą #r dodajemy referencję do FAKE

Linia 3: importujemy przestrzeń nazw Fake

Linie 5-10: definiujemy zmienne gotowe do wykorzystania w dalszych krokach skryptu (tej części MSBuilda nigdy nie potrafiłem zajarzyć… PropertyGroups, ItemProperties, InnaDziwnaNazwa i tym podobne diabelskie pomioty… a przecież chodzi nam jedynie o przypisanie jakichś wartości do identyfikatorów celem ich późniejszego użycia, prawda?) W tym punkcie zwrócę uwagę na operator @@ – jest on zdefiniowany w samym FAKE i znaczy tyle co Path.Combine, czyż nie słodkie?

Linie 12-14: dyrektywą #load nakazujemy skompilować wymienione skrypty, aby były gotowe do wykorzystania

Linie 16-17: definiujemy zależności pomiędzy poszczególnymi krokami kompilacji (zdefiniowanymi w pozostałych skryptach); kroki te są już znane, ponieważ je skompilowaliśmy w liniach 12-14; zapis te znaczy ni mniej ni więcej tylko tyle, że przed krokiem Compile nakazujemy wykonanie kroku Clean, a przed PreDeploy – chcemy wywołać Compile

Linia 19: wywołujemy krok PreDeploy, który dzięki sprytnemu łańcuszkowi zależności z linii 16-17 spowoduje wykonanie całego procesu w kolejności: Clean -> Compile -> PreDeploy

 

Eto wsio.

Mam nadzieję że Was choć trochę tym zaciekawiłem. Następnym razem obadamy instrukcje zawarte w poszczególnych krokach procesu.

Share.

About Author

Programista, trener, prelegent, pasjonat, blogger. Autor podcasta programistycznego: DevTalk.pl. Jeden z liderów Białostockiej Grupy .NET i współorganizator konferencji Programistok. Od 2008 Microsoft MVP w kategorii .NET. Więcej informacji znajdziesz na stronie O autorze. Napisz do mnie ze strony Kontakt. Dodatkowo: Twitter, Facebook, YouTube.

21 Comments

  1. @Artur:
    Poznasz podstawy F#, poznasz nowe narzędzie, uprościsz skrypty buildu. I najważniejsze: uwolnisz się od MSBuild i xml-hell.

  2. Kupa czasu minęła, ale przypomniałem sobie o tym poście. Powolutku myślę, żeby zacząć sobie coś skrobać na boku, głównie celem funu i nowych technologii. Miałem minimalną styczność z MSBuildem (głównie pomodyfikowałem rzeczy, które ktoś mi napisał, a troszkę dopisałem) i szlag mnie trafiał, masakra z tymi XMLami. Te dwa miesiące temu zlałem tego posta, teraz jestem żywo zainteresowany zawartością plików wewnętrznych, także czekam, czekam :)

  3. @pako:
    Niestety sam nie dobrnąłem do końca tego procesu. Co prawda na mojej dev-maszynie wszystko działa, ale już na build serverze bez VS rzucało mi wyjątkami związanymi z fake/f#. Nie doszedłem o co chodzi, autor biblioteki nie był zbyt pomocny -> i póki co przestałem marnować na to czas. Jak na razie starcza mi możliwość lokalnego przygotowania paczki do wdrożenia, ale nie chciałbym publikować czegoś z czego sam nie korzystam w "prawdziwym" scenariuszu.
    Sam osobiście następnym razem zabiorę się za Rake, i na tym etapie chyba także bym to Tobie polecił. FAKE jest jednak… zbyt mało popularny i w razie jakichkolwiek problemów jest się skazanym właściwie tylko na jej autora, a to raptem jedna osoba.