Workflow - testy, produkcja, git.

0

Cześć,
przychodzę do Was z pytaniem o dobre praktyki jeśli chodzi o worflow podczas zmian/tworzenia aplikacji.
W jaki sposób wprowadzacie zmiany w swoich projektach na wersjach beta, na gicie a finalnie na produkcji.
Sam zajmuje się głównie tematami webowymi i do tego się odniosę, jak to u mnie aktualnie wygląda podczas np aktualizacji kodu:

  1. Mam wersje lokalną strony, którą edytuje
  2. Wysyłam zmiany na serwer z wersją beta (pliki + baza)
  3. GIT PUSH
  4. Wysyłam zmiany na serwer produkcyjny (pliki + baza)

Przy dużych zmianach (wielu plików) ciężko określić, które dokładnie pliki edytowałem i po prostu robię upload całości z lokalnej wersji na serwery - co jest długotrwałe.
Przy małych zmianach - np jedna linijka w pliku przekopiowanie pliku na bete, gita i produkcje trwa razem z 15-20min, co oznacza, że sam upload zajmuje 15x więcej czasu niż dopisanie linijki.

Jak to u Was wygląda? Są na to lepsze/szybsze sposoby? Jak taki proces można zautomatyzować?

0

Przy dużych zmianach (wielu plików) ciężko określić, które dokładnie pliki edytowałem i po prostu robię upload całości z lokalnej wersji na serwery - co jest długotrwałe.
Przy małych zmianach - np jedna linijka w pliku przekopiowanie pliku na bete, gita i produkcje trwa razem z 15-20min, co oznacza, że sam upload zajmuje 15x więcej czasu niż dopisanie linijki.

Rozwiązanie masz już w tym zdaniu - git.

Mam jeden projekt, w którym jest lokalna wersja strony. Gdy stwierdzę, że już jest "ok", to robię git push, loguję się na serwerze i tam robię git pull. Wymaga oczywiście dostępu do SSH na serwerze, ale to ma zarówno mój hosting współdzielony, jak i moje VPS-y. I dla tego projektu nie ma żadnej automatyzacji ponad to. Zero martwienia się o upload.

W innym projekcie mam z kolei pewną automatyzację - korzystam z Azure Dev Ops (jest za darmo), gdzie po zrobieniu git push mam odpalany pipeline, który buduje projekt, loguje się na serwerze i tam odpala pewien skrypt, który robi git pull i uruchamia wersję beta. Jest też deployment pipeline, który czeka na ręczne kliknięcie "akceptuj" i robi to samo, ale na "produkcyjnej" domenie. Podobne rzeczy można robić w innych narzędziach CI/CD, typu Appveyor, Jenkins czy co tam innego.

Co do aktualizacji bazy danych to nie wiem o jakiej technologii mówisz, ale zainteresuj się koncepcją "migracji", które pozwalają wersjonować bazę danych.

0

Ale, że jak z ta bazą? A co jeśli userzy coś zmienią? To co mówisz zadziała tylko dla prostych stron wizytówek bez panelu admina.

0

Na git powinny być gałęzie dev od których idą gałęzie rozwojowe. Jakaś betę i proda. Poprzez merge robisz emisje na dana wersje a job Jenkins jest przez to wzbudzany, żeby na określonym serwerze puścić deploy i testy i potem może na trwało podmienić. Nic obecnie nie powinno robić się ręcznie. Bazę powinno zmieniać się migracjami jeśli technologia pozwala lub skryptami SQL które wprowadza zmiany, przepompują dane, zadbają o integralność. Jenkins Ofc testuje i pilnuje czy się udaje Ew. przywraca środowisko do stanu z backupy który robi na początku.

1

obecnie bitbucket oferuje pipeline nawet przez stare ftp, wtedy przy pushu automatycznie zmienia pliki na serwerze, do czegoś większego może vagrant, docker

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