Jakiś przewonik po deploymencie?

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...

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ś.

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ć.

0

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

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.

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.

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.

4

Kurcze, nie wiem z czym masz problem.

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

Odpowiedź:

http://marcelog.github.io/articles/ci_jenkins_hudson_continuous_integration_php_phing.html
https://modess.io/continuous-integration-for-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ć.

0

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

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.

0

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

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