Comments 20
Может быть тут будет наконец-то услышано и замечено — в мобильной версии автоматом прибавляются фрикадельки, за каждое обновление, у меня при средней активности использования порядка 5к. А ведь это мотивация для монетизации, с большим количеством единиц данного ресурса почти так же хорошо, как с премиумом. В саппорт писал — "Мы знаем, мы исправим". Месяца полтора прошло :)
Будет продолжение с подробностями про те задачи, которые выполняет Тимсити и как они соотносятся с флоу задач/релизов в джире?
Про процесс релизов обязательно напишем отдельную подробную статью. Про teamcity интересует настройки конкретных конфигураций для запуска тестов, сборки тестовых площадок и т.д.?
Нет, конкретные конфигурации не нужны. К сожалению, картинка в разделе CI-unit не раскрывает, что же кроется за терминами Inspection, Integration и как они связаны с флоу в джире. И да, почему шаг Review не автоматический? Пулл-реквесты в гитхабе создаются же автоматически?
Подробно по этапам:
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.
Inspection. Тут мы проверяем качество кода. Для php-проектов мы запускаем проверку на соответствие стандартам psr и юнит-тесты, а также измеряем покрытие тестами. Если проверка или тесты упали, то задача возвращается назад разработчику.
Review. Автоматически создаем pull request и отправляем тикет review`eру.
Build. Этап для создание тестовой сборки. Для php мы создаем тестовую площадку (про них ответил чуть ниже), для мобильных приложений собираем полноценный билд.
Testing. Непосредственно тестирование задачи.
Acceptance. На этом этапе заказчик должен подтвердить, что было сделано именно то, что он хотел. Мы используем это шаг для больших бизнез-фич сайта, в случае библиотек или внутренних инструментов он чаще всего проходит автоматически.
Integration. Мы используем gitflow и на этом этапе наступает именно тот момент, когда ветку с задачей нужно интегрировать в develop/master. На самом деле тут просто происходит merge pull request`a :)
Release. Релиз
Для каждого этапа в нашем флоу в jira существует 3 статуса:
- Ready for step
- On step
- step failed
Статусы step completed не нужны, т.к. факт успешного прохождения одного этапа означает, что задача готова к следующему.
Статусов суммарно получается действительно много, но благодаря им мы в любой момент времени можем абсолютно точно сказать, что происходит с задачей. Все наши команды используют доски в джире и поэтому разработчикам нужно просто перетаскивать карточки из одной колонки в другую, а не думать над большим кол-вом статусов. Все, что можно сделать автоматически, за них сделает J.A.R.V.I.S.
Миша, а где же ссылка на github ???
Жень, система сейчас закрытая. Возможно, пока :) Проблема не в том, чтобы принять решение и открыть исходники, это достаточно просто. Помимо этого нужно проделать очень и очень большую работу по написанию хорошей и подробной документации с примерами использования, а это к сожалению сейчас не в приоритете.
А какую аналитику для Jira используете если не секрет?
Рассматривали Buildbot?
А можете подробнее рассказать о тестовых стендах?
Мы используем достаточно простое, но очень удобное решение: на тестовом сервере nginx настроен таким образом, чтобы пути вида XXX.sandbox.local смотрели на папку /var/www/XXX. Соответственно когда задача проходит ревью и готова к тестированию, J.A.R.V.I.S. подхватывает её и запускает конфигурацию в teamcity, которая состоит из двух основных шагов:
Также каждую ночь у нас автоматически собирается площадка develop.sandbox.local, можно всегда зайти и посмотреть на самую последнюю версию продукта.
После того как задача релизится, то J.A.R.V.I.S. автоматически удаляет ненужную площадку, но, если необходимо, мы всегда собрать и запустить площадку из любой ревизизии.
- Собрать из ветки feature/dev-123 билд, который включает в себя генерацию js, сss, шаблонов и т.д. и запаковать в tar.gz архив
- Загрузить и распаковать архив на тестовом сервере в папку /var/www/dev-123
Также каждую ночь у нас автоматически собирается площадка develop.sandbox.local, можно всегда зайти и посмотреть на самую последнюю версию продукта.
После того как задача релизится, то J.A.R.V.I.S. автоматически удаляет ненужную площадку, но, если необходимо, мы всегда собрать и запустить площадку из любой ревизизии.
Первая мысль про JARVIS — Ingress
Где скачать-то?
Sign up to leave a comment.
J.A.R.V.I.S. — невидимый помощник Leo