По поводу конфликтов у нас сделано просто благодаря той самой автоматизации. если автомерж не смог залить какую-то ветку в билд, то задаче выставляется специальный флаг в Jira чтобы предотвратить дальнейшие попытки автомержа и с AIDA переводится обратно на разработчика с комментарием что в такой-то билд её не удалось замержить.
А зачем разработчику мержить себе в ветку релиз, если он через 4 часа всё равно будет в мастере? Если есть какая-то зависимость между задачами, то можно замержить отдельную задачу, это намного безопаснее.
Честно говоря не знаю, как у нас биллинг считается, но в BI используют специализированные базы. Но после одного успешного применения judy уже разные команды начали думать как им это расширение может помочь.
Но только это будет не просто массив на 100k записей, а массив из массивов по count(columns) — так что уже стоит попробовать judy. Но это всё так, just for fun, мы не такие задачи с помощью judy решаем.
В какой-то момент для одной из бизнес задач нам потребовалась графовая база данных. Данные в неё нужно было как-то загружать, а при нашем масштабе данных было иногда мало, а иногда очень много, порядка озвученных 100k-1M. В основном это нужно было для того, чтобы не загружать в C-сервис уже имеющиеся в нём данные, потому каждая часть графа собиралась предварительно в PHP и в ней исключались дублирующиеся связи.
2. В Confluence у нас хранится документация и подготавливаются PRD по функционалу со стороны Product Team. Описания обновлений у нас рассылаются в maillist при каждом деплое, обновлении версий мобильных приложений и раз в неделю рассылается сводка по всем отделам.
Как тогда проверить какой-либо функционал, который использует записи в базе?
Ну так ведь
Как было сказано ранее, сначала задачи тестируются на девел-серверах
А если какая-то фича ещё не введена, то обычно её сначала включают для разработчиков, потом для всех сотрудников, потом для фокус-группы. Ничего лишнего простой пользователь увидеть не должен. Это, в том числе, позволяет не делать очень долгоживущие ветки — можно релизить частями.
Так как для нас «master branch — копия продакшена», то да, если это действительно хотфикс — то выкладывается сразу разработчиком и коммитится в мастер релиз-инженером. Но есть и нюансы, связанные с исправлением статики и шаблонов — для них нужен полноценный билд.
Вы уверены? Судя по ману и отзывам в сети, это поможет если делается несколько одновременных соединений. А тут обсуждается случай, когда идут последовательные соединения.
Ну так ведь
А если какая-то фича ещё не введена, то обычно её сначала включают для разработчиков, потом для всех сотрудников, потом для фокус-группы. Ничего лишнего простой пользователь увидеть не должен. Это, в том числе, позволяет не делать очень долгоживущие ветки — можно релизить частями.