2015-08-22 12:00 GMT+01:00 Petru Rațiu <[email protected]>: > Bun, m-am lamurit ca nu ne trollam, doar vorbim unul pe langa altul. > Resetez si mai incerc o data. > > 1. Cu restul de ecosisteme am un trust ceva mai bun (nu absolut), pentru ca > sunt mai multi pasi in toolchain unde pot fi verificate chestii si ai un > control mai bun asupra cand se fac schimbarile. Povestea de care vorbesti > cu ssl-ul din debian e un exemplu bun de ce e nevoie sa faileze: cineva a > introdus bugul din greseala si acelasi pachet l-a avut toata lumea. Cand > s-a observat bugul, toti au putut sa isi dea seama daca si cand au instalat > pachetul cu pricina si ce e de facut in case shit. > > 2. La composer prima chestie care ma deranjeaza e ca nu am nici o legatura > intre ce zice la https://getcomposer.org/download/ si ce zice la > https://github.com/composer/composer . Nu mi-a sarit in ochi vreun script > de build, nu exista pachete in Debian, nici macar amaratul ala de .phar pe > care-l downloadez nu are vreun md5 sau ceva publicat, sa stiu si eu ca am > downloadat ce trebuie inainte sa-l rulez. >
Atunci nu folosi deloc getcomposer.org si foloseste numai versiunea din guithub, si nu orice e acolo ci de aici https://github.com/composer/composer/releases https://github.com/composer/composer/archive/1.0.0-alpha10.tar.gz si gata. Asupra zip/tar.gz nu este nici un control din partea celui care a publicat repository-ul din punctul lui de vedere e doar un anumit commit in git repo, adica nu se poate "trisa" si zip-ul sa fie defapt altundeva. Faci audit la 1.0.0-alpha10 si daca iese tot OK zici "asta e bun, avem incredere in el, asta il folosim". Dupa asta faci audit la toate modulele folosite, asta e, daca vrei siguranta. > 3. Vad ca ai oaresce experienta cu chestia asta, chiar daca ai decis ca mai > intai razi de mine. Cum zici ca faci update la aplicatia live? Niciodata, > doar pui containere noi si pointezi traficul la ele? Desteptii astia ai mei > Da. Cu mentiunea ca "pointezi traficul la ele" o faci si asta automat cu un service discovey tool. > mi-au zis sa rulez composer direct pe mediul de productie si sa mut un > symlink dupa, ca sa-si pastreze diverse cache-uri si alte traznai. Pot rula > treaba aia in alta parte si doar sa le copiez fisierele? Ce-mi scapa? > Asta recomand, faci un build script pentru aplicatie, care ruleaza composer, si rezultatul e un director undeva. Ala il pui intr-un tar.gz, zip, git repo, orice, si deployment propriuzis e defapt unpack la arhiva aia, fara composer. Specific pentru laravel inainte de a rula composer nu o sa ai directorul vendor. Dupa ce rulezi o sa ai vendor in care sunt toate dependintele : https://github.com/laravel/laravel/blob/master/composer.json - (require si require-dev) Implicit composer ruleaza cu --with-dev ( https://getcomposer.org/doc/03-cli.md#install) asa ca pentru prod poate vrei sa faci "curat" ca sa nu instaleze dependintele pentru dev. Dupa care iei exact ce-ti trebuie (cam tot fara composer.phar) si pui intr-un tar.gz si acolo e aplicatia. git clone <repo> cd <repo> php composer.phar install --witout-dev cd .. tar cvzf aplicatie-v<commit>.tar.gz --exclude=composer.* <repo> rm -rf <repo> Ia-o ca pseudocod ;). Poti sa faci asta cu un commit-hook in git si cind faci deployment in test/staging/production o faci doar specificind commit-ul. Rollback ? depinde de mediu (cu containere/haproxy sau symlinks sau altele). Hell poti sa le instalezi pe toate in /var/www/aplicatie-v<commit> si doar sa muti symlinks si atunci deployment/rollback e instant pentru ca toate versiunile de aplicatie sunt preinstalate ;). HTH. > -- > P. "pe bune, containerele n-au nici o legatura cu povestea asta" > _______________________________________________ > RLUG mailing list > [email protected] > http://lists.lug.ro/mailman/listinfo/rlug > _______________________________________________ RLUG mailing list [email protected] http://lists.lug.ro/mailman/listinfo/rlug
