Jakiś przewonik po deploymencie?

Odpowiedz Nowy wątek
Abażur świecący
2017-02-03 21:14
Abażur świecący
0

Szukam jakiegoś poradnika, który krok po kroku opisuje jak powinien wyglądać proces wytwarzania i wdrażania oprogramowania. Na ten moment mam podpięty netbeans do serwera testowego i po zrobieniu zmian i przetestowaniu przerzucam zedytowane pliki na produkcję. Z tego co widzę ostatnio ten proces się nieco zmienił, ale nie mogę znaleźć jednego konkretnego źródła wiedzy.
Chciałbym razem z kolegą pracować nad jednym projektem na serwerze testowym. Teraz po prostu sobie mówimy "nie ruszaj pliku panel.php... Dobra zmieniłem, pobierz go sobie". Brzmi lamersko. Umiem podpiąć sobie gita, ale pliki wysyłają się na serwer przy zapisywaniu pliku, a nie przy pushowaniu. Czy jest jakieś autopullowanie? Bez sensu tak zgadywać. Musi być jakiś jeden właściwy sposób, który został gdzieś opisany...

Pozostało 580 znaków

2017-02-03 21:33
Moderator

Rejestracja: 12 lat temu

Ostatnio: 4 minuty temu

Lokalizacja: Wrocław

0

Umiem podpiąć sobie gita, ale pliki wysyłają się na serwer przy zapisywaniu pliku, a nie przy pushowaniu.

Co to w ogóle znaczy? Przecież Git magicznie sam nic nie wysyła :P
Chyba że to sobie zainstalowałeś Gita, a o koledze i serwerze testowym zapomniałeś.


edytowany 2x, ostatnio: Patryk27, 2017-02-03 21:33

Pozostało 580 znaków

Abażur świecący
2017-02-04 11:32
Abażur świecący
0

Na razie chciałbym wiedzieć jak to powinno być zrobione. Przecież jak zainstaluje koledze gita to i tak będziemy sobie nadpisywać pliki na serwerze, a zdamy sobie z tego sprawę przy pushowaniu do githuba. Nie wiem jak się za to wszystko zabrać.

Pozostało 580 znaków

2017-02-04 12:07
Moderator

Rejestracja: 12 lat temu

Ostatnio: 4 godziny temu

Lokalizacja: Wrocław

0

Bo źródłem plików na serwerze ma być Git, a nie odwrotnie.


"HUMAN BEINGS MAKE LIFE SO INTERESTING. DO YOU KNOW, THAT IN A UNIVERSE SO FULL OF WONDERS, THEY HAVE MANAGED TO INVENT BOREDOM."

Pozostało 580 znaków

Pijany Orzeł
2017-02-04 13:27
Pijany Orzeł
0

Po prostu ustawiłeś sobie w IDE żeby przy commicie ten wysyłał pliki na serwer przez FTP.

Jak chcesz wrzucać pliki na serwer przez push do repo to musisz mieć odpowiednio skonfigurowane repozytorium na serwerze i/lub jakieś hooki w repo do którego pushujesz, które będą aktualizowały pliki na serwerze przy pushu.

Pozostało 580 znaków

Abażur świecący
2017-02-04 16:06
Abażur świecący
0

A jest to gdzieś wszystko ładnie opisane jako standardowy sposób? Wolę googlować, kiedy coś nie idzie zgodnie z planem, bo takie szukanie enigmatycznych terminów bez wcześniejszego zagłębienia w temacie nigdy mi na dobre nie wychodziło.

Pozostało 580 znaków

2017-02-04 16:34

Rejestracja: 5 lat temu

Ostatnio: 9 godzin temu

1

U mnie to wygląda na dwa sposoby:

Sposób pierwszy:

  1. push do repo
  2. weryfikacja
  3. Jenkins co X godzin buduje serwer i tu są pierwsze testy jeśli zadanie przejdzie weryfikacje
  4. jak jest gotowa paczka żeby poszła na produkcje to idzie ona na serwer testowy, który przypomina produkcje.
  5. jak wszystko działa na serwerze testowym to idzie na produkcje

Sposób drugi dla jednego projektu, który tworzę sam i nie mam problemu że coś się wysypie na produkcji.

  1. push do repo
  2. produkcja od razu się aktualizuje

Sposobu drugiego nie polecam jeśli nie możesz sobie pozwolić na błędy na produkcji. Jest to projekt hobbystyczny.

edytowany 1x, ostatnio: anonimowy, 2017-02-04 16:48
Pokaż pozostałe 3 komentarze
Jakie testy na głównej gałęzi? Ja mam budowę z głównej gałęzi. Nie mam budowy co commit bo commit czasem jest co pół godziny a budowa trwa ponad 10 minut i testerzy nie zdąża przetestować zadania nawet. Przy krótkiej budowie też to mało sensu by miało bo wbija sobie tester i testuje i nagle mu się kasuje wszystko co wprowadził do systemu bo projekt się buduje... - anonimowy 2017-02-04 18:31
Coś strasznie dziwny flow macie. Testy automatyczne są po to, by tester nie musiał siedzieć, a wy macie testera, by testy automatyczne nie musiały się odpalać? Coś tu mi nie bangla. Idea powinna być taka, że robisz commit (oczywiście w osobym branchu, najlepiej jeszcze w osobnym forku) i dopalają się testy jednostkowe. Następnie idzie Pull/Merge Request i odpalają się wszystkie testy, a dopiero wtedy aplikację do zabawy dostaje tester. Jak PR/MR przeszedł testy manualne i code review wtedy jest mergowany do gałęzi głównej, znów wszystkie testy się odpalają na CI -> deploy. - hauleth 2017-02-04 18:37
Moim zdaniem normalny. Testy to dla mnie testy manualne, testy automatyczne oczywiście są odpalane na każdym etapie (lokalnie i na CI). Nie bardzo rozumiem pracę na osobnych gałęziach skoro wszystko można robić wygodnie na defaulcie. - anonimowy 2017-02-04 18:42
@anonimowy z paru powodów: można łatwo śledzić rozwój funkcjonalności; każda nowa funkcjonalność jest odizolowana od reszty (jak testy się sypią, to wiesz, że przez Ciebie); zdecydowanie łatwiej rozwiązywać merge conflicts; oraz najważniejsze - to jest główna zaleta Gita nad SVNem, że Git jest rozproszonym systemem kontroli wersji. Używajmy tego rozproszenia a będzie się pracowało wygodniej. - hauleth 2017-02-04 18:50
Jak testy się sypią to znaczy, że ktoś nie włączył ich lokalnie a to się nie zdarza... Zawsze jak sypią się testy to jest znany powód i osoba. Merge confilct to żaden problem bo jest ich mało i rzadko. Zdecydowanie wolę to niż potem łączyć dwie gałęzie. Wygodniej mi pracuje się w ten sposób. - anonimowy 2017-02-04 18:58

Pozostało 580 znaków

2017-02-04 18:14

Rejestracja: 8 lat temu

Ostatnio: 6 godzin temu

4

Kurcze, nie wiem z czym masz problem.

Hasło: "php continuous development"
lub "php continuous integration"

Odpowiedź:


http://marcelog.github.io/art[...]us_integration_php_phing.html
https://modess.io/continuous-[...]laravel-with-jenkins-and-git/
https://modess.io/jenkins-php/


Podstawowe zasady:
https://dzone.com/articles/8-principles-continuous
https://www.infoq.com/articles/continuous-deployment-containers

Nie wiem o którą technologię chodzi, dla każdej zestaw narzędzi jest inny, zakładam że o PHP zgodnie z pierwszym postem.

W PHP-ie mocno nie siedzę, ale:

  • GIT w zasadzie aktualnie jest standardem do obsługi współdzielenia kodu i kontroli wersji
  • do przechowywania centralnego kodu możesz użyć GitHub
  • do budowania projektów z tego co wiem używa się Phing
  • jako serwer CI można zastosować Jenkins lub PHPCI: https://www.phptesting.org/
  • do kontroli jakości kodu użyj narzędzi wymienionych w ww artykule
  • do zarządzania zależnościami używasz Composer
  • na serwer powinieneś wrzucać kod przetestowany (automatycznie) - i tylko taki

Obejrzyj / przeczytaj to wszystko i daj znać jak planujesz to robić.


Szacuje się, że w Polsce brakuje 50 tys. programistów
edytowany 2x, ostatnio: vpiotr, 2017-02-04 18:29
Jeśli projekt FLOSS, to można użyć darmowego TravisCI. Jeśli nie to lepiej GitLaba + GitLab CI. - hauleth 2017-02-04 18:16

Pozostało 580 znaków

Abażur świecący
2017-02-07 15:20
Abażur świecący
0

Dzięki vpiotr. Tego hasła nie znałem.

Pozostało 580 znaków

2017-02-09 18:28
Administrator

Rejestracja: 18 lat temu

Ostatnio: 11 godzin temu

4

Napiszę jak to jest robione na 4programmers.net. A nuż ktoś będzie miał jakieś uwagi albo lepsze pomysły.

Kod jest pushowany na Github. Taka operacja automatycznie uruchamia:

  • statyczną analizę kodu (szukanie błędów w kodzie, zduplikowanego kodu, przypadkowo zakomentowanego kodu itp), w tym również zgodność kodu ze standardem (psr2)
  • uruchomienie testów na serwerze CI (Travis CI)
  • automatyczne wdrożenie kodu na serwerze testowym

Automatyczne wdrożenie polega na:

  • pociągnięciu nowej wersji kodu z github (do nowego katalogu - nie tego, pod którego aktualnie podpięta jest produkcja)
  • zaciągnięciu pakietów z composera
  • zaciągnięciu pakietów z npm
  • budowanie projektu: CSS, JS, minifikacja-
  • uruchomienie migracji bazy danych (dodanie kolumn/tabel jeżeli jest taka konieczność)
  • cachowanie

Jeżeli powyższe kroki będą ok (nie rzucą błędów), to katalog ze starym kodem zastępowany jest tym nowym.
Wdrożenie na produkcję jest podobne, ale nie jest to proces automatyczny.

Jeżeli chodzi o narzędzia do wdrażania to np. http://capistranorb.com/
Osobiście nie korzystałem, bo nie znam w ogóle Ruby.

Rzucam jeszcze pojęcia: continuous deployment, continuous delivery.

edytowany 1x, ostatnio: Adam Boduch, 2017-02-09 18:49

Pozostało 580 znaków

2017-02-10 09:36

Rejestracja: 17 lat temu

Ostatnio: 1 dzień temu

0

A ktoś ma podobne doświadczenia z desktopami albo hybrydami (web - desktop)?

To zależy od platformy, ale o ile się da to najlepiej używać sklepu do aplikacji lokalnej. Webowo to po prostu wersjonujesz API. - hauleth 2017-02-10 19:05

Pozostało 580 znaków

Odpowiedz

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