Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > pl.comp.lang.php > #15875 > unrolled thread

Laravel - jakie pliki i foldery można usunąć?

Back to article view | Back to pl.comp.lang.php

Contents

  Laravel - jakie pliki i foldery można usunąć? Marek S <precz@spamowi.com> - 2018-12-14 22:59 +0100
    Re: Laravel - jakie pliki i foldery można usunąć? Borys Pogoreło <borys@pl.edu.leszno> - 2018-12-16 12:29 +0100
      Re: Laravel - jakie pliki i foldery można usunąć? Marek S <precz@spamowi.com> - 2018-12-16 16:40 +0100
        Re: Laravel - jakie pliki i foldery można usunąć? Wojciech Bancer <wojciech.bancer@gmail.com> - 2018-12-16 17:00 +0100
          Re: Laravel - jakie pliki i foldery można usunąć? Marek S <precz@spamowi.com> - 2018-12-16 17:07 +0100
            Re: Laravel - jakie pliki i foldery można usunąć? Wojciech Bancer <wojciech.bancer@gmail.com> - 2018-12-16 17:11 +0100
              Re: Laravel - jakie pliki i foldery można usunąć? Marek S <precz@spamowi.com> - 2018-12-16 17:33 +0100
                Re: Laravel - jakie pliki i foldery można usunąć? Wojciech Bancer <wojciech.bancer@gmail.com> - 2018-12-16 18:11 +0100
                  Re: Laravel - jakie pliki i foldery można usunąć? Marek S <precz@spamowi.com> - 2018-12-16 18:26 +0100
                    Re: Laravel - jakie pliki i foldery można usunąć? Wojciech Bancer <wojciech.bancer@gmail.com> - 2018-12-17 20:42 +0100
                      Re: Laravel - jakie pliki i foldery można usunąć? Marek S <precz@spamowi.com> - 2018-12-18 21:53 +0100
                        Re: Laravel - jakie pliki i foldery można usunąć? Wojciech Bancer <wojciech.bancer@gmail.com> - 2018-12-18 22:13 +0100
                          Re: Laravel - jakie pliki i foldery można usunąć? Marek S <precz@spamowi.com> - 2018-12-22 20:47 +0100
                            Re: Laravel - jakie pliki i foldery można usunąć? Wojciech Bancer <wojciech.bancer@gmail.com> - 2018-12-22 20:54 +0100
                              Re: Laravel - jakie pliki i foldery można usunąć? Marek S <precz@spamowi.com> - 2018-12-23 14:56 +0100
                                Re: Laravel - jakie pliki i foldery można usunąć? Borys Pogoreło <borys@pl.edu.leszno> - 2018-12-26 17:51 +0100
                          Re: Laravel - jakie pliki i foldery można usunąć? Roman Tyczka <noemail@because.no> - 2018-12-23 13:30 +0100
                            Re: Laravel - jakie pliki i foldery można usunąć? Marek S <precz@spamowi.com> - 2018-12-23 14:56 +0100
                            Re: Laravel - jakie pliki i foldery można usunąć? rePeter <no@spam.no> - 2018-12-23 16:46 +0100
                              Re: Laravel - jakie pliki i foldery można usunąć? Marek S <precz@spamowi.com> - 2018-12-23 19:10 +0100
                                Re: Laravel - jakie pliki i foldery można usunąć? rePeter <no@spam.no> - 2018-12-24 11:59 +0100
                                  Re: Laravel - jakie pliki i foldery można usunąć? Roman Tyczka <noemail@because.no> - 2018-12-24 14:18 +0100
                                    Re: Laravel - jakie pliki i foldery można usunąć? rePeter <no@spam.no> - 2018-12-24 14:46 +0100
                                      Re: Laravel - jakie pliki i foldery można usunąć? Roman Tyczka <noemail@because.no> - 2018-12-24 16:13 +0100
                                        Re: Laravel - jakie pliki i foldery można usunąć? rePeter <no@spam.no> - 2018-12-24 22:32 +0100
                                  Re: Laravel - jakie pliki i foldery można usunąć? Wojciech Bancer <wojciech.bancer@gmail.com> - 2018-12-27 14:50 +0100
                                Re: Laravel - jakie pliki i foldery można usunąć? Borys Pogoreło <borys@pl.edu.leszno> - 2018-12-26 17:56 +0100
                                  Re: Laravel - jakie pliki i foldery można usunąć? Marek S <precz@spamowi.com> - 2018-12-26 21:41 +0100
                                    Re: Laravel - jakie pliki i foldery można usunąć? Borys Pogoreło <borys@pl.edu.leszno> - 2018-12-26 23:47 +0100
                                      Re: Laravel - jakie pliki i foldery można usunąć? rePeter <no@spam.no> - 2018-12-27 01:19 +0100
                                        Re: Laravel - jakie pliki i foldery można usunąć? Borys Pogoreło <borys@pl.edu.leszno> - 2018-12-27 15:39 +0100
                            Re: Laravel - jakie pliki i foldery można usunąć? Wojciech Bancer <wojciech.bancer@gmail.com> - 2018-12-27 13:18 +0100
                              Re: Laravel - jakie pliki i foldery można usunąć? Borys Pogoreło <borys@pl.edu.leszno> - 2018-12-27 15:45 +0100
                                Re: Laravel - jakie pliki i foldery można usunąć? Wojciech Bancer <wojciech.bancer@gmail.com> - 2018-12-27 16:10 +0100
                                  Re: Laravel - jakie pliki i foldery można usunąć? Borys Pogoreło <borys@pl.edu.leszno> - 2018-12-27 21:33 +0100
                                    Re: Laravel - jakie pliki i foldery można usunąć? Wojciech Bancer <wojciech.bancer@gmail.com> - 2018-12-27 22:08 +0100
                                      Re: Laravel - jakie pliki i foldery można usunąć? Borys Pogoreło <borys@pl.edu.leszno> - 2018-12-27 23:17 +0100
                                        Re: Laravel - jakie pliki i foldery można usunąć? Wojciech Bancer <wojciech.bancer@gmail.com> - 2018-12-27 23:31 +0100
        Re: Laravel - jakie pliki i foldery można usunąć? Borys Pogoreło <borys@pl.edu.leszno> - 2018-12-16 17:37 +0100
          Re: Laravel - jakie pliki i foldery można usunąć? Marek S <precz@spamowi.com> - 2018-12-16 18:33 +0100
            Re: Laravel - jakie pliki i foldery można usunąć? Wojciech Bancer <wojciech.bancer@gmail.com> - 2018-12-17 20:43 +0100
              Re: Laravel - jakie pliki i foldery można usunąć? Marek S <precz@spamowi.com> - 2018-12-18 22:01 +0100
                Re: Laravel - jakie pliki i foldery można usunąć? Wojciech Bancer <wojciech.bancer@gmail.com> - 2018-12-18 22:14 +0100
                  Re: Laravel - jakie pliki i foldery można usunąć? Tomek <skowtm@wp.xx.pl> - 2018-12-19 09:57 +0100
                    Re: Laravel - jakie pliki i foldery można usunąć? Wojciech Bancer <wojciech.bancer@gmail.com> - 2018-12-19 10:34 +0100

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#15951

Sun, 23 Dec 2018 19:10:27 +0100      
Marek S <precz@spamowi.com>   napisał(a):

> 3. Przesiadam się na PHPStorma z Dreamweavera - tu też doświadczam 
> kłopotu pewnego. FTP pod PHPStorm transferuje plik za plikiem. W DW 
> równolegle to się odbywało. Na oko po 10 połączeń na raz. Wtedy FTP nie 
> był aż tak dokuczliwy. Być może to kwestia ustawienia czegoś gdzieś.

Nie używam PHPStorma do przesyłania plików więc nie wiem,
w lftp (i zapewne w innych tego typu klientach) można przesyłać pliki równolegle.

Git chyba też specjalnych cudów nie dokona, jeśli używa http lub ssh do przesyłu.


-- 
pozdrawiam, Peter

[toc] | [prev] | [next] | [standalone]

#15952

On Mon, 24 Dec 2018 11:59:24 +0100, rePeter wrote:

>> 3. Przesiadam się na PHPStorma z Dreamweavera - tu też doświadczam 
>> kłopotu pewnego. FTP pod PHPStorm transferuje plik za plikiem. W DW 
>> równolegle to się odbywało. Na oko po 10 połączeń na raz. Wtedy FTP nie 
>> był aż tak dokuczliwy. Być może to kwestia ustawienia czegoś gdzieś.
> 
> Nie używam PHPStorma do przesyłania plików więc nie wiem,
> w lftp (i zapewne w innych tego typu klientach) można przesyłać pliki równolegle.
> 
> Git chyba też specjalnych cudów nie dokona, jeśli używa http lub ssh do przesyłu.

Tylko, że git wysyła różnice a nie całe pliki, to może dać kolosalnie mniej
danych do przesyłu.

-- 
pozdrawiam
Roman Tyczka

[toc] | [prev] | [next] | [standalone]

#15953

Mon, 24 Dec 2018 14:18:58 +0100      
Roman Tyczka <noemail@because.no>   napisał(a):


> > Git chyba też specjalnych cudów nie dokona, jeśli używa http lub ssh do przesyłu.  
> 
> Tylko, że git wysyła różnice a nie całe pliki, to może dać kolosalnie mniej
> danych do przesyłu.

OK, ale czy dla plików www ma to aż takie znaczenie?
jpga czy mpga nie wyśle zmienionego kawałka, natomiast skrypty php, js, css, to
właściwie małe pliczki, wydaje mi się, że bez znaczenia czy są przesyłane całe, czy ich
fragmenty. Dla mnie ważne aby szło hurtem i z automatu, różnice w sekundach nie robią
różnicy.
Ale muszę sobie przy okazji przeprowadzić jakiś test na żywym organizmie.

-- 
pozdrawiam, Peter

[toc] | [prev] | [next] | [standalone]

#15954

On Mon, 24 Dec 2018 14:46:24 +0100, rePeter wrote:

>>> Git chyba też specjalnych cudów nie dokona, jeśli używa http lub ssh do przesyłu.  
>> 
>> Tylko, że git wysyła różnice a nie całe pliki, to może dać kolosalnie mniej
>> danych do przesyłu.
> 
> OK, ale czy dla plików www ma to aż takie znaczenie?
> jpga czy mpga nie wyśle zmienionego kawałka, natomiast skrypty php, js, css, to
> właściwie małe pliczki, wydaje mi się, że bez znaczenia czy są przesyłane całe, czy ich
> fragmenty. Dla mnie ważne aby szło hurtem i z automatu, różnice w sekundach nie robią
> różnicy.
> Ale muszę sobie przy okazji przeprowadzić jakiś test na żywym organizmie.

Sam transfer FTP jest szybki, jak łącze, ale problemem jest sama obsługa
poleceń FTPowych, których przy setkach plików są setki, a dodatkowo każde
polecenie jest parsowane od nowa (protokół tekstowy). Także system plików
daje opóźnienie na otwieraniu, kasowaniu i pisaniu od nowa _każdego_ pliku,
to kosztowne sprawy. 
No i sprawa z boku tematu szybkości, choć czasem istotna. Gdy okaże się, że
coś jest nie tak i trzeba szybko przywrócić pooprzednią wersję to git zrobi
to w kilka sekund.

Wesołych Świąt wszystkim! :-)

-- 
pozdrawiam
Roman Tyczka

[toc] | [prev] | [next] | [standalone]

#15955

Mon, 24 Dec 2018 16:13:52 +0100      
Roman Tyczka <noemail@because.no>   napisał(a):

> On Mon, 24 Dec 2018 14:46:24 +0100, rePeter wrote:
> 
> >>> Git chyba też specjalnych cudów nie dokona, jeśli używa http lub ssh do
> >>> przesyłu.    
> >> 
> >> Tylko, że git wysyła różnice a nie całe pliki, to może dać kolosalnie mniej
> >> danych do przesyłu.  
> > 
> > OK, ale czy dla plików www ma to aż takie znaczenie?
> > jpga czy mpga nie wyśle zmienionego kawałka, natomiast skrypty php, js, css, to
> > właściwie małe pliczki, wydaje mi się, że bez znaczenia czy są przesyłane całe, czy
> > ich fragmenty. Dla mnie ważne aby szło hurtem i z automatu, różnice w sekundach nie
> > robią różnicy.
> > Ale muszę sobie przy okazji przeprowadzić jakiś test na żywym organizmie.  
> 
> Sam transfer FTP jest szybki, jak łącze, ale problemem jest sama obsługa
> poleceń FTPowych, których przy setkach plików są setki, a dodatkowo każde
> polecenie jest parsowane od nowa (protokół tekstowy). Także system plików
> daje opóźnienie na otwieraniu, kasowaniu i pisaniu od nowa _każdego_ pliku,
> to kosztowne sprawy. 

To chyba załatwia opcja parallel

> No i sprawa z boku tematu szybkości, choć czasem istotna. Gdy okaże się, że
> coś jest nie tak i trzeba szybko przywrócić pooprzednią wersję to git zrobi
> to w kilka sekund.

Ale mówimy o developowaniu lokalnie i wypuszczaniu gotowców na serwer.

> Wesołych Świąt wszystkim! :-)

Wesołych  👍





-- 
pozdrawiam, Peter

[toc] | [prev] | [next] | [standalone]

#15974

On 2018-12-24, rePeter <no@spam.no> wrote:

[...]

>> równolegle to się odbywało. Na oko po 10 połączeń na raz. Wtedy FTP nie 
>> był aż tak dokuczliwy. Być może to kwestia ustawienia czegoś gdzieś.
>
> Nie używam PHPStorma do przesyłania plików więc nie wiem,
> w lftp (i zapewne w innych tego typu klientach) można przesyłać pliki równolegle.
>
> Git chyba też specjalnych cudów nie dokona, jeśli używa http lub ssh do przesyłu.

Gita można przede wszystkim użyć na maszynie docelowej, ma kompresję
i przesyła delty. Jakby nie skręcać, to równoległe przesyłanie plików
przez FTP jest i wolniejsze, i bardziej zawodne i niespecjalnie łatwo
jest zrobić rollback, sprawdzanie poprawności plików, wykonanie komend
na serwerze itp.

-- 
Wojciech Bańcer
wojciech.bancer@gmail.com

[toc] | [prev] | [next] | [standalone]

#15961

Dnia Sun, 23 Dec 2018 19:10:27 +0100, Marek S napisał(a):

> 3. Przesiadam się na PHPStorma z Dreamweavera - tu też doświadczam 
> kłopotu pewnego. FTP pod PHPStorm transferuje plik za plikiem. W DW 
> równolegle to się odbywało. Na oko po 10 połączeń na raz. Wtedy FTP nie 
> był aż tak dokuczliwy. Być może to kwestia ustawienia czegoś gdzieś.

Connection > Advanced > Concurrent connections limit

Czasem warto poklikać, zamiast się męczyć.

-- 
Borys Pogoreło
borys(#)leszno,edu,pl

[toc] | [prev] | [next] | [standalone]

#15967

W dniu 2018-12-26 o 17:56, Borys Pogoreło pisze:
> Dnia Sun, 23 Dec 2018 19:10:27 +0100, Marek S napisał(a):
> 
>> 3. Przesiadam się na PHPStorma z Dreamweavera - tu też doświadczam
>> kłopotu pewnego. FTP pod PHPStorm transferuje plik za plikiem. W DW
>> równolegle to się odbywało. Na oko po 10 połączeń na raz. Wtedy FTP nie
>> był aż tak dokuczliwy. Być może to kwestia ustawienia czegoś gdzieś.
> 
> Connection > Advanced > Concurrent connections limit
> 
> Czasem warto poklikać, zamiast się męczyć.


Ale... opis tej opcji jest dokładnie odwrotny:

Select this checkbox to have PhpStorm restrict the number of connections 
to be supported simultaneously and specify the maximum number of allowed 
connections in the field.

Teraz nie mam jak przetestować jak opcja działa ale z opisu wynika, że 
mogę w ten sposób narzucić ograniczenie na ilość jednoczesnych połączeń 
a nie zmusić PHPStorm do ich tworzenia.

Póki co udało mi się utworzyć dwa równoległe połączenia poprzez 
zaznaczenie folderu do uploadu i rozpoczęcie transmisji, a potem to samo 
z innym folderem gdy poprzednia transmisja trwa. Ale gdy zaznaczę oba na 
raz lub folder nadrzędny do nich, to pliki będą leciały gęsiego. Tak 
zaobserwowałem.

-- 
Pozdrawiam,
Marek

[toc] | [prev] | [next] | [standalone]

#15970

Dnia Wed, 26 Dec 2018 21:41:02 +0100, Marek S napisał(a):

> Select this checkbox to have PhpStorm restrict the number of connections 
> to be supported simultaneously and specify the maximum number of allowed 
> connections in the field.

Spróbuj tam wpisać np. 5 i zobacz co się stanie.

Akurat tej opcji nie testowałem, bo wrzucanie plików przez FTP to jest męka
i jeśli już muszę, to robię to z serwera na serwer.

-- 
Borys Pogoreło
borys(#)leszno,edu,pl

[toc] | [prev] | [next] | [standalone]

#15971

Wed, 26 Dec 2018 23:47:32 +0100      
Borys Pogoreło <borys@pl.edu.leszno>   napisał(a):

> Dnia Wed, 26 Dec 2018 21:41:02 +0100, Marek S napisał(a):
> 
> > Select this checkbox to have PhpStorm restrict the number of connections 
> > to be supported simultaneously and specify the maximum number of allowed 
> > connections in the field.  
> 
> Spróbuj tam wpisać np. 5 i zobacz co się stanie.
> 
> Akurat tej opcji nie testowałem, bo wrzucanie plików przez FTP to jest męka
> i jeśli już muszę, to robię to z serwera na serwer.

Porównujesz dwa różne pojęcia.
FTP to tylko protokół.
Z serwera na serwer też musisz to jakimś protokołem przesłać.


-- 
pozdrawiam, Peter

[toc] | [prev] | [next] | [standalone]

#15975

Dnia Thu, 27 Dec 2018 01:19:49 +0100, rePeter napisał(a):

>> Akurat tej opcji nie testowałem, bo wrzucanie plików przez FTP to jest męka
>> i jeśli już muszę, to robię to z serwera na serwer.
> 
> Porównujesz dwa różne pojęcia.
> FTP to tylko protokół.
> Z serwera na serwer też musisz to jakimś protokołem przesłać.

I piszę o FTP. Między dwoma serwerami z solidną "rurą" nawet dużo
niewielkich plików przesyła się bardzo szybko w ten sposób.

-- 
Borys Pogoreło
borys(#)leszno,edu,pl

[toc] | [prev] | [next] | [standalone]

#15973

On 2018-12-23, Roman Tyczka <noemail@because.no> wrote:

[...]

>> I na serwer też buduje się to lokalnie, a nie lata niepotrzebnie
>> po FTP. Taki proces nazywa się "deployment".
>
> A możesz coś więcej o deplymencie napisać? Bo ja też obecnie jadę przez
> FTPa i mnie trafia. Chociaż pewnie potrzebny jest do tego shell, a na
> hostingu jaki obecnie mam niestety shella nie ma.
> Niemniej ciekawi mnie czy deployment robisz gitem czy jak?
> Tak czy owak napisz trzy słowa, thx.

Naprostsza wersja to:
https://deployer.org/
Oferuje np. rollbackm ale tak, wymaga SSH.

A przy bardziej zaawansowanych projektach mam postawionego CI, który
reaguje na commity gita z brancha do develop i do mastera, buduje
paczkę z wersją i instaluje na serwerze, robi migrację bazy (o ile
trzeba) itp.

A argument z hostingiem? Hostingi które dają SSH kosztują mniej niż
200 zł rocznie. Koszt czasu programisty wrzucającego dzielnie pliki 
ręcznie przewyższa tą kwotę już po jednej takiej akcji.

-- 
Wojciech Bańcer
wojciech.bancer@gmail.com

[toc] | [prev] | [next] | [standalone]

#15976

Dnia Thu, 27 Dec 2018 13:18:05 +0100, Wojciech Bancer napisał(a):

> Naprostsza wersja to:
> https://deployer.org/
> Oferuje np. rollbackm ale tak, wymaga SSH.

O, ciekawe, dzięki. W praktyce jest wygodniejsze, niż skrypty shella
(pominąwszy czytelniejszy i spójny format komunikatów)?

-- 
Borys Pogoreło
borys(#)leszno,edu,pl

[toc] | [prev] | [next] | [standalone]

#15977

On 2018-12-27, Borys Pogoreło <borys@pl.edu.leszno> wrote:

[...]

>> Naprostsza wersja to:
>> https://deployer.org/
>> Oferuje np. rollbackm ale tak, wymaga SSH.
>
> O, ciekawe, dzięki. W praktyce jest wygodniejsze, niż skrypty shella
> (pominąwszy czytelniejszy i spójny format komunikatów)?

No dla mnie jest, ale wiadomo że każdy ma swoje przyzwyczajenia.
Ja mam starsze projekty w symfony z tym skonfigurowane.

Tu masz oficjalnie wspierane recipe:
https://github.com/deployphp/deployer/tree/master/recipe
m.in. cake, laravel, symfony 2/3/4 (każdy ma inną strukturę).
A są jeszcze te 3rd party. No i bardzo łatwo to rozbudować poprzez
wstrzykiwanie się w eventy.

Typowo dla tego typu narzędzi - tworzy nowy katalog z wersją (iteracyjną), 
robi wszystko co ma robić i dopiero jak wszystko skończy poprawnie, to podmienia 
symlinka "current". Wstrzyknąć można np. migrację bazy danych (z symfony wspierany 
jest doctrine migration), potrafi też zadbać o prawa do zapisu wskazanych katalogów,
czyści cache itp.

Dość łatwo da się rozbudować o równoległy deploy na kilka serwerów.
Osobiście zacząłem używać po tym jak capifony umarł:
https://github.com/everzet/capifony
capistrano/symfony mi nie podpadł, a trzymanie ruby tylko dla tego
jednego frameworka było overkillem :)

Alternatywą (którą mi się zdarzało stosować w projektach JS) jest
też shipit + shipit-deploy. Pozwala np. budować sobie "gdzieś na boku"
taką aplikację javascript, a na serwer posłać tylko niezbędne 
pliki.

https://github.com/shipitjs/shipit/tree/master/packages/shipit-deploy

Ale w kategorii "mało kodzenia dużo efektu" deployer jest najlepszy :)

-- 
Wojciech Bańcer
wojciech.bancer@gmail.com

[toc] | [prev] | [next] | [standalone]

#15978

Dnia Thu, 27 Dec 2018 16:10:35 +0100, Wojciech Bancer napisał(a):

> Typowo dla tego typu narzędzi - tworzy nowy katalog z wersją (iteracyjną), 
> robi wszystko co ma robić i dopiero jak wszystko skończy poprawnie, to podmienia 
> symlinka "current". Wstrzyknąć można np. migrację bazy danych (z symfony wspierany 
> jest doctrine migration), potrafi też zadbać o prawa do zapisu wskazanych katalogów,
> czyści cache itp.

A tak z ciekawości - da się zrealizować scenariusze w rodzaju "deploy się
sypnął na dalszym etapie, więc wycofaj migracje w bazie, ale tylko te przed
chwilą wykonane"? Albo np. w jakiś sposób przekazać argumenty tylko do
jednego etapu procesu (przykładowo czasem chcę uruchomić tylko jeden Seeder
przy aktualizacji aplikacji Laravel)?

> Alternatywą (którą mi się zdarzało stosować w projektach JS) jest
> też shipit + shipit-deploy. Pozwala np. budować sobie "gdzieś na boku"
> taką aplikację javascript, a na serwer posłać tylko niezbędne 
> pliki.

Też sobie zapiszę. Na szczęście w JS nie mam takich projektów, by sięgać po
tak rozbudowane narzędzia.

-- 
Borys Pogoreło
borys(#)leszno,edu,pl

[toc] | [prev] | [next] | [standalone]

#15981

On 2018-12-27, Borys Pogoreło <borys@pl.edu.leszno> wrote:

[...]

>> Typowo dla tego typu narzędzi - tworzy nowy katalog z wersją (iteracyjną), 
>> robi wszystko co ma robić i dopiero jak wszystko skończy poprawnie, to podmienia 
>> symlinka "current". Wstrzyknąć można np. migrację bazy danych (z symfony wspierany 
>> jest doctrine migration), potrafi też zadbać o prawa do zapisu wskazanych katalogów,
>> czyści cache itp.
>
> A tak z ciekawości - da się zrealizować scenariusze w rodzaju "deploy się
> sypnął na dalszym etapie, więc wycofaj migracje w bazie, ale tylko te przed
> chwilą wykonane"? Albo np. w jakiś sposób przekazać argumenty tylko do
> jednego etapu procesu (przykładowo czasem chcę uruchomić tylko jeden Seeder
> przy aktualizacji aplikacji Laravel)?

Możesz ustalać role poszczególnych serwerów (np. app/db) i przypisać odpowiednie
komendy do ról. Możesz wywołać poszczególne komendy, np:

dep database:migrate --roles=db
(w laravelu pewnie będzie dep artisan:migrate)

Tu masz więcej o możliwych podziałach tasków:
https://deployer.org/docs/tasks
w sekcji filtering.

Przy czym ja osobiście mam wpisane migracje do bazy tuż przed samym
linkowaniem do current, więc jak migracja bazy zawiedzie, to po prostu
nic się nie wykona (migrację pisze jako transakcyjne, więc jak coś pójdzie
nie tak, to z automatu pójdzie rollback na bazie).

Jeśli któraś faza nie wyjdzie, to "domyślnie" nic się nie zmieniło,
nie podmienił się link do wersji bieżącej, więc można cały proces 
ponowić od początku.

Wycofanie konkretnego etapu z bazy danych (już po tym jak deployment poszedł
i wszystko było ok) jeśli muszę, to już wykonuję na serwerze i przy założeniu,
że jest poprawnie wypełniona sekcja down() w migracjach. Ale szczerze mówiąc,
to wolę tak projektować system, by tego unikać, bo tego typu cofanie bazy to
proszenie się o kłopoty.

>> Alternatywą (którą mi się zdarzało stosować w projektach JS) jest
>> też shipit + shipit-deploy. Pozwala np. budować sobie "gdzieś na boku"
>> taką aplikację javascript, a na serwer posłać tylko niezbędne 
>> pliki.
>
> Też sobie zapiszę. Na szczęście w JS nie mam takich projektów, by sięgać po
> tak rozbudowane narzędzia.

Ja ostatnio jestem zakochany w serverless, więc siłą rzeczy więcej w node 
siedze. :-)

-- 
Wojciech Bańcer
wojciech.bancer@gmail.com

[toc] | [prev] | [next] | [standalone]

#15983

Dnia Thu, 27 Dec 2018 22:08:30 +0100, Wojciech Bancer napisał(a):

> Tu masz więcej o możliwych podziałach tasków:
> https://deployer.org/docs/tasks
> w sekcji filtering.

Ok, widzę, że seedery mógłbym rozwiązać przez input options.

> Przy czym ja osobiście mam wpisane migracje do bazy tuż przed samym
> linkowaniem do current, więc jak migracja bazy zawiedzie, to po prostu
> nic się nie wykona (migrację pisze jako transakcyjne, więc jak coś pójdzie
> nie tak, to z automatu pójdzie rollback na bazie).

A wtedy wchodzi MySQL, cały na biało, z implicit commit na ALTER TABLE...

> Wycofanie konkretnego etapu z bazy danych (już po tym jak deployment poszedł
> i wszystko było ok) jeśli muszę, to już wykonuję na serwerze i przy założeniu,
> że jest poprawnie wypełniona sekcja down() w migracjach. Ale szczerze mówiąc,
> to wolę tak projektować system, by tego unikać, bo tego typu cofanie bazy to
> proszenie się o kłopoty.

No niestety, na szczęście takie historie to rzadkość.

> Ja ostatnio jestem zakochany w serverless, więc siłą rzeczy więcej w node 
> siedze. :-)

E tam, jakieś nowoczesne fiu-bździu, kiedyś panie to były serwery ;)

-- 
Borys Pogoreło
borys(#)leszno,edu,pl

[toc] | [prev] | [next] | [standalone]

#15985

On 2018-12-27, Borys Pogoreło <borys@pl.edu.leszno> wrote:

[...]

>> Przy czym ja osobiście mam wpisane migracje do bazy tuż przed samym
>> linkowaniem do current, więc jak migracja bazy zawiedzie, to po prostu
>> nic się nie wykona (migrację pisze jako transakcyjne, więc jak coś pójdzie
>> nie tak, to z automatu pójdzie rollback na bazie).
>
> A wtedy wchodzi MySQL, cały na biało, z implicit commit na ALTER TABLE...

Ja bardziej postgresowy :)
Ale w takim razie pozostaje pisanie sensownych down();

>> Wycofanie konkretnego etapu z bazy danych (już po tym jak deployment poszedł
>> i wszystko było ok) jeśli muszę, to już wykonuję na serwerze i przy założeniu,
>> że jest poprawnie wypełniona sekcja down() w migracjach. Ale szczerze mówiąc,
>> to wolę tak projektować system, by tego unikać, bo tego typu cofanie bazy to
>> proszenie się o kłopoty.
>
> No niestety, na szczęście takie historie to rzadkość.

I tak lepiej to zautomatyzować niż ręcznie odpalać SQLki (a strona albo wali
500, albo ma maintenance mode na kilka godzin :)

>> Ja ostatnio jestem zakochany w serverless, więc siłą rzeczy więcej w node 
>> siedze. :-)
>
> E tam, jakieś nowoczesne fiu-bździu, kiedyś panie to były serwery ;)

Teraz serwery to się stawia przez infrastructure as a code i terraform :)

-- 
Wojciech Bańcer
wojciech.bancer@gmail.com

[toc] | [prev] | [next] | [standalone]

#15896

Dnia Sun, 16 Dec 2018 16:40:57 +0100, Marek S napisał(a):

> Ściągnięcie z serwera w USA tych 32MB trwało całą noc. Mniej więcej 
> jeden plik na sekundę pobierał się. Po godzinie oczekiwania poszedłem do 
> domu bo wiedziałem, że nie ma sensu czekać.

To jest jakaś chora sytuacja, a nie norma.

> SSH nie załatwi sprawy przy ściąganiu danych. Lokalnie też nie miałbym 
> gwarancji, że zainstalowanie frameworka composerem da mi dokładnie te 
> same pliki, co u klienta.

Oczywiście, że da. O to w tym rozwiązaniu przecież chodzi. Sprawdź sobie
zawartość pliku `composer.lock`.

-- 
Borys Pogoreło
borys(#)leszno,edu,pl

[toc] | [prev] | [next] | [standalone]

#15902

W dniu 2018-12-16 o 17:37, Borys Pogoreło pisze:
> 
> To jest jakaś chora sytuacja, a nie norma.

U nich norma. I to w różnych stanach tak jest. Do tej pory 4 lokalizacje 
korporacyjne stamtąd ogarniałem i wszędzie się żalili na wolne łącza. A 
to 3G gdziebyś się nie ruszył, to tak tam jest. Nic na to nie poradzę.

>> SSH nie załatwi sprawy przy ściąganiu danych. Lokalnie też nie miałbym
>> gwarancji, że zainstalowanie frameworka composerem da mi dokładnie te
>> same pliki, co u klienta.
> 
> Oczywiście, że da. O to w tym rozwiązaniu przecież chodzi. Sprawdź sobie
> zawartość pliku `composer.lock`.

Szczerze mówiąc nie wiem czy nie pousuwali tych plików. Ale przyjrzę się 
bo może faktycznie będzie lepiej lokalnie framework pobierać. Liczę na 
to, że w kopiach klienckich nikt nie grzebał.

-- 
Pozdrawiam,
Marek

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | pl.comp.lang.php

csiph-web