Как работите в екип ? Как работите с dev и real среда?

Ticketa

Registered
По какъв начин се организирате , когато работите в екип ? Какви софтуери ползвате ? Задължително какъв е самия процес и разлика при тестова и реална среда? Аз лично работя в реална среда винаги , но това има доста минуси отколкото плюсове :naughty:
 
Ще е интересно някой да сподели професионален опит да сверя часовника.
 
Тестовата и реалната среда не трябва да имат разлики. Може да има разлика в брой сървъри, но цялостната конфигурация на сървърите трябва да е задължително еднаква.
Ако реалната среда има много сървъри, които обработват заявки чрез load balancer, то тестовата ти тогава трябва да има поне 2 сървъра, които отново минават през load balancer.

Ние имахме проблеми с нашите сървъри, които след доста дълъг период осъзнахме, че самата конфигурация е била различна. Не бяхме забелязали докато не опряхме до проблем, който работеше в реалната среда, но не и на тестовата.

Та от тука може да си направиш равносметка защо двете среди трябва да са еднакви.


Съвет: никога, ама никога не работи директно в реалната среда. Можеш да омажеш нещата сериозно и оправянето след това ще е трудно.
Работата директно в реална среда няма нито един плюс!

Ние използваме capistrano и Jenkins за деплойване за всяка една среда. Всичко, което с екипа правим си стои в github. Всеки един feature/bugfix/hotfix си е в отделен бранч, който след това се пуска като PR. PR-те съответно се мърджват в release branch и този release branch се деплойва към съответната среда. Лично за нас Gitflow Workflow работи добре.

Предимството да използваш deployer е, че може да пази backup-и и в момента, в който нещо фейлне, винаги може да се rollback-не - fail-proof.
 
Тестовата и реалната среда трябва да са еднакви (идентични). Най-малкото, ако всичко върви гладко при изграждането на софтуера можете директно да направите синхронизация между тестовата и реалната среда, като така, когато кодът Ви е готов с една команда го прехвърляте на публичната версия. Наистина е важно да имате коректна тестова среда. Така ще избегнете безброй дребни спънки.
 
Тоест да разбирам, че се ползват два различни сървъра (тестов 127.0.0.1 и реален 127.0.0.2(примерно)) с клонирани файлове едно към едно, едни и същи бази от данни , едни и същи параметри.

Когато се надгражда/променя се работи по тестовия (127.0.0.1) и след това когато е приключена работата се пуска всичко за синхронизиране?

Как става синхронизирането , така че да не рефлектира (грешки) на реалната среда?
Как се разбира кое е коригирано например и този процес да стане автоматизиран? Диплоя или както е то ли прави цялата въртележка (синхронизация) или съм в грешка?
 
Ticketa каза:
Тоест да разбирам, че се ползват два различни сървъра (тестов 127.0.0.1 и реален 127.0.0.2(примерно)) с клонирани файлове едно към едно, едни и същи бази от данни , едни и същи параметри.

Когато се надгражда/променя се работи по тестовия (127.0.0.1) и след това когато е приключена работата се пуска всичко за синхронизиране?

Как става синхронизирането , така че да не рефлектира (грешки) на реалната среда?
Как се разбира кое е коригирано например и този процес да стане автоматизиран? Диплоя или както е то ли прави цялата въртележка (синхронизация) или съм в грешка?

При нас системния администратор си конфигурира нещата. MySQL-а може да бъде направен синхронен само в едната посока (от публичната версия към тестовата среда). Принципно базата с данни си я синхронизираме ръчно за да не повлияем на публичната версия на приложението. Файловете ги прехвърляме посредством команда за синхронизация от тестовата среда към публичната версия. При нас това е много ефективно. Всички работим на тестовата среда и създаваме една обща версия между локалните ни данни и тези на тестовия сървър. От там след тестване на модулите посредством команда на публичния сървър той се синхронизира с тестовата среда. Тестваме на за някакви несъответствия и сме готови. Основният проблем е ако някой без да иска синхронизира публичния сървър с тестовия.
 
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.

Синхронизация се прави на базата данни, но не толкова често. В случай, че тестовата среда изостава прекалено много, тогава ръчно си правим синхронизацията + анонимизираме потребителски данни.
 

Горе