Witaj Gościu! ( Zaloguj | Rejestruj )

Forum PHP.pl

 
Reply to this topicStart new topic
> Poprawne praktyki przy programowaniu serwisu, git, npm, gulp, composer itp
nyfko
post 25.10.2017, 20:50:36
Post #1





Grupa: Zarejestrowani
Postów: 17
Pomógł: 0
Dołączył: 29.07.2014

Ostrzeżenie: (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.


1. Czy tak to powinno wyglądać? Czy jeszcze jakiegoś podstawowego narzędzia brakuje?
2. 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?
3. 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
Go to the top of the page
+Quote Post
gitbejbe
post 27.10.2017, 04:54:06
Post #2





Grupa: Zarejestrowani
Postów: 515
Pomógł: 63
Dołączył: 27.08.2012

Ostrzeżenie: (0%)
-----


1. bardzo dobrze że nie pracujesz już tylko przez ftp bo to bez sensu
2. za npm i gulpa bardzo duży +, tak się teraz pracuje i sam widzisz jak to ułatwia temat
4. composer to samo

do php'a naucz się dowolnego frameworka - to nic strasznego, a wręcz przeciwnie. Skoro nie bałeś się npm'a to szybko się przekonasz że frameworki php to bardzo duży strzał jakości i szybkości Twojej pracy. Jaki na początek ? Bardzo dużo osób zaczyna chociażby od Codeignitera - w tym również ja, bo jest mega łatwy do ogarnięcia i ma bardzo dobrą dokumentacje w tym również po Polsku. Może też być dowolnie inny, zacznij od czegokolwiek a odkryjesz zupełnie nową jakość pisania kodu.

Co dalej:

1. Tak, zawsze
2. Na serwer produkcyjny wrzucasz ZAWSZE TYLKO działającą wersje programu
3. Nie musisz aktualizować serwera poprzez repozytorium, chociaż też jest to rozwiązanie. Ja zawsze wersje produkcyjną wrzucam zwyczajnie przez ftp - przecież nie robi się tego codziennie. Można to zautomatyzować na wiele sposobów, najprościej i najbezpieczniej jednak wg mnie jest to robić ręcznie.
4. Po co masz kompilować pliki na serwerze ? Przecież od tego masz serwer lokalny. Tak jak w pkt 1. na serwer produkcyjny wrzucasz już tylko gotowe pliki. Folder npm_modules ma działać tylko na serwerze lokalnym, nie wrzucaj go na produkcje i też wyklucz ten folder z z GIT'a poprzez plik .gitignores.
5. tak jak wyżej. Na serwerze produkcyjnym pod żadnym pozorem nie kompilujesz bibliotek , nie robisz aktualizacji compozera oraz npm'a exclamation.gif! Co jak po aktualizacji strona przestanie działać prawidłowo ? Od tego masz serwer lokalny.

Co do GIT'a. Z początku konsola odpycha, do tej pory nie lubię z niej korzystać ale nie ma biedy bo jest już wiele fajnych GUI. Polecam Ci program "sourceTree". Zarejestruj konto na bitbucket. Na githubie prywatne repozytoria są płatne, na bitbucket masz za darmo do pewnej ilości - chyba do 10 repozytoriów. Ja pracuje głównie w pojedynkę i bez gita nie wyobrażam sobie pracy. Nie zadawaj sobie pytania po co mi to, tylko uwierz że skoro każdy szanujący się programista tego używa to coś w tym musi być. Korzystanie z systemu kontroli wersji niesie z sobą tylko same plusy i nie ma co się tutaj nad tym rozwodzić, po prostu zacznij stosować a się przekonasz. Zapoznaj się też z terminem "gitflow", program sourceTree ma fajne wsparcie dla tego modelu.

Ten post edytował gitbejbe 27.10.2017, 04:58:09
Go to the top of the page
+Quote Post
nospor
post 27.10.2017, 07:20:32
Post #3





Grupa: Moderatorzy
Postów: 36 440
Pomógł: 6290
Dołączył: 27.12.2004




Cytat
Ja zawsze wersje produkcyjną wrzucam zwyczajnie przez ftp - przecież nie robi się tego codziennie.
W duzych zespolach i duzych projektach to wrzuca sie nawet co pol godziny.

Cytat
najprościej i najbezpieczniej jednak wg mnie jest to robić ręcznie.
No wlasnie nie. Taki proces sie automatyzuje, sprawdza czy dziala poprawnie a potem tylko klikasz czerwony guzik i wszystko samo leci z zautomatu a ty sie nie zastanawaisz czy zapomniales moze skopiowac to a moze tamto

Cytat
tak jak wyżej. Na serwerze produkcyjnym pod żadnym pozorem nie kompilujesz bibliotek , nie robisz aktualizacji compozera oraz npm'a exclamation.gif! Co jak po aktualizacji strona przestanie działać prawidłowo ? Od tego masz serwer lokalny.
Od tego to masz composer.lock by byly tam juz przetestowane pakiety. composer install na serwerze jak najbardziej ok. Zeby zabezpieczyc proces, to najpierw sie to robi w oddzielnym katalogu a potem tylko przelacza wlasciwy katalog na ten dopiero co przygotowany. I juz. Jest cala masa rzeczy ktora to wszystko automatyzuje.

Cytat
Co do GIT'a. Z początku konsola odpycha, do tej pory nie lubię z niej korzystać ale nie ma biedy bo jest już wiele fajnych GUI.
Konsola to podstawa. Jedyne co odpycha to wlasnie te GUI wink.gif
Jak sobie wyobrazasz prace z GIT na serwerze? Tylko konsola. A predzej czy pozniej bedziesz musial cos sprawdzic na serwerze wiec umiejetnosc poruszania sie w tej przepieknej konsoli to podstawa


--------------------

"Myśl, myśl, myśl..." - Kubuś Puchatek || "Manual, manual, manual..." - Kubuś Programista
"Szukaj, szukaj, szukaj..." - Kubuś Odkrywca || "Debuguj, debuguj, debuguj..." - Kubuś Developer

Go to the top of the page
+Quote Post
Pyton_000
post 27.10.2017, 07:45:19
Post #4





Grupa: Zarejestrowani
Postów: 8 068
Pomógł: 1414
Dołączył: 26.10.2005

Ostrzeżenie: (0%)
-----


Generalnie to...
- Pakiety Composer instaluje się ju na serwerze na podstawie composer.lock (composer install). Robi się to dla tego że zależności potrafią swoje ważyć. Oczywiście można by było wpakować cały `vendor` do repozytorium ale nie widzę sensu.

- Kompilacje assetów wykonuje się już na etapie przygotowania Release lub Hotfix i do repozytorium lecą już skompilowane wersje JS i CSS a dodatkowo zminimalizowane itd. Nie wrzuca się katalogu `npm_modules` bo on zawiera w sobie 98257823745698237698346 plików. Nie ma sensu bo to w sumie tylko na etapie projektowania jest potrzebne.

- GIT - Wpierw konsola, potem GUI. Niestety ale ucząc się GUI nie zawsze wszystko da się zrobić. Ja np. z GUI używam tylko Merge w PHPStorm. Wcześniej Meld. Ale to jest jedyny przypadek gdzie to faktycznie ułatwia. Oczywiście jeśli jesteś sam lub nawet 2-3 osoby to GUI styknie w zupełności.

- Deployment. Jest zasada w świecie DevOps że jeśli podczas Deploymentu musisz wykonać więcej niż 1 krok - zautomatyzuj to. Może być to cokolwiek począwszy od prostego skryptu w Bash, Envoy po Ansible, aż do CD. Release przez FTP to chyba najgorszy możliwy przypadek (no chyba że jest shared hosting i nic innego nie zadziała to wtedy przykro mi, lepiej zmienić serwer wink.gif )

Go to the top of the page
+Quote Post
nospor
post 27.10.2017, 08:23:38
Post #5





Grupa: Moderatorzy
Postów: 36 440
Pomógł: 6290
Dołączył: 27.12.2004




Cytat
Oczywiście jeśli jesteś sam lub nawet 2-3 osoby to GUI styknie w zupełności.
No nie rob im krzywdy takim czyms...
Ja kiedys dawno dawno temu, gdy uzywalem jeszcze SVN to siedzialem na samym GUI. Potem przyszlo mi cos zrobic na serwerze z SVN i zonk, nie znalem komend. GUI rozleniwia i uwstecznia. Konsole musisz znac bo predzej czy pozniej bedziesz musial cos zrobic na serwerze i bedziesz godzine szukal jak to zrobic poprawnie. A jak lokalnie bedziesz sie bawil w konsoli to i na serwerze nie odczujesz ze siedzisz na serwerze. Odkad uzywam GIT ani razu nie uzylem GUI a komendy GIT to pestka. Nie boje sie rowniez szalec po serwerze bo wiem co pisze.


--------------------

"Myśl, myśl, myśl..." - Kubuś Puchatek || "Manual, manual, manual..." - Kubuś Programista
"Szukaj, szukaj, szukaj..." - Kubuś Odkrywca || "Debuguj, debuguj, debuguj..." - Kubuś Developer

Go to the top of the page
+Quote Post
Pyton_000
post 27.10.2017, 08:31:51
Post #6





Grupa: Zarejestrowani
Postów: 8 068
Pomógł: 1414
Dołączył: 26.10.2005

Ostrzeżenie: (0%)
-----


Konsola GIT to podsawa. Jak jeszcze masz fajne aliasy porobione to praca staje się szybka i lekka.
Go to the top of the page
+Quote Post
nospor
post 27.10.2017, 08:32:32
Post #7





Grupa: Moderatorzy
Postów: 36 440
Pomógł: 6290
Dołączył: 27.12.2004




Cytat
Jak jeszcze masz fajne aliasy porobione to praca staje się szybka i lekka.
No ba wink.gif


--------------------

"Myśl, myśl, myśl..." - Kubuś Puchatek || "Manual, manual, manual..." - Kubuś Programista
"Szukaj, szukaj, szukaj..." - Kubuś Odkrywca || "Debuguj, debuguj, debuguj..." - Kubuś Developer

Go to the top of the page
+Quote Post
gitbejbe
post 27.10.2017, 10:11:32
Post #8





Grupa: Zarejestrowani
Postów: 515
Pomógł: 63
Dołączył: 27.08.2012

Ostrzeżenie: (0%)
-----


Stety czy niestety ale nie miałem tej przyjemności pracowania w dużym zespole (góra 3 osoby), wiec być może moja odpowiedź jest tą którą na ten moment oczekuje również samotny developer, nie mniej jednak domyślam się że moja praca zapewne odbiega od technik pracy zespołowej i oczywiście chylę czoła nad waszym doświadczeniem w tym temacie : ) Autor tematu ma za to merytoryczną rozmowę. Również z chęcią poczytam
Go to the top of the page
+Quote Post
Pyton_000
post 27.10.2017, 10:21:56
Post #9





Grupa: Zarejestrowani
Postów: 8 068
Pomógł: 1414
Dołączył: 26.10.2005

Ostrzeżenie: (0%)
-----


Tak nadmienię jeszcze na temat GitFlow. Nie zawsze sprawdza się ten sposób pracy. Dużo tez zależy jak jest zorganizowana praca w firmie i jak robiony jest np. deployment.

Z GitFlow jest jak ze Scrumem. Jesli wprowadzisz wszystko na raz to katastrofa gotowa. Najpierw dobrze jest nauczyć się jak się pracuje z branchami, merche, cherry-pick itd. dopiero potem można zaczynać pracować w systemie 1 feature = 1 brach z develop. Jak jest 100% gotowy to merge do develop. Potem ew. poprawki i można robić merge na master a to już ost. krok do prod.

Oczywiście wiele ludzi powie że jak to tak. Ano tak, przy bardzo małch produktach sprawdza się do spoko. Każdy może wypracować swoje własne metodologie pracy z projektem, gitFlow jest tylko wskazaniem na rozwiązywanie pewnych problemów.
Go to the top of the page
+Quote Post
markuz
post 27.10.2017, 11:29:44
Post #10





Grupa: Zarejestrowani
Postów: 1 240
Pomógł: 278
Dołączył: 11.03.2008

Ostrzeżenie: (0%)
-----


Ja używam GIT nawet jak piszę sam, dzięki czemu wiem które pliki zmieniłem w danej "sesji programowania" - jak mnie poniesie "flow" to mogę wrócić do stanu poprzedniego, działającego systemu.


--------------------
Go to the top of the page
+Quote Post
nyfko
post 27.10.2017, 13:12:05
Post #11





Grupa: Zarejestrowani
Postów: 17
Pomógł: 0
Dołączył: 29.07.2014

Ostrzeżenie: (0%)
-----


Bardzo dziękuje za konkretne odpowiedzi wink.gif

Tak więc jednak nie wrzucać przez FTP - to więc w jaki sposób polecacie? Tak jak pisałem wcześniej, czyli najpierw na np. github (bitbucket czy inny host gita) a z niego na serwer? Jak Wy to robicie?

Rozumiem że dla współdzielonego prostego hostingu pozostaje tylko FTP, ale załóżmy np. że dla danego projektu wynająłem VPS czy serwer dedykowany z dostępem roota. Jakie mam wtedy opcje?
Go to the top of the page
+Quote Post
Pyton_000
post 27.10.2017, 13:30:06
Post #12





Grupa: Zarejestrowani
Postów: 8 068
Pomógł: 1414
Dołączył: 26.10.2005

Ostrzeżenie: (0%)
-----


dla PHP np. Deployer, Rocketer
Go to the top of the page
+Quote Post
trzczy
post 7.11.2017, 19:55:59
Post #13





Grupa: Zarejestrowani
Postów: 460
Pomógł: 49
Dołączył: 5.06.2011

Ostrzeżenie: (0%)
-----


Cytat(nyfko @ 27.10.2017, 13:12:05 ) *
Rozumiem że dla współdzielonego prostego hostingu pozostaje tylko FTP

Niekoniecznie. Warto to sprawdzić u hostingodawcy. Kiedyś miałem najtańszą taryfę na linux.pl i tam był ssh.

edit: na linuxpl.com
Go to the top of the page
+Quote Post

Reply to this topicStart new topic
1 Użytkowników czyta ten temat (1 Gości i 0 Anonimowych użytkowników)
0 Zarejestrowanych:

 



RSS Wersja Lo-Fi Aktualny czas: 29.03.2024 - 10:28