Poprawne praktyki przy programowaniu serwisu (git, npm, composer itp)

0

Witam. Od jakiegoś czasu piszę mniejsze i większe stronki główne hobbystycznie zarówno front-end (html/css/js) jak i back-end (php). Do tej pory działałem bardzo chałupniczo, tzn całe kodowanie odbywało się bezpośrednio na FTP na zwykłym hostingu www. Gdy potrzebne były jakieś bilblioteki np. bootstrap czy coś z PHP to po prostu to pobierałem, wgrywałem na serwer i dołączałem do projektu - tyle. Uczę się teraz lepszych praktyk bo wiem że to złe.

Tak więc przez ostatnie dni zmieniłem to:

  1. Przeniosłem się z pracy na serwerze na lokalny (xampp).
  2. Wprowadziłem narzędzie npm i od teraz nim instaluję pakiety potrzebne przy frontendzie (bootstrap, jquery itp) zamiast ręcznie. W katalogu projektu mam teraz folder node_modules i package.json z używanymi pakietami.
  3. Do npm wprowadziłem gulp który od teraz łączy mi wszystkie pliki js i css w pojedyncze wraz z tymi z node_modules, minifikuje itp, na stronie mam załadowane tylko te wynikowe. Do projektu dołączył plik gulp.js.
  4. Wprowadziłem composer który instaluje mi zewnętrzne bilblioteki PHP. Do projektu dołączył folder vendor i composer.json

Pytanie co dalej?

Moim kolejnym krokiem powinno być chyba GIT. Gdy o nim czytam to wszędzie mówi się o nim w kontekście pracy zespołowej. Ja jednak obecnie piszę dane rzeczy w pojedynkę, i nie jako publiczne projekty tylko własne stronki.
Chcę go jednak wykorzystać jako jedyne poprawne rozwiązanie na sposób pracy nad serwisem - nie wiem czy słusznie. Chodzi o to by nie edytować wszystkiego przez FTP, tylko by to szło jakoś przez GIT - pytanie jak?

Czy dobrze rozumiem że to powinno wyglądać tak:

  1. Piszę sobie jakąś stronę w PHP i testuję jej działanie na lokalnym serwerze.

  2. To co zrobiłem działa i chcę by znalazło się na serwerze WWW.

  3. Robię więc commita do jakiegoś prywatnego repozytorium np. na github mojego kodu, ale z pominięciem plików wygenerowanych przez gulp, bez pakietów npm i composera.

  4. Na serwerze www przez zainstalowane na nim wszystkie narzędzie najpierw pobieram całą obecną zawartość z gita, potem instaluje zależności pakietów npm i composera a na koniec odpalam gulpa by wykonał wszystkie operacje na plikach js i css. I strona działa.

  5. Dodając w przyszłości jakąś nową funkcjonalność znowu wgrywam wszystko z komputera na githuba, z githuba na serwer i odpalam npm, composera by sprawdził czy nie doszły jakieś nowe pakiety wymagane i odpalam gulpa.

  6. Czy tak to powinno wyglądać? Czy jeszcze jakiegoś podstawowego narzędzia brakuje?

  7. Czy powinienem te wszystkie operacje z npm, composerem itp wykonać na serwerze, czy na gita wgrać jednak już komplet plików razem z tymi skompresowanymi przez gulp?

  8. Co jeżeli ja mam zwykły hosting www? Da się to wszystko jakoś ogarnąć, czy git i inne narzędzia wtedy tracą sens? Czy do każdego serwisu wtedy potrzebuję vps by to mogło działać?

Ogólnie proszę o podzielenie się tym jak to wygląda u Was, jak ta praca (głównie w pojedynkę jeśli tak też zdarza Wam się pracować) jest zorganizowana by to miało ręce i nogi?

Pozdrawiam

0

Moim kolejnym krokiem powinno być chyba GIT. Gdy o nim czytam
to wszędzie mówi się o nim w kontekście pracy zespołowej.

Nie tylko. Nawet używając go do jednoosobowych projektów, możesz dużo zyskać (choćby łatwe cofanie zmian jak się coś spieprzy. Masz dostępną całą historię zmian (pod warunkiem regularnego commitowania) i jak chcesz możesz powrócić do stanu z wczoraj jak i sprzed tygodnia, choćby.

Dodając w przyszłości jakąś nową funkcjonalność znowu wgrywam wszystko z komputera na githuba, z githuba na serwer

nie rozumiem o co ci chodzi w tym punkcie. Z Gita możesz korzystać bez żadnego Githuba (Github to tylko hosting dla Gita - trochę jak pliki *.jpg i Picassa (czy tam Google Photos albo jak to się nazywa teraz, cholera wie) - możesz mieć pliki *.jpg na dysku, a możesz je mieć w jakiejś usłudze w internecie, taką usługą dla obrazków może być właśnie Picassa, a Github jest taką usługą, która hostuje repozytoria kodu).

Czyli po prostu instalujesz Gita i Git działa ci na dysku i tworzy ci specjalne foldery na dysku, na których będzie zapisywać historię zmian (i tego gita obsługujesz zwykle albo wpisując komendy w linii poleceń, albo z poziomu IDE, jeśli twoje IDE obsługuje Gita, albo ściągasz jakieś GUI do Gita i obsługujesz to wizualnie.

Możesz potem wysłać zmiany na Githuba, ale zwykle to nie ma związku z tym, czy coś wrzucić albo nie wrzucisz na serwer produkcyjny.

Czy powinienem te wszystkie operacje z npm, (...) itp wykonać na serwerze,
czy na gita wgrać jednak już komplet plików razem z tymi skompresowanymi przez gulp?

Na gicie trzymasz zwykle kod źródłowy, taki do czytania dla ludzi i edytowania przez ludzi*, i najlepiej obsługiwać go z poziomu własnego komputera - a na serwer wrzucasz zwykle tylko pliki wynikowe**.

*chociaż też nie zawsze, ale niech będzie, że to takie uproszczenie.
** znowu, nie zawsze. niektóre hostingi wręcz działają na repozytoriach git, np. Heroku.

0
LukeJL napisał(a):

Dodając w przyszłości jakąś nową funkcjonalność znowu wgrywam wszystko z komputera na githuba, z githuba na serwer

nie rozumiem o co ci chodzi w tym punkcie. Z Gita możesz korzystać bez żadnego Githuba (Github to tylko hosting dla Gita - trochę jak pliki *.jpg i Picassa (czy tam Google Photos albo jak to się nazywa teraz, cholera wie) - możesz mieć pliki *.jpg na dysku, a możesz je mieć w jakiejś usłudze w internecie, taką usługą dla obrazków może być właśnie Picassa, a Github jest taką usługą, która hostuje repozytoria kodu).

Czyli po prostu instalujesz Gita i Git działa ci na dysku i tworzy ci specjalne foldery na dysku, na których będzie zapisywać historię zmian (i tego gita obsługujesz zwykle albo wpisując komendy w linii poleceń, albo z poziomu IDE, jeśli twoje IDE obsługuje Gita, albo ściągasz jakieś GUI do Gita i obsługujesz to wizualnie.

Możesz potem wysłać zmiany na Githuba, ale zwykle to nie ma związku z tym, czy coś wrzucić albo nie wrzucisz na serwer produkcyjny.

Bardzo dziękuję za obszerne odpowiedzi.
Co do tego to właśnie chodzi mi o to jak w najlepszy sposób wrzucić to na serwer produkcyjny, jak zsynchronizować serwer produkcyjny (serwer www lub vps) z moim lokalnym. Bo ja to rozumiałem tak że git m.in właśnie do tego służy. Jednak nie? Wiem że github to tylko jeden z hostingów gita, ale właśnie o to mi chodziło czy by wrzucać wyniki na www powinienem wpierw wgrywać moje zmiany na jakieś zdalne repozytorium (czyli np. na github) i z niego na serwer www? Jeśli nie to jak inaczej? Bo wgrywanie ręcznie przez FTP jest mało wydajne przy wielu plikach no i wtedy po za opcją cofania zmian nie widzę sensu korzystania z gita w przypadku jednej osoby. Wszędzie czytam (nawet na tym forum) że praca na serwerze produkcyjnym czy nawet na osobnym deweloperskim ale zdalnym jest bez sensu i powinno się to robić lokalnie. Ale nie potrafię właśnie zrozumieć tego jak w optymalny sposób przenosić moje prace lokalne na ich ostateczne miejsce w sieci.

0

W sumie to mógłbyś jeszcze skonfigurować sobie np jenkinsa i gita w taki sposób by przed każdym commitem na mastera (naucz się przy okazji mergowac branchu i korzystaj z techniki branch per feature) testować kod pod kątem pewnych założeń.

Tymi założeniami może być np code style zgodny z psr'ami, sprawdzanie czy kod nie powtarza sie (możliwości na takie sprawdzanie jest sporo). Jeśli dadz rade na tym etapie to robić pisz testy jednostkowe - to też zepniesz z Jenkins. Zamiast jenkinsa możesz użyć innego narzędzia do Ci/cd. A te narzędzia do sprawdzania kodu możesz też odpalać lokalnie (php code sniffer, php mess detector, php copy paste detector, piszę z pamięci wiec może nazwy nie są do końca poprawne)

0

najlepiej trzymać pliki na jakimś prywatnym repo, dodatkowo wypadałoby mieć subdomenę na której testujemy funkcjonalności, jak wszystko działa przesyłasz na domenę podstawową, w ten sposób nie ma przypału

0

Aaa i oczywiście wszelkie dane typu hasła do bazy, loginy, itp itd nie mogą być trzymane w repo. Dodatkowo, pomyśl nad tym by na środowisku developerskim zabezpieczyć dane klientów, tzn. np robisz funkcjonalność powiadomień o czymkolwiek za pomocą maili, więc nie chciałbyś aby na etapie testów do wszystkich użytkowników poszły jakieś maile z treścią "test/dupa".

Idąc dalej możesz pokusić się o postawienie wirtualnej maszyny albo dockera, gdzie będziesz trzymał w pełni skonfigurowane developerskie środowisko - po co? Taką maszynę można łatwo przenieść, w momencie gdy chciałbyś, aby ktokolwiek chociaż w jednej rzeczy Ci pomógł - unikniesz konfliktów typu A bo ja nie mam tego modułu w phpie, hmmm dziwne, u mnie działa albo musisz zainstalować phpa w wersji 5.5.5.5.5.5.5.5.4 zamiast 5.5.5.5.5.5.5.5.55 [sic!] . Dodatkowo możesz łatwiej podmieniać systemy/wersje oprogramowania - dzięki temu będziesz mógł sprawdzić czy kod zachowa się poprawnie na jakiejś nowszej wersji php'a i nie będziesz musiał w xampie żonglować wersjami serwera/phpa

0
czysteskarpety napisał(a):

najlepiej trzymać pliki na jakimś prywatnym repo, dodatkowo wypadałoby mieć subdomenę na której testujemy funkcjonalności, jak wszystko działa przesyłasz na domenę podstawową, w ten sposób nie ma przypału

Dobry pomysł, ale nadal nie rozumiem jak wgrać moje zmiany z serwerem produkcyjnym, czy to podstawowym czy na osobnej subdomenie? Dobrze to opisałem wcześniej? Czyli najpierw z lokalnego na np. github przez git, i potem z githuba na serwer produkcyjny poprzez git zainstalowany na serwerze?
A może jakoś bezpośrednio z PC na serwer da się? Szukam po prostu najlepszego rozwiązania, bo wiem że pewnie da się to zrobić na wiele sposóbów, ale ja chcę ten najczęściej prakykowany, a nie jakiś mój wymysł który będę powielał przez następne 5 lat "bo działa" ;)

0

zasadniczo jak sam robisz to pewnie starczyłoby local->bitbucket->subdomena/domena

0

Witaj, jesli chcesz przerzucic pliki produkcyjne z komputera na serwer bez programu ftp to mozesz uzyc tego: gulp-sftp

0
czysteskarpety napisał(a):

zasadniczo jak sam robisz to pewnie starczyłoby local->bitbucket->subdomena/domena

Poczytałem i wychodzi na to że bitbucket to po prostu alternatywa githuba, a zasada działania taka sama. Więc możesz rozwinąć co masz na myśli mówiąc local->bitbucket->subdomena/domena? Dokładnie to co opisałem wcześniej, czy jednak z butbucketem to jakoś inaczej się rozwiązuje?

0

Prawdopodobnie chodzilo mu o to ze piszesz apke lokalnie, nastepnie commitujesz zmiany i wrzucasz do repo, nastepnie robisz builda i przesylasz wszystko na stage server jestli wszystko smiga i nie masz zastrzezen to przerzucasz to wszystko na produkcje

1 użytkowników online, w tym zalogowanych: 0, gości: 1