Vlákno názorů k článku Monitoring RDBMS PostgreSQL od MP - Tak nejak. Zakladni monitoring si udela kazdy admin...
-
MP (neregistrovaný)
Tak nejak. Zakladni monitoring si udela kazdy admin sam. Ale pokud vyvojari nevyuzivaji nastroje, ktere jsou jiz nasazene, nebo nepouzivaji rozlisovaci parametry, tak s tim admin proste nic neudela. Ale nejhorsi je, ze pokud vyvojari vyvijeji primo na produkci, protoze to jinak neumeji nebo firma to tak chce, tak proste pulka tech analyz je k nicemu, pokud nelze rozlisit vliv dev/prod.
-
MP (neregistrovaný)
Tak instalace je ten nejmensi problem. Jenze ono to je komplexnejsi, vzhledem k tomu, ze se jedna o web aplikace a bezime vice psql serveru ruznych verzi.
1] neni vyresen prenos struktur/dat/(pripadna sanitizace) mezi prod-dev
2] neni vyreseno testovani webu z dev stanicTreba ten web, pokud dev webu bezi jen na produkci a vyzaduje psql backend a externi zdroje, tak jak ho asi tak propojit na nekolik dev psql. Ze by vyvojari prepinali ve skriptech pro vsechny najednou psql backend? To asi ne ze...
Jako jo, pokud dev bude delat jen backend, tak je to jednodussi, ale protoze je potreba to propojit i s temi, co delaji frontend, tak je to cele o naplanovani, realizovani. A to jeste k tomu preskolit vyvojare a nabourat vyvojovy proces cele firmy. Na jedne strane vyhoda, ze se to cele da postavit na zelene louce, na druhe strane nevyhoda, ze je nutne vymyslet cely ekosystem, aniz se vi, kde jsou zadrhele jednotlivych casti ekosystemu vyvoje...(ale to uz je jen povzdech...prace az nad hlavu)... -
MP (neregistrovaný)
Vagrant jsem trochu otukaval, ale priznam se, ze se mi nejak nepodarilo zprovoznit ani zakladni vec - prenos dat mezi PC a Vagrantem. Ale i u Vagrantu zustava stejna premisa - je nutne ten Vagrant nejak automatizovane nakonfigurovat a hlavne zajistit nejak obsah DB/web slozek. A na tom zatim stoji a pada veskere ma snaha o zmenu vyvojoveho procesu.
Treba by me zajimalo - jakym zpusobem je resen prenos struktury DB mezi dev-prod? Resp., pokud ma mit kazdy dev svoji verzi DB na PC, tak jak se pak merguji zmeny, pokud dela vice lidi na stejne casti DB?
-
V GD měl každý vývojář vlastní virtuální instanci (případně jich měl víc), která byla v podstatě trochu redukovanou kopií produkčních serverů (na virtuálu bylo možné pustit vybranou odpovídající část regresních testů) - jeho úkolem bylo doručit alter scripty, které se aplikovaly na preprod a na produkci. Teoreticky by si tyto skripty mohl každý aplikovat u sebe, ale to se většinou nedělo - pokud se mu virtuál rozjel vůči masteru, tak se virtuál zahodil a nechal si buildnout nový. Samozřejmě, že build, instalace a konfigurace sw byla automatická - pomocí puppetu, který jel vůči jeho větvi v gitu.
-
Ivan (neregistrovaný)
Treba by me zajimalo - jakym zpusobem je resen prenos struktury DB mezi dev-prod? Resp., pokud ma mit kazdy dev svoji verzi DB na PC, tak jak se pak merguji zmeny, pokud dela vice lidi na stejne casti DB?
Ve starych, ne-frikulinskych korporacich to byva tak, ze dev databaze je sdilenena (anebo je jich vice a jsou sdilene). Zmeny struktury provadi pouze architekt po dohode a ostatnimi. Vetsinou chcete aby za navrh schematu byl zodpovedny nekdo, kdo ma presah i do jinych technologii.
Pak jsou i na nastroje jako DBUnit, Liquibase anebo Flyway. Casto ale nakonec skoncite u klasickeho SQL, zvlast kdyz vyvijete na databazi ktera je zhruba stejne velika jako produkcni.
ČLÁNKY DO MAILU