Как стать автором
Обновить

Комментарии 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 статуса:

  • Ready for step
  • On step
  • step failed

Статусы step completed не нужны, т.к. факт успешного прохождения одного этапа означает, что задача готова к следующему.

Статусов суммарно получается действительно много, но благодаря им мы в любой момент времени можем абсолютно точно сказать, что происходит с задачей. Все наши команды используют доски в джире и поэтому разработчикам нужно просто перетаскивать карточки из одной колонки в другую, а не думать над большим кол-вом статусов. Все, что можно сделать автоматически, за них сделает J.A.R.V.I.S.
Миша, а где же ссылка на github ???
Жень, система сейчас закрытая. Возможно, пока :) Проблема не в том, чтобы принять решение и открыть исходники, это достаточно просто. Помимо этого нужно проделать очень и очень большую работу по написанию хорошей и подробной документации с примерами использования, а это к сожалению сейчас не в приоритете.
если сделаешь приватный repo, я готов взяться за написание документации и адаптировать под опенсорц
Хорошо, мы подумаем над этим :)
ну как подумали? ;) чего надумали?
А какую аналитику для Jira используете если не секрет?
Используем разные отчеты по scrum/kanban доскам, а также некоторые виджеты. Никакой специальной внешней аналитики для jira у нас нет, да и вроде бы она нам и не нужна :)
Рассматривали Buildbot?
Честно говоря нет. Судя по описанию это аналог только build-сервера (в нашем случае teamcity), а нам нужен был инструмент для управления всем процессом.
А можете подробнее рассказать о тестовых стендах?
Мы используем достаточно простое, но очень удобное решение: на тестовом сервере 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. автоматически удаляет ненужную площадку, но, если необходимо, мы всегда собрать и запустить площадку из любой ревизизии.
А какая используется бд? Общая или каждый раз клонирует слепок и накатывает миграции?
Сейчас используем одну общую базу на все площадки. Все изменения в схемы БД у нас обратно-совместимы, поэтому проблем со схемой не возникает. Но вскоре все равно планируем уходить от этой схемы.
Первая мысль про JARVIS — Ingress
Где скачать-то?
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.