Pomoc - Szukaj - Użytkownicy - Kalendarz
Pełna wersja: Poprawne praktyki przy programowaniu serwisu
Forum PHP.pl > Forum > Kontrola i zarządzanie projektami
nyfko
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
gitbejbe
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.
nospor
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
Pyton_000
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 )

nospor
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.
Pyton_000
Konsola GIT to podsawa. Jak jeszcze masz fajne aliasy porobione to praca staje się szybka i lekka.
nospor
Cytat
Jak jeszcze masz fajne aliasy porobione to praca staje się szybka i lekka.
No ba wink.gif
gitbejbe
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
Pyton_000
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.
markuz
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.
nyfko
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?
Pyton_000
dla PHP np. Deployer, Rocketer
trzczy
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
To jest wersja lo-fi głównej zawartości. Aby zobaczyć pełną wersję z większą zawartością, obrazkami i formatowaniem proszę kliknij tutaj.
Invision Power Board © 2001-2018 Invision Power Services, Inc.