Rozwój lokalny

Lokalne środowisko developerskie Goat uruchamia cały wymagany zestaw usług i procesów jednym poleceniem.

Główny skrypt:

herd/dev.goat

koordynuje między innymi:

PostgreSQL,
pgAdmin,
backend aplikacji,
generowanie kodu,
budowanie CLI,
ładowanie fixture'ów,
budowanie frontendu Angular,
obserwowanie zmian w źródłach i modelu.

Dzięki temu nie musisz ręcznie uruchamiać każdej części projektu osobno.

Uruchomienie środowiska

Aby rozpocząć pracę, uruchom:

goat run:script --path=herd/dev.goat

Skrypt przygotowuje kompletne środowisko developerskie i pozostaje uruchomiony, obserwując zmiany w projekcie.

Po zakończeniu inicjalizacji możesz od razu pracować z backendem, frontendem i lokalną bazą danych.

Co dzieje się podczas startu

Podczas uruchamiania środowiska dev.goat wykonuje kolejne etapy potrzebne do przygotowania aplikacji.

W uproszczeniu proces wygląda tak:

uruchomienie infrastruktury
        ↓
core:build
        ↓
generowanie kodu
        ↓
budowanie CLI
        ↓
oczekiwanie na PostgreSQL
        ↓
ładowanie fixture'ów
        ↓
uruchomienie aplikacji i watcherów

Najważniejsze kroki obejmują:

zbudowanie rdzenia aplikacji przez core:build,
wygenerowanie kodu na podstawie aktualnego modelu,
zbudowanie CLI wygenerowanej aplikacji,
uruchomienie i sprawdzenie dostępności PostgreSQL,
załadowanie danych z herd/fixture.goat,
uruchomienie backendu,
uruchomienie procesu budowania frontendu,
rozpoczęcie obserwowania zmian w projekcie.

Dzięki temu lokalne środowisko jest przygotowywane w sposób powtarzalny i nie zależy od ręcznie wykonanej sekwencji poleceń.

Lokalne usługi

Po uruchomieniu środowiska dostępne są następujące usługi:

Usługa	Adres
Aplikacja	`http://localhost:8080`
PostgreSQL	`localhost:5433`
pgAdmin	`http://localhost:5050`

Aplikacja jest dostępna pod portem 8080, PostgreSQL pod 5433, a pgAdmin pod 5050.

Automatyczne reagowanie na zmiany

Jedną z głównych zalet herd/dev.goat jest obserwowanie projektu i automatyczne wykonywanie odpowiednich operacji po zmianie źródeł.

Nie musisz za każdym razem ręcznie uruchamiać generatora lub procesu budowania.

Zmiana modelu

Zmiana:

herd/_model.goat

powoduje ponowne uruchomienie procesu generowania.

W uproszczeniu:

zmiana modelu
      ↓
regeneracja kodu
      ↓
aktualizacja aplikacji

Dzięki temu podczas pracy nad strukturą domeny możesz skoncentrować się na modelu, a środowisko developerskie zajmie się przygotowaniem wynikających z niego zmian.

Zmiana backendu

Zmiany w źródłach backendu lub narzędziach rdzenia powodują przebudowanie odpowiednich elementów aplikacji.

Dotyczy to między innymi kodu źródłowego aplikacji oraz:

scripts/

Po wykryciu zmiany środowisko może ponownie wykonać:

core:build

i przygotować aktualną wersję aplikacji.

Nie musisz więc restartować całego środowiska przy każdej zmianie backendu.

Zmiana frontendu

Frontend Angular działa w trybie obserwacji.

Po zmianie kodu frontendowego proces builda automatycznie przygotowuje aktualną wersję aplikacji.

Typowy cykl wygląda więc tak:

zmiana komponentu Angular
        ↓
automatyczny build
        ↓
odświeżenie aplikacji

Pozwala to pracować nad frontendem bez ręcznego uruchamiania pełnego procesu generowania.

Praca z wygenerowanym kodem

Kod wygenerowany przez Goat może być normalnie edytowany podczas developmentu.

Generator ma przyspieszać pracę, a nie wymuszać wykonywanie każdej zmiany przez model.

Możesz więc:

zmienić model i pozwolić Goat wygenerować wynikające z niego elementy,
zmienić szablon, jeśli dana modyfikacja powinna dotyczyć wielu podobnych miejsc,
edytować kod aplikacji bezpośrednio, jeśli zmiana jest specyficzna dla konkretnej funkcjonalności.

Po każdej większej regeneracji warto sprawdzić:

git diff

aby zobaczyć rzeczywisty zakres zmian.

Jednorazowe przygotowanie aplikacji

Nie zawsze potrzebujesz pełnego środowiska developerskiego działającego w tle.

Jeżeli chcesz jedynie przygotować aktualną wersję wygenerowanej aplikacji, możesz uruchomić:

goat core:build
goat re

Pierwsze polecenie przygotowuje aktualny rdzeń aplikacji, a drugie wykonuje generowanie na podstawie modelu i konfiguracji projektu.

Jest to przydatne między innymi:

przed sprawdzeniem zmian w Git,
przed uruchomieniem pojedynczego testu,
podczas debugowania generatora,
gdy nie potrzebujesz PostgreSQL, pgAdmin i watcherów,
w prostych skryptach automatyzacji.

Typowy workflow

W codziennej pracy najczęściej wystarczy uruchomić środowisko raz:

goat run:script --path=herd/dev.goat

a następnie pracować normalnie nad projektem.

Przykład:

uruchom dev.goat
      ↓
zmień _model.goat
      ↓
automatyczna regeneracja
      ↓
zmień wygenerowany kod lub frontend
      ↓
automatyczna przebudowa
      ↓
sprawdź rezultat w aplikacji

Na koniec warto sprawdzić:

git diff
git status

i uruchomić pełny zestaw testów:

goat run:script --path=herd/test.goat

Fixture'y podczas developmentu

Podczas początkowego uruchomienia środowiska ładowany jest:

herd/fixture.goat

Dzięki temu aplikacja może wystartować od razu z przykładowymi danymi i dokumentacją właściwą dla używanej wersji projektu.

Jeżeli zmodyfikujesz fixture'y w trakcie pracy i chcesz załadować je ponownie, możesz zrobić to ręcznie przez CLI aplikacji.

Nie usuwaj cache podczas działania środowiska

Podczas pracy dev.goat może korzystać z katalogów cache i trwałych danych wykorzystywanych przez kontenery oraz procesy developerskie.

Nie usuwaj ich ręcznie podczas działania środowiska.

Może to prowadzić do:

utraty lokalnych danych,
błędów działających procesów,
niespójnego stanu kontenerów,
nieoczekiwanych problemów podczas kolejnych przebudowań.

Jeżeli potrzebujesz wyczyścić środowisko, najpierw zakończ działające procesy, a następnie użyj dedykowanych komend lub skryptów przeznaczonych do czyszczenia konkretnej części projektu.

Najważniejsza zasada

herd/dev.goat powinien być głównym punktem wejścia do lokalnej pracy nad projektem.

Zamiast ręcznie zarządzać osobnymi procesami Dockera, backendu, frontendu, generatora i bazy danych, uruchamiasz jeden workflow, który przygotowuje środowisko i reaguje na zmiany w kodzie.

Dzięki temu lokalny development pozostaje szybki, powtarzalny i możliwie zbliżony pomiędzy różnymi stanowiskami developerskimi.