2015-08-21 22:48 GMT+01:00 Petru Rațiu <[email protected]>: > Multa lume alege 1 pentru ca e codul disponibil pentru toata lumea. Ma mir > > ca ai ajuns la problema asta filozofica si folosesti deja Linux, MySQL, > si > > multe multe altele la care sigur nu te-ai agitat asa de mult si nu ti-ai > > pus atitea probleme in a le folosi. > > > > > Aici nu inetelg ce vrei sa spui (sau mai degraba nu vreau sa cred ca > argumentul pe care vrei sa-l faci e atat de retard ca cel pe care il > inteleg eu, asa ca prefer sa cred ca nu am inteles). >
Ai inteles argumentul retard. Dece ai incredere in tot restul ecosistemului ? L-ai auditat la un moment dat si ai ? sau orbeste ? > Dar o intrebare, cum folosesti tu composer in productie? il folosesti > > pentru dependency management si cind faci deploy in productie codul > > respectiv nu instaleaza composer pe serverul de productie, right right ? > > > > > Nu folosesc (inca). E vorba de un proiect care a fost dezvoltat de niste > developeri fara sa-mi ceara parerea pana nu s-a ajuns la pusul in > productie. Acu incerc sa ma pun la curent cu cum se folosesc chestiile > astea intr-o forma de bun simt. Faptul ca pun intrebari inseamna ca inca > sper ca exista o solutie si ca inca nu am dat mailul cu "mizeria asta n-o > sa ajunga vreodata pe vreun mediu de productie pe care sunt eu admin". Tot > faptul ca pun intrebari inseamna ca de la cei care au decis sa foloseasca > frameworkuri de-astea moderne nu am ce insighturi operationale sa aflu, ca > inca sunt incantati de ce usor se scrie codul si uite ce simplu se pune > live. > composer nu se foloseste in productie, il folosesti doar la faza de build. Sa zicem ca ai o aplicatie care foloseste 20 module php si inca 5 scrise de compania ta si peste asta e aplicatia. Cu composer poti in loc sa tot copiezi de fiecare data de pe net cele 20 module, sa le faci doar referinta ceva de genul "ia de pe github versionea 1.2.3". Multe pachete au la rindul lor composer.json in care sunt mentionate toate dependintele (daca au) si or sa fie downloadate toate. Rezultatul e un director unde ai aplicatia si toate dependintele. De aici incolo nu ai nevoie de composer, iei directorul si il pui unde vrei tu. > > > Ca sa fac o analogie, e ca si cum as avea dubii privind identitatea si > > > competenta dentistului care imi umbla prin masele (ca vine cu masca > pusa > > si > > > nu-i vad decat ochii) si tu zici ca e ok ca masca aia e sterila. Faptul > > ca > > > poarta masca sterila si manusi nu inseamna ca stie ce face cand imi > baga > > > chestii prin dinti. > Diferenta e ca tu ai control total la ce dinti, ce dentist, ce scule foloseste, tot tot. > > cum ziceam mai sus. In Linux ai incredere, in CentOS ai. Daca nu ai, fai > > audit si daca tot e ok, il folosesti. Daca nu, nu. > > > > > Da, in Linux si Centos si Debian am incredere pentru ca stiu ca au un > mecanism de qa si ca artefactele lor de build imi vin semnate gpg, nu > trebuie sa verific de fiecare data ce e in ele. La mecanismul asta am niste > dubii: > Debian e hilar, adu-ti aminte de bug-ul de generat ssh keys care l-a introdus super Debian-ul ca au vrut ei sa repare un warning, si, ca bonus, nu l-au trimis si la upstream, l-au tinut doar pentru ei ca deh. QA. Semnatura gpg nu are valoare pentru ca nu-ti garanteaza ca odata ce se face un update nu se introduce si un backdoor. > 1. trebuie sa obtin un phar care nu stiu cine e ma-sa si ta-su, doar ca > l-am luat de pe un site si parea sa mearga si aia zic ca e legat de > versiunea cutarescu din git la care pot sa ma uit daca vreau (cum ar fi > uite o sursa si un link de unde iei rpm-ul care ar trebui sa fie produs din > sursa aia, fara sa-ti garantez in vreun fel ca uite asa l-am produs si iti > semnez eu gpg ca eu l-am produs). > https://github.com/composer/composer hai ca nu e facut de un chinez pe genunchi, sunt gramada de contributii, gramada de commits, lumea lucreaza la el, "lots of eyeballs". > 2. mecanismul de build trage chestii de pe internet din niste branchuri pe > care le mentin diversi, pe care nu pot sa-i urmaresc cand si de ce au facut > schimbari (asta cred ca e doable daca imi trag local repo-urile cu pricina > si-l invat pe composer sa traga doar de acolo stuff, si cineva de la mine > din organizatie le schimba pe-alea doar cand stie f. bine de ce) > asta e greseala numarul unu, nu trage din branch, ia dintr-un commit/tag/release etc. Ceva ce e stabil si nu se poate modifica. Cind ai release nou atunci schimbi versiunea/tag/branch/whatever si bineinteles testezi inainte. Totul e transparent (version control) asa ca trebuie doar sa te uiti. > 3. oarecum legat de 2, faptul ca versiunile de soft depind de ce anume se > nimerea sa fie pe repo-uri la momentul cand am dat build sau update sau > spanac, face sa nu pot garanta ca pot reproduce in alta parte un anumit > comportament, pentru ca nu pot fi sigur ca pot controla toate schimbarile. > Sa zicem ca am un mediu de sandbox pe care testez nushce nou si maret > feature, cum ma asigur ca mediul de productie va fi fix la fel si nu se vor > introduce buguri noi din cauza ca intre timp cineva prin una din dependinte > a decis ca schimba nushce api? > poti sa controlezi la singe versiunile din productie si versiunile din sandbox. Cine te opreste? Iar zic docker, dar aici te ajuta docker enorm, poti sa ai windows + virtualbox + vagrant + ubuntu + docker + containere cu centos pe statii la developeri si pe servere sa ai orice Linux + docker + acelasi container cu centos pe productie. Cu _exact_ aceeasi versiune pentru _toate_ librariile. Asta si separarea e marele avantaj docker. > PS: Incep sa suspectez ca ma trollezi, da' mi-am propus sa mai raspund la > inca 1-2 mailuri tot serios, pentru ca chiar vreau sa vad daca exista vreo > solutie, da' dupa aia scot si eu capacul la borcan. > Poate a fost troll din greseala, sincer n-am inteles dece nu ai incredere in composer si ai in alte softuri opensource. Daca nu ai incredere, auditeaza-le. Sau faci tot de la zero. > > -- > P. > _______________________________________________ > RLUG mailing list > [email protected] > http://lists.lug.ro/mailman/listinfo/rlug > _______________________________________________ RLUG mailing list [email protected] http://lists.lug.ro/mailman/listinfo/rlug
