Ticketa каза:
Тоест да разбирам, че се ползват два различни сървъра (тестов 127.0.0.1 и реален 127.0.0.2(примерно)) с клонирани файлове едно към едно, едни и същи бази от данни , едни и същи параметри.
Когато се надгражда/променя се работи по тестовия (127.0.0.1) и след това когато е приключена работата се пуска всичко за синхронизиране?
Как става синхронизирането , така че да не рефлектира (грешки) на реалната среда?
Как се разбира кое е коригирано например и този процес да стане автоматизиран? Диплоя или както е то ли прави цялата въртележка (синхронизация) или съм в грешка?
Разбира се, че отделни сървъри. Не може да имаш 2 сървъра споделящи ресурси, освен ако не те интересува производителността.
Базите данни, при нас лично, са също на отделни сървъри. Мастъра и слейва са отделни сървъри.
По принцип се работи на твоята локална машина. Тестовия сървър е именно за тестване. След като се оправят няколко бъга, добавени са няколко фичъра, всичко това минава през ревю и ако се одобри кода, се мърджва в един бранч (при нас се води develop) и този бранч (е не точно този, но нямам намерение да изписвам книги обяснения) се деплойва към тестовата среда. Оттам тестърите си вършат работата.
Деплоя не прави синхронизация между тестова и реална среда. Както казах в предния пост, деплойъра има длъжността да знае кой бранч/таг да пулне и да качи на сървъра. Този бранч, когато е готов да ходи в реалната среда, не се пипа повече - т.е. няма как да имаш разлики в кода.
Същото е с базата данни. Правят се миграции и според зависи какво ползва фирмата ви, деплойъра е длъжен да пусне миграциите.
При нас деплойъра прави доста неща, изпълнява npm install, composer install, създава entity proxy-та за Доктрин и още много други неща.
Това обмисляме да го променим с docker swarm или kubernetes, където се правят готови пакети и се деплойват към докер без downtime.
Синхронизация се прави на базата данни, но не толкова често. В случай, че тестовата среда изостава прекалено много, тогава ръчно си правим синхронизацията + анонимизираме потребителски данни.