> Ésszel kell csinálni mindent.
Ezt szoktam en is mondani. Gondolkozzon el az ember, hogy adott szituacioban melyik altala ismert (vagy nem ismert, ld. research) technika/technologia a legmegfelelobb valasztas. Ha a trunk based, akkor az. Ha a feature branches, akkor az. Ha valamilyen teljesen agyament a logikus, akkor az. De biztos, hogy nem "ahol csak lehet". Ahol logikus, igen.
Az a problema az egesszel, hogy kodbol akarnak megoldani annal melyebben fekvo problemakat. Ezeknek a gyokere a nem megfelelo teszteles, a nem megfelelo infrastruktura, illetve a nem megfelelo kod-, es munkaszervezes. Esetleg a bandwagonra pattanas is szerepet jatszhat, "a tobbiek is ezt csinaljak, ez csak jo lehet" effektus.
Ha a kod rendesen van strukturalva, akkor merge conflict nem szabad hogy felmeruljon, mert ket kulonbozo valtoztatas nem erinti ugyanazt a teruletet (ld. SRP vs. spagetti kod).
Ha a csapat rendesen van struktulralva, akkor ha megis ugyanazon a teruleten dolgoznak, akkor ezt elotte megbeszelik, es fejlesztes kozben folyamatosan egyeztetnek (ld. agile, standup, "Individuals and interactions over processes and tools").
Ha az infrastruktura nem tamogatja a folyamatos release-t, a releasenkenti feature-szamot megfeleloen alacsonyan tartva, akkor nincs mas lehetoseg, mint a feature flageles. Ha az infrastruktura tamogatja a gyakori release/rollbacket, akkor semmi ertelme a kodot teleszemetelni, mert elegendo monitorozasi idoablak utan vagy mehet a kovetkezo release, vagy rollback kell. Ez webapplikacio eseten a gyakori release megoldhato, egy mobil app eseten mondjuk kevesbe.
Ha nincs megfelelo automata teszt es regression lefedettseg, akkor megette a fene az egeszet. Ha ezeket manualisan kell elvegezni, akkor nem marad ido a feature rendes manualis/exploratory tesztelesere, gyakorlatilag a happy path lesz lefedve, meg talan egy-ket error eset. Ennek hatasara bugos kod jelenik meg eles kornyezetben, mely vagy tamogatja annak rollbackeleset, vagy nem. Megfelelo tesztelessel a hibak aranya ezaltal a rollbackek szama minimalizalhato.
Kicsit kezd elegem lenni abbol, hogy mindent (is!) a fejleszto oldjon meg. Nyilvan ertsen az uzemelteteshez, legalabb egy picit, mert az uzemeltetok basznak megtanulni, hogy kell a szoftvert rendesen uzemeltetni (flamebait!). Mert nincs ido automata tesztekre/olyan szar a kod, hogy lehetetlenseg ertelmesen tesztelni, tehat a fejleszto azert manual teszterkedjen is, mert nincs kapacitas. Hogy az infrastruktura es a processzek akadalyozzak a folyamatos release/rollback ciklust, igy a mar igy is elegge komplex kodbazisba meg egy retegnyi komplexitas epitese a megoldas termeszetesen, hogy a fejlesztonek meg azt is folyamatosan fejben kelljen tartania, hogy eppen mi van bekapcsolva/masik team miket kapcsolgat (ld. fentebb kommunikacio)/a live issue keresest feleslegesen komplexsze teszi. Nagyon cool, olyan erzes, mint egy Forma 1-es kocsit tav-finomhangolni a garazsbol, de azert na... itt nem errol van szo elsosorban (az a GC futasidobeli tutujgatasa eseten lenne megfelelo analogia).