CJRoman а можно чуть подробнее вы используете swagger, добавляете новые методы но при этом не пишете ApiDocumentation и не подерживаете в актуальном состоянии?
*так выходит из вашего ответа
тут проблема слегка не техническая: а скорее организационная.
для решения :
1 заставить писать ApiDocumentation и поддерживать в актуальном состоянии. (+0.5 - 1 ч к работе над задачей)
2 заставить писать тесты, покрытие 90и более % для api очень желательно
3 пинать менеджера проекта (этож не Вы?) чтобы вёл актуальную документацию
Сами пишем в похожем стеэке : ROR + Angular/Ember/React - запрос к /api/documentation выгружает json c swagger определением :
{"swagger":"2.0","info":{"version":"1.0","title":"Satyr","description":"Service for.....", "termsOfService" .... }
Фронт/мобил залез глянул что изменилось - поправил.
А вот если Бэк раздолбаи - то тут пара пятничных/понедельничных совещаний с мозгопромывкой, что до сихпорт не отдал Апи фронту помогут_) или Вам придётся искать нового бэка ))
w_b_x
Во первых: Какую задачу вы решаете данным запросом? может сам запрос не верен?
Если Вам надо вывести под пользователем 3, что он обрался с 1 и от него был полсдений ответ - зачем вы это перекладываете в БД ? почему не одной строкой в бэке (при созданиии ответа) или во фронте?
Иван Николаевич: печально, хотя я всё ещё вижу бесплтаный вариант,
c дрйгой стороны, аккаунт старый, но на новый: Full refund if you don’t love it within 30 days. - это Вас сильно смутило ?
Иван Артамонов: с ДНС есть проблема если тестировщики внешние и у них ip не постоянные.
На самом деле нет проблемы в локальной разработке, крути и делай что хочет - весь код всё равно проходит через test сервер и/или staging, рельсы вон по умолчанию локально отлично работают и отлаживаются.
Иван, не понял про сисадмина - а зачем им Вам быть?
В принципе всё реализуется скриптами запущенными по крону или через jenkins при деплое.
надо только определиться, что и как нужно:
1 сделать сборку для дев сервера (со всеми нужными хостами для разработки) те для каждого разработчика свой вирт сервер с настроенными хостами и 4 уровенем url
2 собрать выкатку на тест:
2.1 отдельной ветки [branch].service1.company.com
2.2 RC для [rc-branch].service1.company.com (c группой веток из 2.1)
2.3 выкатку на staging/pre-prod c полубоевой БД [staging].service1.company.com
и да Вам скорее всего нужен Админ ) часов на +/- 8-40 (при наличии расписанных хотелок ) для формирования системы разработки, и конечно разрешение сверху :)
а да и не забываем про БД :
- для дева (в принципе всем разрабам достаточно одной, хотя тут есть нюансы если добавляется новый функционал который зависит от БД или удаляются данные - один сломал, остальные бамбук курят)
- для стэйджа (обезличенную прода, для тестов на нагрузку и объёмы)
Про кэши, рэбиты и тп - всё же это тоже дублируем для каждого
AlexanderY: тогда что делать в ситуации когда на staging выкачен текущий релиз и его активно гоняет тест команда? а задачу с платежами надо делать и отлаживать.
не надо трогать staging оно вообще отдельно от dev сервера существует.
А один общий дев более чем на 2х программистов - по опыту, не рабочий вариант.
Илья: А при чём тут git то ? это же схема деплоя по сути, а не разработки-отладки
Иван Артамонов описанная Илья схема потребует введения в работу, к примеру Jenkins,
и вся работа будет строиться примерно так:
1 разработчик делает локально задачу, запиливает её в кокретной ветке
2 разработчик сдаёт её в тестирование
3 тестировщик в Jenkins выбирает ветку и сервер (или сервис) куда её выкатить
4 Jenkins выкатывает ветку на сервер, параллельно создавая субдомен [branch].service1.company.com или [branch].company.com
5 тестируется
6 прошло тест - ветка вливается в текущий релиз
7 ветка [branch] , субдомен и все зависимости убиваются тем же Jenkins
Тут правда есть пара моментов:
1 надо следить за зависимостями тк при деплоее [branch] на company.com он куда будет смотреть в [branch].service1.company.com или в [branch-old].service1.company.com
2 при удалени ветки и субдомменов - надо так же следить за зависимостями сервисов
Но по идее всё это решается на стадии внедрения и 1 раз )
xtreme по порядку
1 корпоративный ящик на yandex
2 стукрутра такая
info@example.ru -> meneger@example.ru
| ->support@example.ru
| -> vasia@examle.ru
и вот на этого vasia@examle.ru - яндекс ругается и просит исключить его из рассылки - так как он зафильтровал письма в спам.
Но двум другим письма нужны)
проблема скорее социальная, чем техническая, но тем не менее существует (
xtreme а если пользователь получает почту переадресацией с основного ящика на свой и у него письма попадают в спам? Но при этом от отписываться не желает - как быть в таком случае ?
пример корпоративный ящик с которого собирает несколько сотрудников.
У мандрила бывают заскоки) если спам рейт держится в пределах 2-3 процента в течении месяца - им проще забанить ваш аккаунт чем разбираться с чего это у Вас такой дикий рейт)
а в рейт может нагадить спам оборона яндекса - при отсутствии обратной записи, к примеру)
Уверены что фрилансер (человек ) работающий по договору ГПХ - не работник, а кто же он тогда ?
У договора гражданско-правового характера есть некоторые отличия от трудового договора , хотя один в другой можно переквалифицировать.
>>Заключая договор ГПХ, работодатель не делает никаких записей в трудовой книжке работника. Тем не менее, период работы по договору ГПХ, предметом которого является выполнение работ или оказание услуг, включается в страховой стаж, дающий право на трудовую пенсию по старости (п. 8 Правил подсчета и подтверждения страхового стажа для установления трудовой пенсии, утв. Постановлением Правительства РФ от 2.07.2002 № 555).
>>Продолжительность периода работы, который включается в страховой стаж, определяется по сроку действия договора ГПХ.
Трудность в том, что shared хостинг, хостнг древний и стоит жоская смесь из разных сайтов, версий WP и лагинов к нему.
Сейчас техподдержка смотрит, что там и как.
Браузеры — всё почищено.
Благо пресс ставился руками. Походу дела только один путь — сносить, ребутаться и ставить самую посленюю версию. не понятно откуда он высасывает данные, если на диске всё чисто.
Плагины кэширующие деативированны.
да есть Плагин. но он деактивирован.
Файлы темы на диске чистые, раза 3 проверил. Походу дела что-то в памяти. НЕ понятно можно ли вообще вычистить, или придется уничтожить всё на диске и заново ставить.
Для обоих доменов включены множественные входы?
вошли сначала в gmail основной, потом в gmail второй через войти в другой акк, и поставили галочки оставаться в системе?
Может заходили в какие-то не поддерживаем множественным входом сервисы?
