[Task] poprawić commit stage w piepeline

[msz13]

Uruchomić "commit stage" na pipelinie.

Wymagania:

• [x] faza lint
• [x] faza unit test
• [x] faza test modules
• [x] faza build
• [x] faza build image
• [x] uruchomienie przed mergem brancha do main
• [x] gdy zmieni się kod aplikacji api, akcje powinny objąć wszystkie zminione biblioteki api
• [x] gdy zmieni się kod web, akcje powinny objąć wszystkie zmienione biblioteki web
• [x] efektem powinno być dodanie docker image do repozytorium
• [ ] baza danych jest tworzona z poziomu testów integracyjnych

TODO:

• poprawić czas install node

[msz13]

Warianty:

Pipeline jeden 1.. Workflow.. a. jobs/steps

1. Build a. Install dependencies b. Nx affected: test c. Nx efexted: integration-test d. Nz affected e. Nx affected: build f. Nx affected: build-image g. checkout env repo g. update image tag

Pipeline jeden - dwa etapy acceptance testing

1. Build a. Install dependencies b. Nx affected: test c. Nx efexted: integration-test d. Nz affected e. Nx affected: build f. Nx affected: build-image
2. Deploy to preview environment (k3s)
3. Nx zapisywarka-acceptance test a. Nx zapisywarka-acceptance test - exlude in progress stories b. Nx zapisywarka-acceptance test - in progress stories - jobs..steps[*].continue-on-error
4. Deploy to staging

Pipeline jeden

1. Build a. Install dependencies b. Nx affected: test c. Nx efexted: integration-test d. Nz affected e. Nx affected: build f. Nx affected: build-image
2. Deploy to preview environment (k3s)
3. Nx zapisywarka-acceptance test
4. Deploy to staging

Pipeline dwa rozne joby

1. Set affected projects name
2. Build api – if contains({{$affected-apps}}, “api”) a. Nx affected: test b. Nx efexted: integration-test c. Nz affected d. Nx affected: build e. Nx api build-image f. Deploy to preview environment g. Nx api e2e
3. Build web if affected web a. Nx affected: test b. Nx efexted: integration-test c. Nx: affected: visual0check (ewentualnie w e2e) d. Nx affected: build e. Nx web: build-image f. Deploy to preview environment (k3s) g. Nx web e2e
4. Deploy to staging

Pipeline dwa rozne joby, jeden test

1. Set affected projects name
2. Build api – if contains({{$affected-apps}}, “api”) a. Nx affected: test b. Nx efexted: integration-test c. Nz affected d. Nx affected: build e. Nx api build-image
3. Build web if affected web a. Nx affected: test b. Nx efexted: integration-test c. Nx: affected: visual0check (ewentualnie w e2e) d. Nx affected: build e. Nx web: build-image
4. Acceptance test a. Runs k3s cluster b. Deploy apps c. nx zapisywarka-acceptance-test –-filter Category={{affected}} (trudno zrobić odpowiedni filter)

pozniej rozdzielic poszczegolne futeres na projektu, aby zoptymalizowac buildy

[msz13]

Zasady tagowania

• przy kazdym buildzie tagowane jest odniesieniem do PR albo branch

• jak robi się release dla klientów repo jest tagowane w versioning,

• jak idzie release na produkcyjne, to repo przy ostatnim commicie tagowane jest jako producyjne

• Albo semantic versioning, gdzie:

• major - feature

• minor - every story

• patch - every task(pull request)

• Albo semantic versioning, gdzie:

• major - feature deploed to production

• minor - every feature (small)

• patch - every task(pull request)

• Albo semantic versioning, gdzie

• major - release/milstone (etap realizacji projektu)

• minor - każdy deployment na produkcję

• patch - hot fixes

albo tagować image github actions worlfow

Statusy kontenera przy continous delivery:

• build
• deployed to staging (po przejściu pipelinu, wszystkie)
• deployed to production (tylko niektóre, po akceptacji użytkownika)

Statusy kontenera przy continous deployement:

• build
• deployed to staging (po przejściu pipelinu, wszystkie)
• deployed to production (po przejściu pipelinu, wszystkie, funkcjonalności zarządzane są feature flags)

Statusy repo:

• build task
• showcase to users
• released to production

Versioning artefaktów: oddzielnie dla aplikacji, albo razem, np. 1.. Odzielnie: web0.1, api0.1, api.0.2, web0.1

2. Razem web0.1, api0.2, api.03, web0.4

[msz13]

Stępa:

• test
• build - build + docker build
• publish - vwrsion + docker push

[msz13]

Release strategy:

1. Częstotliwość na produkcję: w normalnych warunkach: codziennie lub co spring
2. Teraz: nie ma produkcji
3. Strategia continous delivery??
4. Promocja środowisk: preview, staging

Stany:

1. Feature: planed, developed, tested, PO Accepted, deploed (np. beta users, second users, all)
2. Artifact (container image) - build, tested, deployed to staging, deployed to production
3. Code - ??

Konwencja nazw commitow/pr: rodzaj, zakres web/api-nazwa lib, comment, pr ref i yser story reg feat(web-rejestracja): add ui component (#1234) (story-#1123)

[msz13]

Release to production:

• tag repo
• retag images with same version
• generate release note

[msz13]

rodzaje tagow:

• sha - prosty i krótki, ale trudno odnalezc odpowiednia wersje repo
• semver

wymagania - aby łatwo po wersji imaga było znależć odpowiednią wersję kodu

[msz13]

do zrobienia:

• nie działa cypress
• nie działa dotnet format
• nie działają test integracyjne dotnet bo brak jest bazy danych