Это та нагрузка, которую мы достаточно долго получали во время недавних распродаж. Средняя за «совсем обычный день» будет поменьше, да.
Помимо запросов от пользователей, есть также и огромная офлайн часть компании: WMS (система управления складом), логистика и другие внутренние системы.
Нет, Warden - не монолит :) Он сам состоит уже из нескольких компонентов. Больше и сложнее он стал по сравнению с той самой первой версией, которую мы запустили в 20 году и которая умела работать только с кубером.
Этот процент близок к 100%, потому что в большинстве случаев у команд просто нет никакой альтернативы, да она в целом и не нужна: зачем пытаться самому создавать кластер базы или чего-то еще, если можно сделать пару кликов и получить тоже самое.
Но есть и несколько сервисов, которые появились незадолго до наших фреймворков. В этом случае команды используют какие-то отдельные компоненты из них. Но с ними мы тоже ведем работу по переходу на платформу целиком.
Inspection. Тут мы проверяем качество кода. Для php-проектов мы запускаем проверку на соответствие стандартам psr и юнит-тесты, а также измеряем покрытие тестами. Если проверка или тесты упали, то задача возвращается назад разработчику.
Review. Автоматически создаем pull request и отправляем тикет review`eру.
Build. Этап для создание тестовой сборки. Для php мы создаем тестовую площадку (про них ответил чуть ниже), для мобильных приложений собираем полноценный билд.
Testing. Непосредственно тестирование задачи.
Acceptance. На этом этапе заказчик должен подтвердить, что было сделано именно то, что он хотел. Мы используем это шаг для больших бизнез-фич сайта, в случае библиотек или внутренних инструментов он чаще всего проходит автоматически.
Integration. Мы используем gitflow и на этом этапе наступает именно тот момент, когда ветку с задачей нужно интегрировать в develop/master. На самом деле тут просто происходит merge pull request`a :)
Release. Релиз
Для каждого этапа в нашем флоу в jira существует 3 статуса:
Ready forstep
On step
stepfailed
Статусы stepcompleted не нужны, т.к. факт успешного прохождения одного этапа означает, что задача готова к следующему.
Статусов суммарно получается действительно много, но благодаря им мы в любой момент времени можем абсолютно точно сказать, что происходит с задачей. Все наши команды используют доски в джире и поэтому разработчикам нужно просто перетаскивать карточки из одной колонки в другую, а не думать над большим кол-вом статусов. Все, что можно сделать автоматически, за них сделает J.A.R.V.I.S.
Сейчас используем одну общую базу на все площадки. Все изменения в схемы БД у нас обратно-совместимы, поэтому проблем со схемой не возникает. Но вскоре все равно планируем уходить от этой схемы.
Мы используем достаточно простое, но очень удобное решение: на тестовом сервере nginx настроен таким образом, чтобы пути вида XXX.sandbox.local смотрели на папку /var/www/XXX. Соответственно когда задача проходит ревью и готова к тестированию, J.A.R.V.I.S. подхватывает её и запускает конфигурацию в teamcity, которая состоит из двух основных шагов:
Собрать из ветки feature/dev-123 билд, который включает в себя генерацию js, сss, шаблонов и т.д. и запаковать в tar.gz архив
Загрузить и распаковать архив на тестовом сервере в папку /var/www/dev-123
Также каждую ночь у нас автоматически собирается площадка develop.sandbox.local, можно всегда зайти и посмотреть на самую последнюю версию продукта.
После того как задача релизится, то J.A.R.V.I.S. автоматически удаляет ненужную площадку, но, если необходимо, мы всегда собрать и запустить площадку из любой ревизизии.
Честно говоря нет. Судя по описанию это аналог только build-сервера (в нашем случае teamcity), а нам нужен был инструмент для управления всем процессом.
Про процесс релизов обязательно напишем отдельную подробную статью. Про teamcity интересует настройки конкретных конфигураций для запуска тестов, сборки тестовых площадок и т.д.?
Жень, система сейчас закрытая. Возможно, пока :) Проблема не в том, чтобы принять решение и открыть исходники, это достаточно просто. Помимо этого нужно проделать очень и очень большую работу по написанию хорошей и подробной документации с примерами использования, а это к сожалению сейчас не в приоритете.
Используем разные отчеты по scrum/kanban доскам, а также некоторые виджеты. Никакой специальной внешней аналитики для jira у нас нет, да и вроде бы она нам и не нужна :)
Слышал от коллег, что на каждое изменение таблицы он выполняет отдельный запрос. Т.е. если добавляем две колонки и liquibase выполнит два alter запроса. Это так?
Логично, т.е. получается когда накатывается альтер, то запросы ждут пока снимется блокировка с таблицы. Процент timeout`ов будет крайне низкий из-за маленького трафика.
Много проектов используют Delphi сейчас?)
Некоторые команды были бы даже рады, если бы им приходилось бы обслуживать всего 5к, а не сотни тысяч запросов во время высокого сезона :)
Это та нагрузка, которую мы достаточно долго получали во время недавних распродаж. Средняя за «совсем обычный день» будет поменьше, да.
Помимо запросов от пользователей, есть также и огромная офлайн часть компании: WMS (система управления складом), логистика и другие внутренние системы.
Нет, Warden - не монолит :) Он сам состоит уже из нескольких компонентов. Больше и сложнее он стал по сравнению с той самой первой версией, которую мы запустили в 20 году и которая умела работать только с кубером.
Этот процент близок к 100%, потому что в большинстве случаев у команд просто нет никакой альтернативы, да она в целом и не нужна: зачем пытаться самому создавать кластер базы или чего-то еще, если можно сделать пару кликов и получить тоже самое.
Но есть и несколько сервисов, которые появились незадолго до наших фреймворков. В этом случае команды используют какие-то отдельные компоненты из них. Но с ними мы тоже ведем работу по переходу на платформу целиком.
Да, действительно, когда мы проектировали Warden, то смотрели на опыт других компаний и различные готовые решения.
Но мы принципиально отказались от использования сайдкаров для этой задачи и перенесли всю логику в клиентскую библиотеку.
Inspection. Тут мы проверяем качество кода. Для php-проектов мы запускаем проверку на соответствие стандартам psr и юнит-тесты, а также измеряем покрытие тестами. Если проверка или тесты упали, то задача возвращается назад разработчику.
Review. Автоматически создаем pull request и отправляем тикет review`eру.
Build. Этап для создание тестовой сборки. Для php мы создаем тестовую площадку (про них ответил чуть ниже), для мобильных приложений собираем полноценный билд.
Testing. Непосредственно тестирование задачи.
Acceptance. На этом этапе заказчик должен подтвердить, что было сделано именно то, что он хотел. Мы используем это шаг для больших бизнез-фич сайта, в случае библиотек или внутренних инструментов он чаще всего проходит автоматически.
Integration. Мы используем gitflow и на этом этапе наступает именно тот момент, когда ветку с задачей нужно интегрировать в develop/master. На самом деле тут просто происходит merge pull request`a :)
Release. Релиз
Для каждого этапа в нашем флоу в jira существует 3 статуса:
Статусы step completed не нужны, т.к. факт успешного прохождения одного этапа означает, что задача готова к следующему.
Статусов суммарно получается действительно много, но благодаря им мы в любой момент времени можем абсолютно точно сказать, что происходит с задачей. Все наши команды используют доски в джире и поэтому разработчикам нужно просто перетаскивать карточки из одной колонки в другую, а не думать над большим кол-вом статусов. Все, что можно сделать автоматически, за них сделает J.A.R.V.I.S.
Также каждую ночь у нас автоматически собирается площадка develop.sandbox.local, можно всегда зайти и посмотреть на самую последнюю версию продукта.
После того как задача релизится, то J.A.R.V.I.S. автоматически удаляет ненужную площадку, но, если необходимо, мы всегда собрать и запустить площадку из любой ревизизии.