De a Makefile-t nem kell arra hasznalni, amire eredetileg valo (C/C++ dependency szerinti buildeles), csak egy eszkoz, amivel osszefogjuk a kis scriptelt lepeseket. De ott van a videoban emlitett `just` is, az is jo lehet. De lehet a repo gyokereben `./test.sh`, `./lint.sh`, ... is.
Antipattern és nem is hatékony egy csomó esetben. Kicsit olyan, mint ahogy a Fortran programozók minden nyelvek tudnak Fortran programot írni...
Ez tul lassu szerintem. Csak egy EKS cluster letrehozasa majd 10 perc. Ha felteszunk ra minden observability eszkozt (logging, monitoring, tracing, profiling), akkor kozelitjuk a fel orat. Azert az tulzas, hogy egy egy soros change miatt fel orat varni kelljen a CI-ra.
Ez úgy működik jó esetben, hogy a branch létrehozásakor létrejön a környezet. Lehet, hogy 10 perc, de létrehozott feature branch-en ritkán dolgozol 10 percnél rövidebb ideig, a quickfix branch meg más témakör. És egy-egy sor change kurva gyorsan végig tud menni megfelelő architektúra és pipeline esetén.
Akkor mar inkabb jobb az a modszer, hogy minden PR-hoz keszul egy uj K8s namespace, akkor a tobbi parhuzamos PR-ral nem akad ossze (legalabbis helm szinten). Namespace-t gyorsan lehet letrehozni es torolni.
A PR az kb. branch szintű dolog ideális esetben (sok esetben ez teljesen automatikus issue-branch-PR/MR triót jelent). Pont erről van szó.
Nehezebb ugy, ha egy PR adatbazis schemat modosit, mert nyilvan nem szeretnenk adatbazist clone-ozni minden PR szamara.
Miért nem? A fejlesztő mit csinál a saját gépén egyéb esetben, milyen DB-t használ?