Hosting dla composera.

[aksel 0]

Cześc, zwracam się do was z jednym pytaniem. Potrzebuję do kilku rzeczy wykorzystać menedżer zarządzania zależnościami Composer.

 

Strona www: http://getcomposer.org/

Dokumentacja (installacja na *nix - https://getcomposer.org/doc/00-intro.md#installation-nix )

 

 

Moje pytanie - który hosting będzie w stanie obsłużyć takie coś? Pozdrawiam bardzo serdecznie.

[spindritf 240]

Dowolny VPS.

[ittw 3]

lub hosting współdzielony z dostępem przez SSH. (przy założeniu, że zainstalowane są także git, svn,hg - jeżeli z takich zależności korzystasz).

Zawsze też możesz update/install wykonać lokalnie i zaktualizować kod projektu

[PrecelusMaximus 53]

lub hosting współdzielony z dostępem przez SSH. (przy założeniu, że zainstalowane są także git, svn,hg - jeżeli z takich zależności korzystasz).

Zawsze też możesz update/install wykonać lokalnie i zaktualizować kod projektu

 

Lipa jest na współdzielonym. Często w cli są blokady i jakieś inne dziwne cuda się dzieją. Próbowałem na kilku "developerskich" hostingach i powiem że różnie było. Żeby było śmiesznie jak dostałem dostęp do ssh na koncie hostingowych nazwa.pl (najtańszy projekt) to poszło bez problemu, nawet mogłem symfony z konsoli jechać :-) Jeśli projekt wymaga dostępu cli to jedynie VPS a jeśli decydujesz się na shared to najpierw się upewnij czy to co chcesz będzie działać, jeśli nie są pewno poproś o testy.

[Pan Kot 1535]

Generalnie przy VPSie masz pewność, że to będzie działać dokładnie tak jak chcesz tego Ty, a nie provider hostingu współdzielonego. Bez proszenia się i rozwiązywania problemów przez support.

[MyDevil.net 24]

Witamy,

 

zobacz naszą ofertę: MyDevil.net - pakiet MD2 obsłuży bez problemu Composera - sprawdziliśmy

 

Zapraszamy do przetestowania naszych usług przez 14 dni - dodatkowo zachęcamy do skorzystania z kodu promocyjnego dla użytkowników webhostingtalk.pl 10% zniżki: FORUM_WHT (przy płatności na 6 i 12 miesięcy).

[Gość nrm]

localhost. composer na produkcji to jak dziecko z zapałkami.

[PapaSmerf 497]

@nrm - a jak robisz deployment to przesyłasz cały katalog vendor?

[aksel 0]

Dzięki serdeczne, kupię jakiegoś VPS. Pozdrawiam wszystkich.

[Gość nrm]

@nrm - a jak robisz deployment to przesyłasz cały katalog vendor?

 

Oczywiście, za pierwszym razem i tak muszę przecież całość przegrać, a za kolejnymi jest tylko dany commit. Composer update na produkcji to jak chodzenie z granatem - już miałem okazję się o tym przekonać. W sumie nie ma żadnego rozsądnego powodu dla którego miałbym bawić się composerem na produkcji.

[PrecelusMaximus 53]

Heh, niby tak. Ja też zawsze zgrywam pliki nawet jak ma to trwać 20h ... ale jak pracujesz współpracujesz z innymi przydałoby się wspólne środowisk testowe, bezsensu tracić czas, a te narzędzia mają pomagać developerowi :-)

[PapaSmerf 497]

@nrm - ale argument? Bo aż mnie zaciekawiłeś (i co to znaczy, że musisz przerzucać?). Mnie by się nie chciało przerzucać całego katalogu vendor po SSH czy trzymać go w repo, tym bardziej, kiedy używamy Capistrano do deploymentu.

[Gość nrm]

"muszę" - w sensie, że i tak idzie deploy na produkcję. "wspólne środowisko" - jest, nie rozumiem czemu miało by go nie być w takim układzie. "mnie by sie nie chciało przerzucac katalogu" - mi może też nie, na szczęście nie musze sie tym martwić ani przerzucać tego ręcznie, ani w ogóle o tym myśleć Ja tam wam nie bronię, ale u siebie nie pozwoliłbym nikomu na update composera na produkcji. Zresztą zwolennicy takiego rozwiązania trzymają się swoich zasad tylko do pierwszego roz***ania projektu

[PapaSmerf 497]

@nrm - ale w dalszym ciągu żadnej argumentacji, tylko "nie, bo nie". Akurat deployment i instalowanie zależności na serwerze produkcyjnym przy wdrożeniu to sprawa dosyć powszechna, dlatego mnie to dziwi.

[Gość nrm]

Jak żadnej? To chyba w drogą stronę żadnej Powszechna? Szczerze mówiąc to ja nie znam żadnych dużych zespołów, które by cokolwiek robiły na produkcji poza deployem. Można? Można, tylko po co. Komplikowanie sobie życia i stosunkowo duże ryzyko wysypania się projektu. Zresztą, jak dla mnie rób sobie co chcesz, możesz nawet edytować na produkcji live

[PapaSmerf 497]

No gdzie masz tę argumentacje? Znamy w takim razie inne "duże zespoły". Jak ktoś nie potrafi ustawić odpowiedniego stability i pilnować wersji bibliotek *, to faktycznie może mieć problem, tylko czy każdy commit zmienia zależności? Nie. Ba, w 99.9% nawet nie musisz tego ruszać. Przy automatycznym Continous Deployment już pojawiają się komplikacje.

 

Rób jak chcesz, ale głupot nie gadaj

 

* ba, masz nawet na trzech środowiskach (dev, test, prod) masz to samo. Jasne, autorzy libów są różni, ale tutaj wystarczy pilnować wersji, jak ktoś leci na dev-master co nie ma co się dziwić. Wyjątkiem są rzeczy, które nie powinny się zdarzać: w Laravelu było kiedyś BC pomiędzy dwoma wersjami w tej samej gałęzi, wtedy klops

[Gość nrm]

No właśnie, już nawet nie chciałem przytaczać historii Laravela bo to było nawet po moim zgłoszeniu błędu ;D Jak się ludziom wysypało to był płacz Oczywiście, że to tak nie powinno wyglądać ale średnio ma się na to wpływ (bo błędy mogą być po drugiej stronie), a skoro nie ma ani jednego powodu aby tak robić to sprawa prosta. Skoro masz taki powód to sobie rób, ja nie mam potrzeby dotykać composera na produkcji w ogóle.

[maniack 403]

.

Edytowano Wrzesień 13, 2017 przez maniack (zobacz historię edycji)

[PapaSmerf 497]

No właśnie, już nawet nie chciałem przytaczać historii Laravela bo to było nawet po moim zgłoszeniu błędu ;D Jak się ludziom wysypało to był płacz Oczywiście, że to tak nie powinno wyglądać ale średnio ma się na to wpływ (bo błędy mogą być po drugiej stronie), a skoro nie ma ani jednego powodu aby tak robić to sprawa prosta. Skoro masz taki powód to sobie rób, ja nie mam potrzeby dotykać composera na produkcji w ogóle.

 

W dalszym ciągu unikałeś argumentacji i mi tylko o to chodzi co napisałeś w pierwszym poście. Błąd w Laravelu doskonale pamiętam, bo wtedy poprzestałem wszelkich zabaw z nim (imho tak się poważnego projektu nie prowadzi).

 

 

To może pójdźmy w drugą stronę - dlaczego tak?

Skoro update produkcji odbywa się tylko w konkretnych momentach, niezależnie od aktualnych prac (commitów), to czym się różni wrzucenie "gołego" repo z odpowiedniego brancha/tagu i odpalenie composera od wrzucenia "pełnego" repo z gotowym i przetestowanym vendorem? Bo z doświadczenia wiem, że ta druga opcja jest i szybsza, i bezpieczniejsza. No chyba że sam projekt nie jest prowadzony gitem, albo jest prowadzony w niedbały sposób (hotfixy na masterze, brak wersjonowania/tagów, brak branchów na ficzery i bugfixy, itp.)

 

To nie chodzi w sumie o to "dlaczego tak", czy "dlaczego nie", tylko o kategoryczne pisanie, że nie, bez żadnej argumentacji. Poza tym, jak ktoś pyta "dlaczego nie?", to oczekuje odpowiedzi a nie kontr-pytania "dlaczego tak?".

 

@nrm,

@maniack

Jeśli ktoś robi deploy bez testowania, to życzę powodzenia, a na środowisku testowym - jeśli w zależnościach jest coś skopane w jakimkolwiek libie - elegancko Ci wyjdzie - wtedy nie robisz deployu i już - analogicznie jak w sytuacji z instalacją zależności na localu. Żaden rozsądny zespół nie będzie robił deploymentu bez testów. A jeśli ktoś ma różne wersje bibliotek na dev i prod - to nic tylko życzyć powodzenia. Niezależnie od tego jak instaluje zależności. Kwestia już tak naprawdę tego jak się tworzy oprogramowanie.

 

Poza tym, np. w Capistrano jest coś takiego jak rollback, jak coś pójdzie nie tak, zawsze można w ciągu kilku sekund (lub automatycznie) cofnąć ostatni deploy i po kłopocie.

 

Każdy robi jak chce/potrafi/jest mu wygodnie, tylko głupotę i jedyną słuszną wersję sprostowałem, bo to nie Composer na produkcji jest dzieckiem z zapałkami, tylko "programista" (+ ew. już sam software - vide Laravel - co w przypadku użycia odpowiednich narzędzi i tak da się bezproblemowo rozwiązać).

[maniack 403]

.

Edytowano Wrzesień 13, 2017 przez maniack (zobacz historię edycji)

[PapaSmerf 497]

Coraz ciekawsze wnioski wyciągasz

 

Tylko, że ja nie wyciągam żadnych wniosków, ale widzę, że Ty tak.

 

Dobra, skończmy już OT, bo trochę zboczyliśmy od głównego tematu. Trochę...