Представьте, что вы делаете ревью кода новой фичи. Помимо качества ее кода вам также интересно, как она будет выглядеть и работать в вашем продукте и насколько удобно будет ее использовать. Раньше вам пришлось бы прервать процесс разработки на собственной рабочей машине, сделать checkout на проверяемую ветку, провести нужные миграции БД и запустить всю рабочую среду (development environment), необходимую для приложения. Теперь вам будет достаточно зайти в мерж-реквест этой ветки на GitLab. Там будет ссылка на уже работающее приложение, развернутое в отдельной среде.
Наконец, ревью завершено, и вы даете коллеге обратную связь в чате. Вместо того, чтобы решать, кто из вас пойдет заводить новую задачу в трекере, вы можете создать задачу и оценить время на ее разработку, не выходя из чата. Аналитика цикла разработки (cycle analytics) сразу учтет данную оценку и будет показывать вам весь путь задачи до выпуска на production, сообщая о возможных узких местах.
Все это и многое другое возможно в новой версии GitLab 8.14. В ней появился учет рабочего времени, приложения для ревью (Review Apps), команды чата (chat commands) и новые возможности аналитики цикла разработки.
MVP этого месяца — Toon Claes. Он реализовал кнопку для удаления сразу всех веток, смерженных в master
.
Спасибо, Toon!
Учет времени, затраченного на задачу — непростое дело. Результаты этого подсчета нужны как разработчикам, получающим почасовую оплату, так и руководителям, анализирующим затраты ресурсов на задачи и проекты. Для учета времени применяется множество инструментов, но обычно они не интегрированы в процесс разработки.
Учет времени (time tracking) в GitLab позволяет фиксировать затраченное на задачу время непосредственно в процессе работы.
С помощью слеш-команды /estimate
задаче назначается оценка времени. Той же командой можно в любой момент изменить оценку. Напомним, что слеш-команды пишутся в описании задачи или в комментариях, выполняются при их сохранении и не отображаются в полученном тексте.
/estimate 6h
После того как вы проработали над задачей какое-то время, вы можете учесть его с помощью команды /spend
:
/spend 3h
Это будет сразу отражено в интерфейсе:
Учет времени будет доступен всем нашим клиентам с Enterprise Edition в пробном режиме в течение периода бета-тестирования, после чего станет отдельным платным продуктом.
Мы с нетерпением ждем ваших предложений о том, как можно улучшить учет времени, чтобы он был вам полезен. Пожалуйста, публикуйте их в трекере задач или пишите в комментариях к этой статье.
Например, мы думаем о реализации отчетов, API, учета времени на досках задач and и различных других возможностей.
Похоже, что за последние пару лет обсуждения переехали из переговорок в онлайн-чаты. Чаты помогают совместной работе, и именно в них рождаются новые идеи. Это важная часть концепции «от идеи до реализации» (idea-to-production), которую мы стремимся реализовать в GitLab. Команды чата связывают его с остальными возможностями GitLab: репозиториями, трекером задач и конвейерами CI/CD.
Сейчас разработка команд чата прошла всего одну итерацию, но уже реализована возможность быстро создавать и просматривать задачи. Вот пример команды, которая создает задачу с заголовком и описанием:
/gitlab issue create Улучшить доски задач
Давайте сделаем доски задач еще лучше!
Если включить ChatOps, можно использовать чат для управления развертыванием на production (разумеется, для этого нужна учетная запись и соответствующие права):
/gitlab deploy staging to production
В текущей итерации поддержка команд чата реализована для Mattermost, который поставляется в пакете GitLab Omnibus. В ближайшее время будет добавлена поддержка для Slack. Набор команд пока что ограничен, но мы собираемся его расширить и будем рады вашим отзывам.
За подробностями обращайтесь к документации по командам чата
Review Apps является новым словом в процедуре ревью кода. Вместо простого просмотра кода Review Apps предоставляет полноценную среду, в которой запускается ваше приложение, с возможностью тестирования и внесения изменений на лету.
Экспериментальная поддержка Review Apps была опубликована в GitLab 8.12, в GitLab 8.13 была добавлена их улучшенная версия, и вот, наконец, с версией 8.14 поставляется полноценная финальная версия Review Apps.
Теперь приложение Review Apps автоматически запускается для каждой ветки и уничтожается при ее удалении. Мы используем эту функциональность с официальным блогом GitLab, и она прекрасно себя показывает. Возможности Review Apps настолько впечатляют, что мы написали про них отдельный пост.
С помощью Cycle Analytics можно следить за тем, как быстро ваши идеи доходят до реализации в итоговом продукте, а также где они застревают по пути. Для того, чтобы добавить наглядности, теперь будут отображаться последние события каждой стадии.
Введение этой функциональности позволяет с легкостью отслеживать, что происходит на каждой стадии, а также быстро обнаруживать и устранять причины замедления.
Не стоит проводить мерж кода до успешного прохождения всех тестов и окончания ревью. В GitLab уже какое-то время существует возможность запрета мержа до прохождения тестов, однако до последнего времени того же самого нельзя было сделать в отношении ревью кода.
Начиная с GitLab 8.14 можно запретить мерж кода до тех пор, пока все обсуждения в мерж-реквесте не будут закрыты. Теперь невозможно случайно упустить из внимания последние комментарии внизу страницы (хотя для этого у нас есть прекрасный виджет сверху); только проверенный и верифицированный код попадет в production.
Включите данную опцию в настройках проекта.
Спасибо Rodolfo Arruda за реализацию этой отличной фичи!
Toon Claes реализовал, казалось бы, очевидную, однако почему-то до сих пор отсутствующую фичу — единую кнопку для удаления всех смерженных веток в GitLab.
При нажатии запрашивается подтверждение действия и, в случае согласия, запускается процесс удаления веток. Эта кнопка находится в разделе Repository ➔ Branches.
Это не приведет к удалению защищенных веток.
Спасибо Toon Claes!
В GitLab 8.13 были добавлены групповые метки, а с текущей версии появилась возможность подписаться на них. С помощью этого можно получать уведомления об интересующих вас событиях в масштабе групп. Например, появилась возможность получать нотификации при создании новой задачи с меткой customer
, в результате чего можно легко отслеживать все задачи с такой меткой во всех проектах в рамках одной группы.
В случае падения конвейера (pipeline) вам будет отправлено письмо, в котором содержится причина падения. Так что теперь нет необходимости сразу лезть в логи, чтобы понять, нужно ли немедленно собирать всю команду или достаточно просто перезапустить сборку.
Мы знаем, что многие из вас активно пользуются JIRA. Мы много работаем над улучшением ее интеграции с GitLab. Ниже некоторые изменения, которые мы сделали в этом релизе. Мы с удовольствием выслушаем ваши предложения насчет других улучшений.
Еще проще стала связь задач в JIRA с коммитами в GitLab. Когда вы упоминаете задачу JIRA в коммите или мерж-реквесте, в эту задачу добавляется обратная ссылка на коммит или реквест. Вы можете написать, что он Fixes
задачу в JIRA или просто упомянуть ее — будьте уверены, все ссылки появятся как надо.
Мерж-реквест: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/7413
Когда вы настраиваете интеграцию JIRA и GitLab, по умолчанию каждый коммит и мерж-реквест в GitLab, который ссылается на задачу в JIRA, создает комментарий в этой задаче в JIRA. Одни люди любят быть в курсе всех деталей происходящего, другие предпочитают более тихую работу.
В GitLab 8.14 вы можете запретить создание комментариев при обращении к задаче в JIRA в коммите или мерж-реквесте.
GitLab в версии 8.14 стал красивее и проще в использовании. Ниже некоторые изменения:
Теперь вы можете видеть, кого вы упоминаете:
Конвейеры и метаинформация выглядят лучше, чем раньше:
Теперь мы показываем информацию об окружении (environment) на странице билда:
Конвейеры теперь показывают, когда пропускаются конкретные сборки (builds):
Проще смотреть, что осталось в текущем конвейере:
Наши чудесные команды UX и фронтенда много работали, чтобы улучшить доступность GitLab. Наиболее выделяющиеся в этом месяце изменения:
Мы всегда с удовольствием послушаем ваши предложения по улучшению доступности GitLab.
В GitLab 8.14 и GitLab Runner 1.8 мы улучшили поддержку приватных образов Докера (private docker images).
Теперь вы можете использовать приватные/защищенные образы, которые автоматически сохраняются в GitLab Container Registry без изменений. GitLab будет посылать учетные данные реестра с данными билда, а Runner будет использовать их для авторизации пулл-реквестов докера.
Также вы сможете использовать защищенную переменную DOCKER_AUTH_CONFIG
, чтобы добавить учетные данные для других приватных реестров. Благодаря этому вы можете использовать любой образ из любого реестра — публичного или приватного — до которого есть доступ из хоста сборки, чтобы этот образ стал базой вашей сборки или сервиса, который она использует.
Runner 1.8 также исправляет механизм генерации алиасов из имени сервиса, когда реестр доступен на нестандартном порту.
Вы можете почитать подробнее о поддержке реестров приватных контейнеров в документации по конфигурации GitLab Runner.
Подробные release notes и инструкции по обновлению/установке можно прочитать в оригинальном англоязычном посте: https://about.gitlab.com/2016/11/22/gitlab-8-14-released/
Перевод с английского выполнен переводческой артелью «Надмозг и партнеры», http://nadmosq.ru, над переводом работали @nick_volynkin, @rishavant и @sgnl_05.