Как работите в екип ? Как работите с dev и real среда?
- Автор Ticketa
- Начална дата
Тестовата и реалната среда не трябва да имат разлики. Може да има разлика в брой сървъри, но цялостната конфигурация на сървърите трябва да е задължително еднаква.
Ако реалната среда има много сървъри, които обработват заявки чрез load balancer, то тестовата ти тогава трябва да има поне 2 сървъра, които отново минават през load balancer.
Ние имахме проблеми с нашите сървъри, които след доста дълъг период осъзнахме, че самата конфигурация е била различна. Не бяхме забелязали докато не опряхме до проблем, който работеше в реалната среда, но не и на тестовата.
Та от тука може да си направиш равносметка защо двете среди трябва да са еднакви.
Съвет: никога, ама никога не работи директно в реалната среда. Можеш да омажеш нещата сериозно и оправянето след това ще е трудно.
Работата директно в реална среда няма нито един плюс!
Ние използваме capistrano и Jenkins за деплойване за всяка една среда. Всичко, което с екипа правим си стои в github. Всеки един feature/bugfix/hotfix си е в отделен бранч, който след това се пуска като PR. PR-те съответно се мърджват в release branch и този release branch се деплойва към съответната среда. Лично за нас Gitflow Workflow работи добре.
Предимството да използваш deployer е, че може да пази backup-и и в момента, в който нещо фейлне, винаги може да се rollback-не - fail-proof.
Ако реалната среда има много сървъри, които обработват заявки чрез load balancer, то тестовата ти тогава трябва да има поне 2 сървъра, които отново минават през load balancer.
Ние имахме проблеми с нашите сървъри, които след доста дълъг период осъзнахме, че самата конфигурация е била различна. Не бяхме забелязали докато не опряхме до проблем, който работеше в реалната среда, но не и на тестовата.
Та от тука може да си направиш равносметка защо двете среди трябва да са еднакви.
Съвет: никога, ама никога не работи директно в реалната среда. Можеш да омажеш нещата сериозно и оправянето след това ще е трудно.
Работата директно в реална среда няма нито един плюс!
Ние използваме capistrano и Jenkins за деплойване за всяка една среда. Всичко, което с екипа правим си стои в github. Всеки един feature/bugfix/hotfix си е в отделен бранч, който след това се пуска като PR. PR-те съответно се мърджват в release branch и този release branch се деплойва към съответната среда. Лично за нас Gitflow Workflow работи добре.
Предимството да използваш deployer е, че може да пази backup-и и в момента, в който нещо фейлне, винаги може да се rollback-не - fail-proof.
dakata__92
Super Moderator
Тестовата и реалната среда трябва да са еднакви (идентични). Най-малкото, ако всичко върви гладко при изграждането на софтуера можете директно да направите синхронизация между тестовата и реалната среда, като така, когато кодът Ви е готов с една команда го прехвърляте на публичната версия. Наистина е важно да имате коректна тестова среда. Така ще избегнете безброй дребни спънки.
Ticketa
Registered
Тоест да разбирам, че се ползват два различни сървъра (тестов 127.0.0.1 и реален 127.0.0.2(примерно)) с клонирани файлове едно към едно, едни и същи бази от данни , едни и същи параметри.
Когато се надгражда/променя се работи по тестовия (127.0.0.1) и след това когато е приключена работата се пуска всичко за синхронизиране?
Как става синхронизирането , така че да не рефлектира (грешки) на реалната среда?
Как се разбира кое е коригирано например и този процес да стане автоматизиран? Диплоя или както е то ли прави цялата въртележка (синхронизация) или съм в грешка?
Когато се надгражда/променя се работи по тестовия (127.0.0.1) и след това когато е приключена работата се пуска всичко за синхронизиране?
Как става синхронизирането , така че да не рефлектира (грешки) на реалната среда?
Как се разбира кое е коригирано например и този процес да стане автоматизиран? Диплоя или както е то ли прави цялата въртележка (синхронизация) или съм в грешка?
dakata__92
Super Moderator
Ticketa каза:
При нас системния администратор си конфигурира нещата. MySQL-а може да бъде направен синхронен само в едната посока (от публичната версия към тестовата среда). Принципно базата с данни си я синхронизираме ръчно за да не повлияем на публичната версия на приложението. Файловете ги прехвърляме посредством команда за синхронизация от тестовата среда към публичната версия. При нас това е много ефективно. Всички работим на тестовата среда и създаваме една обща версия между локалните ни данни и тези на тестовия сървър. От там след тестване на модулите посредством команда на публичния сървър той се синхронизира с тестовата среда. Тестваме на за някакви несъответствия и сме готови. Основният проблем е ако някой без да иска синхронизира публичния сървър с тестовия.
Ticketa каза:
Разбира се, че отделни сървъри. Не може да имаш 2 сървъра споделящи ресурси, освен ако не те интересува производителността.
Базите данни, при нас лично, са също на отделни сървъри. Мастъра и слейва са отделни сървъри.
По принцип се работи на твоята локална машина. Тестовия сървър е именно за тестване. След като се оправят няколко бъга, добавени са няколко фичъра, всичко това минава през ревю и ако се одобри кода, се мърджва в един бранч (при нас се води develop) и този бранч (е не точно този, но нямам намерение да изписвам книги обяснения) се деплойва към тестовата среда. Оттам тестърите си вършат работата.
Деплоя не прави синхронизация между тестова и реална среда. Както казах в предния пост, деплойъра има длъжността да знае кой бранч/таг да пулне и да качи на сървъра. Този бранч, когато е готов да ходи в реалната среда, не се пипа повече - т.е. няма как да имаш разлики в кода.
Същото е с базата данни. Правят се миграции и според зависи какво ползва фирмата ви, деплойъра е длъжен да пусне миграциите.
При нас деплойъра прави доста неща, изпълнява npm install, composer install, създава entity proxy-та за Доктрин и още много други неща.
Това обмисляме да го променим с docker swarm или kubernetes, където се правят готови пакети и се деплойват към докер без downtime.
Синхронизация се прави на базата данни, но не толкова често. В случай, че тестовата среда изостава прекалено много, тогава ръчно си правим синхронизацията + анонимизираме потребителски данни.