2015-08-25 15:44 GMT+03:00 Catalin Muresan <[email protected]>:
> 2015-08-25 13:03 GMT+01:00 Petru Rațiu <[email protected]>: > > > N-am nici o problema cu enshpe versiuni diferite in pipeline-ul de > > development, dar pe live eu prezint _un_ serviciu, da. Ma intereseaza sa > > fie consistent (pe oricate servere sau datacentere ar fi in spate) si sa > > treaca printr-un proces riguros de change management. Dar poate lucram in > > medii diferite... > > > > Normal ca oricine vrea asta, cmon. Doar ca realistic pe live or sa fie mai > multe versiuni al aceluias serviciu. > Dar dupa ce au deployment rapid si consistent vor si rollback instant, ca > deh au facut buba mare si trebuie rezolvat - 2 versiuni , una live > Dupa ce ai deploy/rollback rapid, consistent si alea alea vor deploy > partial, adica 5% din trafic sa treaca prin versiunea noua de aplicatie ca > deh daca e buba mare sa fie doar la 5%. Dupa aia 15%,30%. etc. - 2 > versiuni, ambele live. > Dupa aia or sa vrea API versioning unde ai defapt o versiune mai noua si > una mai veche care merg simultan (si care or sa evolueze paralel). - 4 > versiuni, 2 live. > Si ai doua optiuni, ori le tai macaroana din start ori iti faci un sistem > care sa suporte asa ceva. > > Pai cam asta incerc sa fac, sa masor cam cat e macaroana si unde o taiem, dinainte sa vina idei. IMHO situatia e asa: daca userului i se prezinta produsul ca "intri la http://blabla.net/foo si ai acolo aplicatia cutarescu", apai aplicatia aia trebuie sa i se prezinte sub o singura forma gogului cu pricina, indiferent de ce loz castigator sau necastigator a tras din balancer sau anycast sau pana mea. Daca faci A/B test, o faci cu feature flags intr-o unica aplicatie (rezerv scenariul cu red/green environments pt. migrari mult mai mari, nu pt. common releases). Daca o sa-mi vina userul ca "ieri la ora X, am incercat Y si mi-a iesit Z", prefer sa stiu care era versiunea W care era in productie, ce a schimbat, cine a pus-o live, cine i-a facut review si cine repara, nu sa fie un quest in sine "oare ce-o fi nimerit". Treaba cu serializarea release-urilor se face de catre cine e designat ca release manager (un om, un script, un proces, not my problem) undeva in pipeline. Chestiile paralelizabile se intampla mai aproape de devi, care pot trai daca vor in universul lor paralel in care doar feature-ul la care lucreaza acum exista. Acolo e bine mersi loc de composer si curl|sh si alte gheisme(tm) de genul asta, pe live vreau releasuri reproductibile si consistente (in functie de environment, nevoia asta de consistenta se poate certa mai mult sau mai putin cu legile termodinamicii si relativitatii, dar personal prefer sa imping produsul si procesul departe de directiile unde asta conteaza). > Oricum asta e alta discuitie, vreau doar sa atrag atentia sau sa trezesc > curiozitatea celor care nu sunt in discutie, domeniul e foarte interesant > si vorba aia "de viitor" :). > Eu am un background mai de inginer constructor, mie mi s-a bagat in cap ca infrastructurile reliable au principii simple si clare in spate si enshpe factori de siguranta suplimentari. Complexitatea e un bug in sine. Ca atare nu cred ca facem vreun bine industriei daca permitem chestii de-astea ozenistice doar pentru ca cineva le cere, fara sa aiba si argumente. "Mi-e mai simplu la development" nu e un argument pt. probleme de productie. Nu e nici contra, dar e irelevant. -- Petre, oldschool. _______________________________________________ RLUG mailing list [email protected] http://lists.lug.ro/mailman/listinfo/rlug
