Фича реквест что это
Product management: от неплохой идеи к уместной фиче
Product manager – позиция неоднозначная. На постсоветском пространстве еще не сложилось полноценной культуры управления продуктом, хотя продуктовых компаний уже в общем-то немало. «Продактами» становятся бывшие бизнес-аналитики, проектные менеджеры, маркетологи и другие специалисты, каждый из которых по-своему подходит к своим новым задачам. Я хотел бы поделиться несколькими тезисами о работе с новыми фичами продукта, которые кажутся важными с моей колокольни.
Это тоже в своем роде управление продуктами, но речь пойдет о другом.
Disclaimer:
Едва ли хоть что-то из сказанного ниже может являться универсальным советом. Я в основном занимаюсь сервисами, с которыми практически не сталкивается пользователь, что накладывает своеобразный отпечаток на работу и те правила, которыми я руководствуюсь.
Feature request, хороший и плохой.
Если продукт, над которым вы работаете, не обладает сверхузкой спецификой, едва ли не каждый встречный сочтет своим долгом прислать вам feature request. Нужно уметь фильтровать их, особенно если ресурсы ограничены. Если дизайнер со слезами на глазах будет убеждать, что вашей системе обработки данных придет конец, если не привести интерфейс в соответствие с модными трендами, это не значит, что нужно бросать все и делать так, чтобы система напоминала последние изыскания сэра Джонатана Айва. Или наоборот: когда программист отстаивает точку зрения, что пользователю подсказки не нужны, т.к. «все и так очевидно», это не повод отказываться от тултипов. Вообще, многие не очень хорошие идеи вызваны профессиональной деформацией: UX готов заботиться о пользователе в ущерб бизнесу, разработчики предпочитают любому интерфейсу теплую ламповую командную строку, некоторых бизнес-ребят вообще ничего не волнует, кроме сроков и денег и т.п. На это все следует делать поправки.
Отдельно хочу заметить, что довод «Так уже сделали конкуренты!» не является достаточным, чтобы сломя голову браться за разработку. Довольно забавно смотреть, как тот или иной проект слепо копирует что-то вплоть до достаточно мелких деталей, не зная, что такая реализация была вызвана, например, локальными ограничениями используемого фреймворка.
Перед началом разработки
Планируя фичу, крайне важно предусмотреть одну штуку, которую не увидит пользователь, но полезную для принятия продакт-менеджером правильных решений. Это всеобщее логирование. Речь не только и не столько технических логах (об этом все-таки должен заботиться техлид), а о бизнес-логике проекта.
Обязательно логируйте все, что не соответствует идеальному сценарию поведения пользователя. Если у вас вся информация о посещениях, не соответствующих этому сценарию, вы всегда сможете проанализировать, что идет не так, и на что пора обратить внимание. Запланированный сценарий может очень сильно отличаться от реального, и не имея полных логов, вы об этом не узнаете.
Продумайте, как вы проверите эффективность фичи. Возможно, для этого также понадобятся какие-то особенные логи. Отсутствие информации о работе новой функциональности — непозволительный промах продакт-менеджера. Позаботьтесь о том, чтобы логи были легкодоступны вам и тем, кто вместе с вами участвует в анализе проекта: в больших компаниях может случиться такое, что вам придется обойти пятерых человек из разных отделов, чтобы добраться до заветного знания.
Проверка полезности
Существует такой антипаттерн в продуктовом менеджменте: «Давайте сделаем классную фичу, а там посмотрим!». В таких случаях «…там посмотрим» зачастую приводит к «Ну, вроде все ок», чего явно недостаточно. Проблема особенно актуальна для KPI-ориентированных фичей.
До того, как фича разработана и появилась на продакшене, нужно определиться, как будет осуществляться эксперимент, какие данные будут использоваться и что будет критерием успешности/неуспешности. Не нужно изобретать велосипед, статистические науки давно подготовили для этого теоретическую базу, которую несложно соблюдать. Это касается и A/B тестов, которые являются одним из лучших способов тестирования полезности фичи, и любых других способов. Не подготовив заранее дизайн эксперимента, легко поддаться искушению и притянуть результат за уши.
Самый быстрый способ находить инсайты и анализировать фич-реквесты
Содержание статьи:
Как создать продукт, который нравится пользователям и приносит прибыль? Можно месяцами топтаться на месте, прежде чем один инсайт в корне преобразует жизнь приложения. Вопрос в том, как найти такой инсайт.
У мобильных продуктов процесс поиска начинается с отзывов: именно там скрыты драгоценные инсайты, способные качественно улучшить продукт. Однако, когда у приложения тысячи отзывов, ценный фидбек может смешаться со спамом или кучей 5-звездочных ‘thank you’.
Как оптимизировать процесс поиска, чтобы быстрее отделять ценный фидбек от бесполезного? И как находить инсайты конкурентов, чтобы привлечь их пользователей?
В AppFollow мы автоматизировали анализ фидбека пользователей, и теперь поиск инсайтов стал проще.
Представляем Semantic Analysis 2.0 для анализа содержания и эмоционального фона отзывов. Новые AI-алгоритмы в его основе работают в три раза быстрее, на 11% точнее анализируют тональность отзыва и на 26% — темы и проблемы.
Мы добавили 40 новых тегов, чтобы точнее размечать проблемы пользователей, а также новый португальский язык к существующим английскому и русскому (и скоро добавим еще 6 языков).
Анализируя отзывы в Semantic Analysis, вы поймете, что движет пользователями и чего не хватает вашему продукту:
Как ускорить анализ фидбека и сбор фич-реквестов
Мнение пользователей напрямую влияет на будущее продукта, т.к. вы делаете продукт для них, а не для себя. Поэтому важно знать, как они воспринимают изменения. Чтобы это выяснить, вы можете руками собирать фидбек в табличку или ускорить этот процесс с Semantic Analysis. Он делает за вас предварительный анализ, а вы просто собираете инсайты.
Например, мы хотим проанализировать фидбек пользователей после мажорного обновления. Для этого возьмем игру Harry Potter: Hogwarts Mystery в Google Play — 2 марта в игру добавили новый квест.
Источник: appfollow.io
Как пользователи восприняли новшества? Для этого проанализируем отзывы за 2 недели после обновления в Semantic Analysis.
Сначала посмотрим данные по всем странам и языкам. На графиках Positive vs Negative и Sentiment Timeline видно, что пользователи позитивно восприняли изменения: на следующий день после обновления количество позитивного фидбека выросло в 5 раз.
Источник: appfollow.io
Теперь посмотрим, о чем писали пользователи. На графике Topics видно, что про обновление написало всего 3% игроков, зато 13% оставили фич-реквесты.
Источник: appfollow.io
По клику на тему ‘Feature Requests’ смотрим, чего не хватает пользователям. Большинство фич-реквестов касается проблем с энергией и кастомизации персонажей. И нам потребовалось 10 минут, чтобы это определить!
Источник: appfollow.io
Теперь посмотрим, как меняется настроение игроков от страны к стране. Health Check Score показывает, насколько удовлетворены пользователи, и сигнализирует, если что-то не так. Общий скор 72%, при бенчмарке 70%, говорит о том, что пользователи в целом довольны. Но везде ли игроки одинаково довольны?
Самые довольные пользователи из англоговорящих стран — 75%. В Португалии и Бразилии скор снижается до 62% и совсем падает в русскоговорящих странах (Google Play отдает данные по языкам, а не по странам).
Источник: appfollow.io
Далее вы можете сравнить темы отзывов по странам и найти причины недовольств. На такой верхнеуровневый анализ у вас уйдут минуты, а не дни.
Вооружившись этими данными, вы сможете быстрее принимать решения и корректировать продуктовую стратегию.
Как искать инсайты у конкурентов
Почти у каждого приложения в сторах есть сильные конкуренты. Но чего не хватает вашему продукту, чтобы переманить их пользователей к себе?
Разобраться в этом поможет анализ отзывов конкурентов, или reviews mining. Он помогает находить недостатки конкурентов и киллер-фичи, из-за которых пользователи предпочитают конкурента вам. Для этого можно фильтровать отзывы по рейтингу или определенному слову. Однако, фич-реквест может быть с высокой оценкой, а слово может быть написано с ошибкой. Semantic Analysis ускорит поиск инсайтов в таких отзывах.
Предположим, вы ищете, как улучшить фитнес-приложение. Посмотрим, чего не хватает пользователям популярных в этой нише приложений: Sweat, Asana Rebel и Nike Training Club. Мы отсортировали отзывы с фич-реквестами и касающиеся UI/UX и получили небольшой список:
Чтобы собрать эти идеи и гипотезы, не нужно часами перебирать чужие отзывы в аппсторе, Semantic Analysis соберет нужные отзывы за период и найдет все фичреквесты:
Источник: appfollow.io
Также мы можем посмотреть, каким приложением больше всего недовольны. В нашем примере это Asana Rebel — у нее самый низкий скор, 53%.
Источник: appfollow.io
Используйте инсайты о недостатках конкурента для улучшения собственного продукта.
Как автоматизировать сбор инсайтов от конкурентов:
Хотите оптимизировать поиск инсайтов и эффективно улучшать продуктовую стратегию?
Как правильный ответ на фичреквесты поможет вырасти вашему продукту
Если вы работаете в команде поддержки, вероятно, вам знакома ситуация, когда пользователь просит добавить фичу, которой недостает в продукте. Даже у лучших сервисов с большим количеством активных пользователей возникают success gaps — несоответствие возможностей продукта ожиданиям пользователя.
Конечно, на запросы всегда можно ответить общими фразочками вроде «Следите за нашими обновлениями» или «Мы передадим вашу просьбу в продуктовую команду». Но полезнее погрузиться в проблему пользователя, чтобы полностью понять, чего он хочет достичь.
Признать, что в продукте нет какой-либо фичи, которую запросил клиент, — абсолютно нормально.
Как работать с запросами на фичи?
Для начала важно понять, что все фичреквесты разные. Их можно разделить на три основных типа:
Давайте разберем более подробно.
1. Проблемы с существующими фичами.
Идеальных продуктов не существует. Наверняка в вашем сервисе что-то не работает так, как нужно. Возможно, некоторые пользователи даже пишут: «Фича, на которую я рассчитываю (и за которую плачу!) сломалась. Мне срочно нужна ваша помощь.» Конечно, можно просто отправить ошибку в Github и перейти к следующему диалогу, но мы считаем, что команда поддержки должна уметь показывать клиентам, как достичь результата, даже при наличии технических ограничений.
В этих случаях используйте фичреквесты как начальную точку для разговора о том, чего именно пытаются достичь клиенты. Задавайте уточняющие вопросы, консультируйте клиента и погружайтесь в проблемы, которые он описывает.
Старайтесь не указывать даты, когда вы добавите изменения. Лучше сделать больше, чем пообещать все к определенному времени и не уложиться в срок. Вместо этого предложите пользователю обходные пути, чтобы быстро решить задачу. Часто им неважно, работает ли та или иная функция, если при этом они могут делать свою работу. Исполняя желания клиентов и делая больше, чем от вас ожидают, вы сможете завоевать доверие и повысить лояльность к своей компании.
2. Исправления фичей.
Другой распространенный сценарий — просьба добавить новую функциональность в ваш сервис. Служба поддержки будет первым местом, куда обратится пользователь с такой проблемой.
Ресурсы ограничены в любой компании, и ваша команда продукта не может добавлять новые фичи по каждому запросу пользователей. Вместо этого стоит остановиться и подумать, можете ли вы решить проблемы без доработок продукта. Часто бывает, что команда продукта уже разобралась с пробелом в функциональности, но иначе, чем просили клиенты.
Пользователи Carrot quest, у которых несколько бизнес-подразделений (например, опт и розница в интернет-магазине) и стоит один скрипт на сайте, просят разделить панели администраторов чтобы упростить управление. У нас нет такой функции, но мы можем разделить каналы и автоназначения в них, чтобы сообщения приходили тем, кто отвечает за ту или иную часть продукта. Так клиенты получают назначения не изо всех каналов, а только из тех, которые им важны.
Возможно, такая альтернатива — это не совсем то, что ожидает увидеть пользователь, но часто бывает достаточно просто объяснить, почему вы выбрали такой путь. В большинстве случаев клиенты просто не знают, что проблему можно решить при помощи уже существующих в вашем продукте инструментов.
3. Запросы новых фичей.
Самые коварные вопросы — о том, в чем ваш продукт действительно бессилен. Перед ответом на них спросите себя: вписывается ли этот реквест в ваш роадмап и стратегию развития продукта?
Вместо того чтобы давать обещания о том, что на самом деле никогда не произойдет, лучше сразу отказаться от этого изменения.
Всегда важно быть честным с клиентами и рассказывать им, как вы пришли к тому или иному решению.
Если клиент просит что-то, что совсем не вписывается в ваш роадмап, попробуйте стороннее решение или интеграцию, подходящую для этого юзкейса. Например, если клиент хочет управлять календарем, у YouCanBookMe уже есть готовое решение, а с помощью Zapier можно сделать интеграции с огромным количеством сервисов. Вместо пустых обещаний сделать то, что на самом деле не соответствует вашей стратегии, подумайте о возможных решениях вне вашего продукта.
Важно и то, как вы говорите о недостатках продукта. Вместо извинений и приукрашиваний погрузите пользователей в контекст. Абсолютно нормально признавать отсутствие фичи (и рассказывать о том, что ваша команда готовит и скоро выкатит), если при этом пути улучшения продукта вы ищете исходя из конкретных болей клиента.
Очень полезно подробно рассказывать о том, как вы принимаете сложные решения, и объяснять, что ресурсы разработки ограничены, потому что это покажет вас с человеческой стороны и поможет клиентам понять вашу точку зрения. В конце концов, времени никогда не будет хватать, чтобы работать со всеми идеями, параллельно справляться с ошибками и проблемами и при этом соответствовать миссии и долгосрочной стратегии компании.
Приоритизация фичреквестов
Как только вы собрали данные о том, что клиенты хотят изменить в продукте, вам нужно приоритизировать их пожелания.
Критерии, на которые можно опираться:
Заключение
Один раз собрав и приоритизировав обратную связь от пользователей, подумайте, как передать ее команде продукта. В конце концов, если 50 клиентов в неделю не могут найти какую-то кнопку, это точно знак, что нужно что-то поменять в интерфейсе.
Независимо от того, какой инструмент вы используете, самое важное — не просто собрать запросы на новые фичи, а реагировать на них. Если клиенты тратят свое время на написание отзыва или предложения по улучшению функционала, нужно убедиться, что ваш ответ в конечном итоге приведет пользователя к успешному результату.
Мария Пьянкова
Несу контент в Инстаграм, в блог и в народ
Вышел GitLab 11.4 с ревью мерж-реквестов и подключаемыми фичами
Мы рады представить новый релиз GitLab 11.4 с долгожданными обновлениями, призванными помочь командам работать эффективнее. Большинство команд, применяющих DevOps, стремятся к сокращению времени цикла поставки. Поэтому разработчики всегда рады улучшениям, которые уменьшат количество работы и потери во времени, так как за счет этого ускоряется поставка продукта и повышаются бизнес-показатели.
С GitLab 11.4 мы делаем ревью кода более эффективным за счет ревью мерж-реквестов и дерева файлов для изменений; также мы представляем альфа-версию подключаемых фич (feature flags, feature toggle). Auto DevOps и CI работают лучше в связке с миграцией баз данных PostgreSQL и инкрементным развертыванием по расписанию. Даже Git теперь быстрее с поддержкой протокола Git v2.
Ревью кода
Ревью мерж-реквестов поможет упорядочить комментарии по коду и мерж-реквестам. Пакетное комментирование (batch comments) позволяет ревьюверу писать комментарии по коду или мерж-реквесту и затем оформить и отправлять их одним пакетом, и теперь отслеживание изменений в проекте стало проще.
Представление изменений мерж-реквеста в виде дерева файлов также облегчает ревьюверам просмотр множества измененных файлов и предоставление своего фидбэка.
Russell Levy, один из основателей и технический директор Chorus.ai, рассказал, как ревью мерж-реквестов и представление в виде дерева файлов помогают их команде:
Мы проводим код-ревью очень тщательно и обычно пишем по 10-20 комментариев к среднему мерж-реквесту, а по некоторым из них возникает несколько итераций обсуждений. Ревью мерж-реквестов снижает хаос и заминки во время процесса ревью кода.
Для больших мерж-реквестов новое представление изменений в виде дерева файлов сильно облегчает и ускоряет ревью, позволяя легко перемещаться по коду, чтобы понять зависимости.
Подключаемые фичи
Мы представляем альфа-версию системы переключения функциональности — подключаемые фичи. Теперь команды могут практиковать непрерывную поставку (continuous delivery), добавляя новые фичи в продакшн небольшими партиями, снижая риск перед полноценным развертыванием.
Улучшения для Auto DevOps и CI/CD
И ещё больше усовершенствований
Читайте дальше, и вы узнаете обо всех новых фичах GitLab 11.4.
MVP этого месяца — Luke Picciau
Luke добавил возможность скачивания файла с кодами восстановления для двухфакторной аутентификации, что упростит их бэкап. Эти коды потребуются для входа в аккаунт GitLab, если вы потеряете доступ к своему телефону или одноразовому секретному паролю (one time password secret).
Спасибо, Luke, за этот вклад!
Основные фичи релиза GitLab 11.4
Ревью мерж-реквестов
(PREMIUM, ULTIMATE, SILVER, GOLD)
Ревью кода в мерж-реквестах — мощная фича GitLab. Члены команды ведут обсуждения, привязанные к конкретным строчкам кода в диффе, и даже могут их решать. Тем не менее, этот процесс может стать затруднительным в мерж-реквестах с большими диффами. Часто ревьюверу приходится оставлять 10 или более комментариев в одном обсуждении, и 9-ый или 10-ый комментарий могут сделать предыдущие комментарии ненужными. В итоге автор мерж-реквеста получает массу уведомлений, и ему приходится разбираться со всеми.
В этом релизе мы представляем Ревью мерж-реквестов. Это позволит ревьюверу писать в черновик столько комментариев, сколько ему нужно, убедиться, что они все необходимы, и затем отправить их одним действием. Так как черновики сохраняются в GitLab, ревьювер может разделить свою работу на несколько сессий, например, начать ревью на своем десктопе на работе и закончить вечером дома на планшете. Когда эти черновые комментарии отправляются, они отображаются как обычные отдельные комментарии. Это даст отдельным членам команды возможность проводить ревью кода так, как им удобно, но все еще вместе со всей командой.
В будущих релизах мы улучшим эту фичу и предоставим возможность посмотреть превью, прежде чем отправлять пакет комментариев, а также сгруппируем уведомления об этих комментариях в одно уведомление.
Создание и использование подключаемых фич в ваших приложениях (альфа-версия)
(PREMIUM, ULTIMATE, SILVER, GOLD)
Эта возможность позволяет создавать подключаемые фичи для вашего программного обеспечения и управлять ими непосредственно в продукте. Просто создайте новую подключаемую фичу, подтвердите ее в вашем ПО с помощью простых инструкций по API, и у вас появится возможность управлять поведением вашего продукта в полевых условиях с помощью подключаемой фичи в самом GitLab.
Подключаемые фичи предлагают систему переключения функциональности для вашего приложения. Она позволит командам достичь непрерывной поставки (CD), отправляя новые фичи в продакшн небольшими партиями для управляемого тестирования, разделяя отправку фичи с запуском для клиентов.
На данный момент эта система представлена в альфа-версии. Мы и предлагаем вам проверить как это работает и оставить фидбэк, но не забывайте, что реализация может измениться в последующих релизах.
Дерево файлов для просмотра изменений мерж-реквеста
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Ревью кода — необходимая практика для любого успешного проекта, но из списка изменений бывает трудно понять, что поменялось. Чтобы облегчить эту задачу, GitLab теперь предоставляет дерево файлов для изменений, по которому можно искать.
Ранее список измененных файлов был доступен через выпадающий список с поиском, что лучше всего подходило для перехода к конкретному файлу.
Владельцы кода предлагаются в качестве подтверждающих мерж-реквест
(STARTER, PREMIUM, ULTIMATE, BRONZE, SILVER, GOLD)
Не всегда очевидно, кто будет лучшей кандидатурой для ревью ваших изменений. Владельцы кода теперь предлагаются в качестве подтверждающих при создании или редактировании мерж-реквеста для упрощения назначения правильных людей на эту роль.
Поддержка владельцев кода появилась в релизе GitLab 11.3 (оригинальная статья, перевод). В будущих релизах увеличится степень участия владельцев кода в рабочих процессах мерж-реквестов с автоматическим назначением как подтверждающих и требуемым подтверждением владельца.
Обновленный вид страницы профиля
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Не важно, в какой роли вы используете GitLab, ваша активность — значимый источник информации и индикатор вашей вовлеченности, отображающийся на странице вашего профиля. Ваш профиль должен легко давать представление о том, что вам интересно и над чем вы работаете.
В этом релизе мы обновили страницу профиля пользователя, сократив уже знакомый вам график вкладов в разработку: теперь на нем отображаются ваши последние действия и наиболее важные личные проекты в GitLab.
Отображение и изменение статуса в меню пользователя
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
В релизе GitLab 11.2 (оригинальная статья, перевод) мы впервые представили статусы пользователей, предоставив возможность поделиться вашей текущей загруженностью, настроением или хоть любимым животным.
В этом релизе мы упрощаем изменение статуса. Новый пункт «Задать статус» (“Set status”) в меню пользователя позволит вам задать или очистить статус не покидая контекста. Там же отображается ваш текущий статус с сообщением и эмоджи — вверху, вместе с вашим именем и никнеймом.
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Запуск работ only / except для изменений в пути файла или в файле
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Это даст больше контроля над репозиториями, содержащими различные ресурсы и сборки, так как теперь для новых изменений будут выполнены только нужные шаги, что ускорит работу конвейера в целом.
Добавили инкрементное развертывание по расписанию в Auto DevOps
(PREMIUM, ULTIMATE, SILVER, GOLD)
Возможность запускать инкрементное развертывание в Auto DevOps доступна уже некоторое время, и с этим релизом мы добавляем возможность запускать развертывание по расписанию, так что оно будет автоматически проводиться по указанному графику, если не возникнет никаких ошибок.
Поддержка Kubernetes RBAC для приложений под управлением GitLab
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
При первичной настройке вашей инфраструктуры или при подключении к существующей первостепенным фактором является безопасность. Управление доступом на основе ролей (Role-based access control, RBAC) стало общедоступным (GA) в релизе Kubernetes 1.8, предоставляя более точную настройку управлением доступом к ресурсам Kubernetes.
Наша интеграция с Kubernetes теперь предлагает возможность либо создать кластер в GKE (Google Kubernetes Engine) с подключенным RBAC, либо подключиться к существующему кластеру с RBAC, что сделает вашу инфраструктуру безопаснее.
Поддержка RBAC в Auto DevOps
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Auto DevOps теперь также поддерживает развертывание приложений на кластерах Kubernetes с подключенным RBAC.
Управление доступом на основе ролей — важный инструмент, который помогает операторам (ответственным за деплой) обеспечить надежность, безопасность и эффективность кластеров Kubernetes. Использование Auto DevOps совместно с кластером с подключенным RBAC гарантирует, что ваши приложения получат все преимущества возросшей безопасности инфраструктуры.
Поддержка миграции баз данных PostgreSQL и их инициализации для Auto DevOps
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Мы улучшили возможности Auto DevOps для автоматического обнаружения, сборки, тестирования, деплоя и мониторинга ваших приложений. Начиная с релиза 11.4, Auto DevOps предоставляет возможность инициализировать или мигрировать базы PostgreSQL в ваш проект.
Просто задайте переменную проекта для инициализации или миграции вашей базы PostgreSQL, а Auto DevOps сделает все остальное.
Другие улучшения в GitLab 11.4
Список меток, на которые вы подписаны
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Метки в GitLab очень многогранны, так как могут быть применены к задачам, мерж-реквестам и эпикам. Но чем больше меток вы используете, тем труднее поддерживать их в порядке.
В прошлых релизах мы добавили поиск по меткам на странице со списком меток проекта. Начиная с этого релиза вы можете искать метки, сортировать их по имени, дате создания и дате изменения, и просматривать список меток, на уведомления о которых вы подписаны. Все это доступно в списках групповых меток и меток, привязанных к проекту.
Фильтрация мерж-реквестов по WIP
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Мерж-реквесты являются одной из основных частей GitLab. Они позволяют участникам проекта совместно работать над кодом, соблюдая при этом прозрачность. Мы за то, чтобы команды на ранних стадиях делились своей работой и использовали фичу WIP («work in progress», «в процессе разработки»), которая показывает, что над мерж-реквестом все еще ведется активная работа, и его еще рано мержить.
В этом релизе мы добавили новый фильтр для списков мерж-реквестов, работающий как на уровне группы, так и на уровне проекта, что помогает пользователям проще различать WIP и не-WIP реквесты («в работе» и «готово»). Это позволяет пользователям сосредоточить внимание на мерж-реквестах, которые все еще находятся на ранних стадиях работы, в отличие от тех, которые ближе к финальным стадиям проверки перед мержем.
Выделение персональных упоминаний
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
В обсуждении задачи или мерж-реквеста с большим числом участников сложно увидеть, какие комментарии адресованы именно вам.
Начиная с этого релиза, все упоминания по @имени текущего пользователя, будут выделяться другим цветом, что позволяет сразу увидеть, какие комментарии направлены вам, и быстро на них сфокусироваться.
Вставка GFM-таблиц и ссылок в Markdown по клику
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
GitLab поддерживает GitLab Flavored Markdown (GFM) в большинстве полей ввода текста, расширяя возможности форматирования с простым синтаксисом. В частности, на GFM можно создавать таблицы. Ранее этой функцией было сложно пользоваться, особенно при работе с большими таблицами, так как приходилось вводить множество символов или вставлять предыдущую таблицу, чтобы форматировать ее как вам удобно. GFM также поддерживает работу со ссылками. Но иногда бывает сложно вспомнить, какой синтаксис нужно использовать в данном случае.
Начиная с этого релиза, вы можете просто щелкнуть по кнопке с изображением таблицы в редакторе GFM, и таблица будет вставлена автоматически. Далее вы можете легко заполнить значения ячеек таблицы или продлить ее, настраивая как вам угодно. Эту функцию можно использовать в описаниях и комментариях по всему GitLab.
Аналогично, щелкнув по кнопке вставки ссылки, вы получите шаблон для URL, в который вы можете быстро вставить адрес ссылки и ее название.
Спасибо George Tsiolis за разработку вставки таблицы!
Спасибо Jan Beckmann за разработку вставки URL!
Включение новых задач в график выполнения работ
(STARTER, PREMIUM, ULTIMATE, BRONZE, SILVER, GOLD)
Графики выполнения работ (burndown charts) помогают командам отслеживать прогресс в выполнении работы по майлстоуну. Обычно объем работы обсуждается и утверждается до того, как майлстоун начнется. Но иногда у этого правила бывают важные исключения (такие как неожиданный баг или решение проблемы безопасности), и приходится создавать новые тикеты для возникающих задач.
Начиная с этого релиза, графики выполнения работ будут показывать информацию о новых задачах, которые создаются в середине майлстоуна, из-за чего происходит скачок на графике.
Расширенный диапазон значений весов в API задач
(STARTER, PREMIUM, ULTIMATE, BRONZE, SILVER, GOLD)
Начиная с предыдущего релиза, значения весов задач могут меняться от нуля до бесконечности (в разумных пределах).
В этом релизе мы добавили возможность задавать веса с более широким диапазоном при помощи API задач.
Быстрая блокировка обсуждений
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Блокировка обсуждений задач и мерж-реквестов помогает переключить внимание со старых задач и мерж-реквестов на более актуальные. Также эту функцию можно использовать, чтобы пресекать агрессивное или непродуктивное поведение.
В этом релизе мы добавили быстрые действия для блокировки и разблокировки обсуждений, так что теперь вы можете блокировать/разблокировать обсуждения вместе с отправкой комментария.
Спасибо Mehdi Lahmam за эту фичу!
Закрытие эпиков
В этом релизе добавлена возможность закрывать (и открывать заново) эпики в GitLab, так же как задачи и мерж-реквесты. В списке эпиков теперь есть вкладки Open (открыто), Closed (решено) и All (все), аналогично тому, как это реализовано для задач. Так что теперь, если вы завершили всю работу над эпиком, или он уже не актуален, его можно пометить как завершенный (closed), и он больше не будет появляться в списке по умолчанию.
Теперь вы можете закрывать и открывать заново эпики при помощи соответствующих кнопок или через быстрые действия, а также через API, как задачи.
Улучшение панели настроек администратора
(CORE, STARTER, PREMIUM, ULTIMATE)
Из-за большого числа возможностей, которые предоставляет GitLab, администрирование GitLab может оказаться довольно сложной задачей.
В этом релизе мы сделали панель настроек администратора более удобной для использования. Теперь все подразделы индивидуальных настроек находятся на отдельных страницах, что дает администратору быстрый доступ к любым настройкам, которые ему нужно изменить.
Сортировка проектов по популярности
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Наша команда разработчиков делает все возможное, чтобы вам было удобнее искать релевантные и интересные проекты в вашем инстансе GitLab. В этом релизе был добавлен новый фильтр “Most stars” (сортировка по числу лайков), который позволяет находить проекты с наибольшим числом отметок в вашем инстансе.
Спасибо Jacopo Beschi за эту фичу!
Отображение процентного соотношения используемых языков программирования на странице проекта
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Недавно мы добавили на страницу обзора проекта статистику использования языков, которая дает общее представление о том, какие языки программирования были использованы при разработке.
В версии GitLab 11.4 мы добавили отображение процентного содержания кода на каждом языке. Это позволяет получить количественную характеристику стека технологий вашего проекта.
Скачивание двухфакторных кодов восстановления
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Двухфакторная аутентификация по факту является стандартом при входе в систему любого современного веб-приложения. Мы, разработчики GitLab, это понимаем и серьезно относимся к вашей безопасности. Каждый раз, когда вы настраиваете двухфакторную аутентификацию, мы предоставляем ограниченный набор кодов восстановления доступа, которые позволяют восстановить доступ к вашему аккаунту в случае чрезвычайных обстоятельств.
Начиная с этого релиза поддерживается возможность скачивания кодов восстановления в виде текстового файла при помощи кнопки “Download codes” (загрузить коды).
Спасибо Luke Picciau за эту фичу!
Фильтрация по типу и состоянию в окне просмотра Runners
(CORE, STARTER, PREMIUM, ULTIMATE)
Окно просмотра Runners теперь поддерживает возможность фильтровать их по типу и состоянию, что дает больше возможностей для управления большими наборами Runners в окружении проекта.
В исполнитель Docker добавлена поддержка интерактивных веб-терминалов
(CORE, STARTER, PREMIUM, ULTIMATE)
Мы расширили функциональность интерактивных веб-терминалов и сделали их совместимыми с исполнителями Docker. На текущий момент сессия Docker завершается, как только завершается соответствующий скрипт, но мы работаем над этой проблемой, и надеемся решить ее к следующему релизу.
Пропуск работ Auto DevOps при недоступности функций
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Начиная с версии 11.4 Auto DevOps будет производить оценку плана (при хостинге на GitLab.com) или профиля (при селф-хостинге) для инстанса, в котором он запущен, чтобы определить, какие работы следует пропустить. В результате конвейер Auto DevOps будет работать быстрее, так как будут пропускаться неиспользуемые функции.
Это позволит вам сэкономить время, а также теперь ваш график конвейера будет выглядеть аккуратнее, так как на нем будут отмечены только релевантные для вашего проекта работы.
Конвейеры могут задавать выполнение работ по расписанию
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Интерактивные перечни задач с Nurtch и JupyterHub
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Интерактивные перечни задач (runbooks) дают операторам отличную возможность взаимодействовать с различными системами для выполнения диагностики, развертывания и оценки компонентов инфраструктуры.
JupyterHub, приложение, доступное благодаря интеграции GitLab и Kubernetes теперь включает в себя библиотеку Nurtch Rubix, что дает возможность создавать перечни задач для DevOps. В качестве примера представлен тестовый перечень задач, демонстрирующий основные операции.
Добавлен ручной ввод при заполнении списков лицензий
Политика управления лицензиями позволяет разработчикам подтверждать использование отдельных лицензий в проекте, либо заносить их в черный список. Это можно делать прямо на странице мерж-реквеста, как только появляется новая лицензия. Но иногда Maintainers хотят составить список лицензий заранее, чтобы разработчики знали, согласуются ли вносимые ими изменения с политикой проекта.
В GitLab 11.4 мы добавили возможность ручного ввода при составлении списка лицензий. Maintainers могут заполнить список на странице Settings > CI/CD > License Management, выбирая лицензии из стандартного набора или добавляя их вручную.
На панели метрик теперь отображаются пороговые значения для оповещений
Начиная с GitLab 11.4, заданные пороговые значения для оповещений выводятся прямо на графики метрик. Это позволяет проще определять, какие метрики генерируют оповещения в данный момент, а также позволяет получить наглядное представление о взаимодействии между метриками и пороговыми значениями оповещений.
Протокол Git v2
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Разработчики обновляют локальные репозитории ( git fetch ) несколько раз в день, чтобы проверить, не отстает ли текущая ветка от последней версии ветки в репозитории. Протокол Git v2 является важным обновлением протокола передачи данных, который отвечает за обмен данными между клиентом (вашим компьютером) и сервером (GitLab) при клонировании, извлечении и пушах. Новый протокол передачи данных повышает производительность фетчей и дает возможность и дальше улучшать протокол.
Ранее при вызове фетч-команд выводился список всех ссылок в репозитории. Например, если фетчить обновления для одной ветки ( git fetch origin master ) то вам также будет выводиться полный список всех ссылок. Если речь идет о большом проекте, вы можете получить более 100000 ссылок и десятки мегабайт данных.
Улучшение UX панели настроек администратора Geo
Для администратора Geo критически важно следить за загрузкой и синхронизацией вторичных нодов при работе с географически распределенными командами.
В GitLab 11.4 мы улучшили UX Geo на панели администратора, добавив в пользовательский интерфейс еще больше информации по синхронизации и верификации. При нажатии новой кнопки “Open projects” (открыть проекты) в профиле на первичном ноде, генерируется ссылка на список проектов на соответствующем вторичном ноде. В профилях на вторичных нодах в новой вкладке “All” содержится основная информация о статусе верификации всех проектов.
Обновление Prometheus 2.0 для Omnibus GitLab
(CORE, STARTER, PREMIUM, ULTIMATE)
Omnibus Gitlab поставляется вместе с Prometheus, что дает наглядное представление развернутых инстансов. Команда разработчиков Prometheus выпустила масштабное обновление в виде новой серии 2.x, которая включает в себя ряд улучшений, среди которых улучшенная производительность и более удобный формат базы данных временных рядов. К сожалению, изменение архитектуры базы данных привело к тому, что она не поддерживает обратную совместимость со старым форматом серии 1.x.
Начиная с GitLab 11.4, Prometheus 2.4.2 входит в пакет Omnibus, так что вы уже можете воспользоваться его преимуществами.
Чтобы получить больше информации об обновлении Prometheus до 2.4.2, обратитесь к нашей документации по обновлениям.
Подробные release notes и инструкции по обновлению/установке можно прочитать в оригинальном англоязычном посте: GitLab 11.4 released with Merge Request Reviews and Feature Flags.
Над переводом с английского работали cattidourden, rishavant и @maryartkey.