Mam wrażenie, że u Was kuleje tak na prawdę cały proces i pojedyncza zmiana jest trudna bo nie potraficie jej wpasować w Wasz proces.
Rozwiązań jest tyle ilu programistów, ale akurat pracuje z jedna z technologii, którą macie do czynienia (Magento) więc pokrótce jak wygląda prosty proces dla małego zespołu.
Mamy branch master. Gdy programista podejmuje task to tworzy sobie feature-branch wychodząc z mastera i wprowadza swoje zmiany.
Jeśli potrzebne są zmiany w bazie to Magento ma dwa główne mechanizmy:
- declarative schema do zarządzania schemą bazy danych - czyli innymi słowy jeśli jakiś moduł ma wprowadzić zmiany w bazie danych to masz odpowiedni plik XML, w którym wprowadzasz zmiany i są one wywoływane na bazie w momencie wywołacani bin/magento setup:upgrade
- do zmian danych w bazie masz kolejne rozwiązanie czyli upgrade scripty/patche - za pomocą tego rozwiązania możesz wprowadzić dowolne zmiany w bazie - np. coś zaimportować, zmienić ustawienia itp.
Dzięki tym dwóm rozwiazanium możesz w trakcie deploymentu dokonać dowolnej migracji bazy danych na każdym środowisku - czy to developerskim czy produkcyjnym, dzięki czemu nie ma rozjazdów w bazie.
Kolejny ważny element to w naszym przypadku co jakiś okres czasu (u nas raz dziennie) robiony jest dump bazy z głównego środowiska i jest on odpowiedni przerabiany - usuwane są dane wrażliwe, logi etc i wrzucany na s3. Taki dump każdy może sobie w dowolnej chwili wgrać na lokalne środowisko, dzięki czemu jak coś napsuje w lokalnej bazie danych, albo np. coś zostanie zmienione ręcznie na głównym środowisku, to można sobie pobrać bieżącą wersję bazy. Wszystko odbywa się automatycznie - developer wpisuje 1 polecenie do synchronizacji bazy danych. Podobnie mamy z synchronizacją mediów. W przypadku dużych projektów czasami pipeliny stripują część danych/mediów, aby takie synchronizacje nie trwały zbyt długo, ale to już detal.
I teraz wracając do naszych feature branchy - jak developer uznaje, że jest on gotowy, wszystko przejdzie CR to tester może sobie zbudować środowisko testowe. Środowisko testowe buduje się automatycznie - pobiera wyżej wspomniany strip bazy danych i buduje dany branch na serwerze testowym, odpalane są wyżej wspomniane migracje. Gdy występują jakieś żadkie sytuacje, że trzeba coś ręcznie skonfigurować bo import byłby zbyt kłopotliwy to dodajemy odpowiednie pole w JIRZE z opisem deployu dla testera, ale to jest RZADKOŚĆ - nie pamiętam kiedy ostatnio miałem taką sytuację.
Jak tester przetestuje wszystko to leci MR do mastera - z reguły nie ma konfliktów, bo branche mają krótki cykl życia + często deployujemy na produkcję.
Oczywiście tak jak pisałem są inne strategie np. z branchem developerskim/stagingowym etc. Trzeba dobrać pod projekt. Ale kluczowe "take away"
- zamiast wgrywać zmiany przez FTP musicie mieć pipeliny potrafiące w każdej chwili zbudować projekt od zera z tego co jest w repozytorium - na początek polecam albo deployer.org (chyba najprostsze z możliwych narzędzi) albo gitlab pipelines / github actions. Tutaj można ogarnąć cały proces bardzo fajnie. Póki będziecie wgrywać zmiany przez FTP będzie burdel - tak już powoli nawet hindusi nie robią.
- koniecznie musicie używać migracji. W Magento masz cały mechanizm gotowy. W Prestashop o ile pamiętam też są migracje np. przy updajtach, więc pewnie ten mechanizm możecie wykorzystać. Nie wiem jak WP.
- środowiska developerskie powinny być spięte - np. szybka możliwość updajtu bazy danych, przetestowania builda etc - jak coś nie jest proste to ludzie tego nie robią. Myślę, że docker bardzo ułatwia ogarnięcie takich środowisk developerskich, więc jak nie stosujecie to warto zacząć.
Zbudowanie takiego procesu nie jest rzeczą prostą, zwłaszcza jak się nie pracowało wcześniej w podobnej metodologii, ale przy odrobinie ogarnięcia tematu jest do zrobienia.