Что такое flow в разработке

Git Flow

Git flow — это популярная методология ветвления и слияния, которая описывает несколько веток для разработки, релизов и взаимодействия между ними.

Схематично Git flow выглядит так:

Основные принципы

Основные идеи Git Flow состоят в том, что существует несколько типов веток:

• главные ( master и develop ) — существуют всё время.
• вспомогательные ( feature , release и hotfix ) — используются для распараллеливания разработки между членами команды. Всегда имеют ограниченный срок жизни — каждая из них в итоге удаляется.

Подробнее о ветках:

• master . Дефолтная ветка знакомая каждому, кто работал с гитом. Она всегда содержит стабильный код. Код, попадая в нее, образует очередной релиз.
• develop . Создаётся параллельно ветке master и является главной ветвью для разработки. Хранящийся в ней код в любой момент времени должен содержать самые последние изданные изменения, необходимые для следующего релиза. Когда исходный код в этой ветке достигает стабильного состояния и готов к релизу, все изменения должны быть определённым способом (при помощи ветки release ) влиты в главную ветвь ( master ) и помечены тегом с номером релиза.
• feature . Ответвляются от ветки develop . Используются для разработки новых функций, которые должны появиться в текущем или будущем релизах, т.е. заранее неизвестно в какой из релизов они попадут. Когда работа в ветке завершена, она вливается обратно в develop и удаляется. При неудавшемся эксперименте ветка удаляется без вливания куда-либо.
• release . Ответвляются от ветки develop , имена должны присваиваться по типу release-* . Используются для подготовки к выпуску новых версий продукта, т.е. здесь осуществляются небольшие исправления, подготавливается информация для релиза (номер версии, дата сборки и т.д.). Когда вся эта работа завершена, ветка вливается в develop и master .
• hotfix . Ответвляются от ветки master , имена должны присваиваться по типу hotfix-* . Данные ветки порождаются необходимостью немедленно исправить какие-либо ошибки или неправильную работу функционала в текущем релизе. Когда баг исправлен, изменения надо влить обратно в master , а также в ветвь develop , чтобы гарантировать, что это исправление окажется и в следующем релизе.

Плюсы и минусы

Плюсы:

• Git Flow используется многими распределенными командами, в т.ч. и open source команды, которые имеют разные уровни квалификации. Сопровождающие проекта могут проводить код ревью и утверждать каждую строку кода в релизы.
• Git Flow хорошо подходит для “традиционной модели релизов”, где релизы делаются раз в месяц или раз в пару недель.
• Git Flow также хорошо работает при работе с установленным продуктом или несколькими версиями в производстве.

Минусы:

• Git Flow может замедлять работу, когда приходится ревьювить большие пулл реквесты, когда вы пытаетесь выполнить итерацию быстро.
• Релизы сложно делать чаще, чем раз в неделю.
• Большие функции могут потратить дни на мерж и резолв конфликтов и форсировать несколько циклов тестирования.
• История проекта в гите имеет кучу merge commits и затрудняет просмотр реальной работы.
• Может быть проблематичным в CI/CD сценариях.

git-flow (AVH Edition)

Существует специальный инструмент, который облегчает работу с методологией Git Flow — gitflow-avh. Включает в себя коллекцию расширений для git, которая помогает избежать многих повторяющихся операций.

Основные команды:

• start — создаёт ветку (feature, release или hotfix).
• finish — сливает ветку в develop и/или master .
• publish — публикация ветки на удалённом сервере.
• pull — получение ветки, которую опубликовал другой пользователь.

Полезные ссылки

Branching стратегии в Git — статья о нескольких методологиях ветвления (Git flow, Github flow, GitLab flow, Trunk Based Development).
Удачная модель ветвления для Git — плюсы Git Flow.
Пожалуйста, перестаньте рекомендовать Git Flow — минусы Git Flow.
Шпаргалка по git-flow-avh — информация о том как начать использовать gitflow-avh.

Презентация методологии git-flow

Многие наверное слышали про git-flow. В презентации рассказывается для чего нужна методология, как её применять, сравнение с методологиями GitLab Flow и GitHub Flow, ссылки на интеграцию с IDE.

Скачать PowerPoint презентацию git-flow с OneDrive:

Git-flow.pptx

Store photos and docs online. Access them from any PC, Mac or phone. Create and work together on Word, Excel or…

Подписывайтесь на канал про DevOps тренды в Telegram: https://t.me/ruopsdev

Для чего git-flow: командная разработка по стандарту, стабилизация, CI/CD

• Git Flow является методологией работы с Git. Это значит, она определяет, какие ветки нужно создать и как производить их слияние
• git-flow является оберткой для Git. Команда git flow init является расширением стандартной команды git init и ничего не меняет в вашем репозитории, кроме того, что создает ветки. Есть интеграции с IDE и GUI менеджерами репозитория
• Вместо использования одной ветки master, в этой модели используется две ветки для записи истории проекта. В ветке master хранится официальная история релиза, а ветка develop служит в качестве интеграционной ветки для новых функций. Также, удобно тегировать все коммиты в ветке master номером версии

Инициализация git flow

• Первым шагом является создание ветки develop от ветки master
• В этой ветке будет находится вся история проекта, в то время как master содержит частичную историю
• Остальные разработчики теперь должны клонировать центральный репозиторий и настроить отслеживание для ветки develop
• Каждая новая функциональность должна разрабатываться в отдельной ветке, которую нужно отправлять (push) в центральный репозиторий (origin) для создания резервной копии/для совместной работы команды
• Ветки функций создаются не на основе master, a на основе develop. Когда работа над новой функциональностью завершена, она вливается назад в develop
• Новый код не должен отправляться напрямую в master

Создание ветки функции

Публикация, получение, отслеживание

Завершение работы с веткой

• Когда в ветку develop уже слито достаточно нового кода для релиза (или подходит установленная дата предрелиза), от ветки develop создается релизная ветка, например, release/0.3.0
• Создание данной ветки означает начало следующего цикла релиза, в ходе которой новая функциональность уже не добавляется, а производится только отладка багов, создание документации и решение других задач, связанных с релизом
• Когда все готово, ветка release сливается в master, и ей присваивается тег с версией (r0.3.0). Кроме этого, она должна быть также слита обратно в ветку develop, в которой с момента создания ветки релиза могли добавляться изменения с момента создания ветки релиза
• Использование отдельной ветки для подготовки релиза позволяет одной команде дорабатывать текущий релиз, пока другая команда уже работает над функциональностью для следующего релиза
• Это также позволяет разграничить этапы разработки. Например, можно сказать: «На этой неделе мы готовимся к версии 1.0.0» и фактически увидеть это в структуре репозитория

Новая ветка release может быть создана с использованием следующих команд (ветки релизов основаны на ветке develop)

• Когда релиз готов к отправке, он сливается в master и develop, а ветка релиза удаляется (может быть сохранена при продуктовой разработке и необходимости поддержки нескольких релизов). Важно влить release обратно в develop, поскольку в ветку релиза могут быть добавлены критические обновления и они должны быть доступны в дальнейшем. Если ваша команда делает акцент на проверку кода, этот момент идеален для мердж-реквеста (MR, PR, Merge/Pull Request)
• Релиз помечается тегом равным его имени в ветке master. При инициализации может быть задан префикс для тега версии или указан в файле .git/config позже. Префикс тега не добавляется к release ветке

• hotfix — это единственная ветка, которая должна быть создана непосредственно от master. Как только исправление завершено, ветка hotfix должна быть объединена как с master, так и с develop (или с веткой текущего релиза), а master должен быть помечен обновленным номером версии
• Наличие специальной ветки для исправления ошибок позволяет команде решать проблемы, не прерывая остальную часть рабочего процесса и не ожидая следующего цикла подготовки к релизу. Можно говорить о ветках hotfix как об особых ветках release, которые работают напрямую с master

Ветка hotfix может быть создана с помощью следующих команд

Ветка hotfix объединяется как с master, так и с develop

Ключевые идеи, которые нужно запомнить о Git flow

• Данная модель отлично подходит для организации рабочего процесса на основе релизов
• Git-flow предлагает создание отдельной ветки для исправлений ошибок в продуктовой среде
• Модель может быть дополнена использованием Project-ID в названии ветки для интеграции таск-трекера: feature/VK-342-ci
• Модель Git-flow достаточна, проста и стандартна. Для добавления Staging и Pre-production веток используйте модель GitLab Flow, а для упрощения и личного проекта GitHub Flow

Последовательность работы при использовании модели Git-flow

User Flow — что это и как создать? Примеры

User Flow (от англ. user — пользователь, flow — поток), также известен как UX flow, юзерфлоу, пользовательский путь, пользовательский сценарий, путь пользователя — это блок-схемы отображающие пользовательский путь, порядок действий, которые проходит пользователь при использовании продукта. В User Flow визуально отображается каждый шаг, который проходит пользователь от точки входа до достижения конечной цели.

Блок-схема начинается с точки входа в продукт, например, главная страница сайта или карточка товара и заканчивается действием или результатом действия, например, регистрация или оформление заказа.

User Flow на русском пример
Элемент блок-схемы в User Flow

• Круг — начало / конец. Используется для указания начала и конца пользовательского сценария;
• Ромб — принятие решения. Ромб указывает на моменты принятия решения, где у пользователя есть выбор (например: да/нет, зарегистрироваться/без регистрации и т. д.), в зависимости от решения пользователя определяется следующий шаг;
• Прямоугольник— действие. Прямоугольники указывают на действия, которые пользователь должен выполнить, например войти, открыть корзину, отправить сообщение;
• Стрелка / узел — направление. Стрелки указывают направление пользователя от шага к шагу. Стрелки могут переходить последовательно от одного шага к другому, перескакивать шаги или возвращать назад на основе пользовательских решений.

Шаблоны User Flow

Подготовил для вас 5 шаблонов User Flow на русском языке с реальных проектов:

1. Интернет магазин
2. Доска объявлений
3. Новостной сайт / блог
4. Сервис услуг
5. Приложение доставки

Всего за 99 рублей

Купить шаблоны
(ссылки на шаблоны будут направлены на вашу почту сразу после оплаты)

Зачем нужен User Flow

1. Помогает создать удобный интерфейс

2. Помогает улучшить существующие интерфейсы

3. Продемонстрировать структуру проекта

4. Ускорить дальнейшую разработку

Как создать User Flow

1. Исследовать пользователей

2. Расписать цели и пути достижения

Сформировать цели и шаги по достижению данных целей. Простой пример:

Цель купить товар в интернет магазине, соответственно шаги: вход на сайт — переход в каталог — переход в карточку товара — добавление в корзину — переход в корзину — оформление заказа — оплата — выход.

Определив конечные цели для User Flow можно подстраивать путь под цели для создания лучшего пользовательского опыта, убирать или добавлять шаги, условия.

3. Визуализация целей и путей в User Flow

Когда создавать User Flow

Инструменты для создания User Flow

Ввиду того, что как инструмент User Flow достаточно простой в создании, выбор инструмента не является критичным вопросом. User Flow можно составить хоть на бумаге, доске. Но для удобства редактирования и доступа, лучше все же пользовать специализированными программами. К счастью их огромное множество.

Я предпочитаю FigJam, это внутренний инструмент Figma. Мне нравится работать сразу в одном окне и с User Flow и с прототипом. Стоит еще упомянуть такие решения как: Overflow, Axure, XMind, Miro. По ним есть куча туториалов, по которым можно быстро понять как работать в той или иной программе.

Примеры User Flow

Вот пример простого пользовательского сценария нашего проекта UNICORN BASE.

Цель клиента: Получить доступ к базе контактов. Путь состоит из следующих шагов:

1. Вход на сайт;
2. Подбор в каталоге (фильтрация);
3. Выбор карточки;
4. Проверка авторизации;
5. Регистрация;
6. Проверка доступа к контактам;
7. Описание тарифа;
8. Оплата тарифа;
9. Выдача доступа;
10. Полный доступ к каталогу

Пример User Flow проекта UNICORN BASE

Шаблоны User Flow

Мы подготовили 5 шаблонов User Flow с реальных проектов:

1. Интернет магазин
2. Доска объявлений
3. Новостной сайт / блог
4. Сервис услуг
5. Приложение доставки

Купить шаблоны
(ссылки на шаблоны будут направлены на вашу почту сразу после оплаты)

Начиная создание нового проекта с момента идеи и исследования клиента, но еще до момента начала разработки прототипа и дизайн макетов, важно создать пользовательский путь. User Flow является основой для требований к структуре и контенту проекта, логики переходов между страницами и окнами. Понимая потребности пользователей, команде гораздо вероятнее сделать успешный продукт, который будет удовлетворять этих самых пользователей.

Если вы хотите создать пользовательский путь самостоятельно, следуйте этому руководству и пробуйте. Так же я со своей командой могу помочь вам с разработкой User Flow в рамках услуги прототипирование.

От классной идеи до качественного продукта: зачем вам нужен User Flow

Люди из IT-тусовки очень хорошо знакомы с историями о “невероятно крутой идее, которая бы взорвала рынок и стала спасением для тысячи людей! Мы собрали команду, сделали MVP, начали привлекать пользователей и…”. Чаще всего на этом моменте глаза говорящего потухают и следует невнятное “В общем, не выгорело…”.

Я сама как сооснователь IT-стартапа слышала с десяток подобных историй. Мой собственный проект пришёл к своему печальному завершению тем же образом. Что же мы упускаем?

Я хочу поговорить об одной составляющей IT проекта, правильное использование которой поможет подняться на уровень выше своих конкурентов, увеличить шансы успешно запустить проект и удовлетворить пользователей.

Поговорим о User Flow.

Представьте ситуацию: на платформе для поиска знакомств вы находите подходящего партнёра, жмёте на кнопку “Отправить запрос”. и дальше ничего не происходит. Сервис не уведомляет об успешном отправлении запроса, не предлагает перейти в раздел отправленных. Пользователь в растерянности: что делать дальше? Разработчики явно не смотрели на процесс отправки запроса глазами покупателя. Им бы не помешало продумать User Flow.

User Flow – это визуальное представление пути пользователя. На практике он выглядит как схема действий, которые должен совершить пользователь с момента запуска приложения и до достижения своей цели. User Flow можно составить как для всего приложения в целом, так и для его отдельной функции.

“Идея – огонь, продукт нужно как можно скорее запускать, пока никто не сделал этого раньше! А детали… Детали доделаем в процессе.” В этот момент и запускается лавина проблем. Пренебрегать проработкой User Flow – ошибка, которая может стоить жизни продукта.

С User Flow вы создаете продукт, который удерживает пользователя.

Придумать крутую идею и реализовать ее – это большая и сложная работа.Но сделать интерфейс интуитивно понятным и комфортным – еще сложнее. Если упустить это, то отличная идея и большая работа пойдут прахом.

Пользователь выбирает приложения, которые упрощают ему жизнь. Наша цель – освободить его от рутины, например, от ручного подсчета прибыли и других операций, которые можно автоматизировать. Освободившееся время человек может отвести личной жизни, семье, отдыху. Тому, что действительно важно.

Мне нравится аналогия User Flow с поездкой. Ваша задача – добраться до Нью-Йорка чтобы купить себе новенький блестящий автомобиль. Наша – просчитать все возможные действия, которые вы будете совершать от сбора чемоданов (вы не забыли билеты? если да, то что тогда делать?) до приземления в аэропорту Большого Яблока. Увидеть все возможные ошибки, которые вы как пользователь можете совершить, уберечь вас от них, или придумать способ их решения. Согласитесь, неприятно уже в аэропорту обнаружить, что вы забыли взять с собой билеты.

User Flow помогает выявить скрытые на первый взгляд моменты, о которых мы не задумываемся в момент прорабатывания идеи. Мы можем не вспомнить о них при разработке продукта.

Возьмем, например, сервис для поиска работ фрилансерами. На словах действие звучит так: исполнитель просмотрел заказы – откликнулся на один – выполнил – отправил. Что может быть проще? Но когда начинаешь прописывать каждый шаг детально, возникают условия. А как пользователь найдет заказ по своей специальности? Нужен фильтр. А если у него возникли вопросы по заказу? Добавить возможность задать вопрос без отклика. А что произойдет после того, как откликнулся?

Эти детали играют решающую роль в том, будет опыт использования продукта позитивным или негативным, и будут ли его вообще использовать.

Кейс из нашей практики: мы создавали личный кабинет пользователя сервиса. Изначально задача казалась простой. MVP уже был собран на коленке и состоял из четырех экранов. Затем мы поняли, что половина функций требует запроса в техническую поддержку. Пользователю нужно тратить время на письма, а технической поддержке – отвлекаться на любую мелочь, вместо того, чтобы решать действительно сложные проблемы. Мы пришли к тому, что все эти функции может совершить пользователь. Это гораздо быстрее и проще для всех. Пользователи довольны, техподдержка занята своим делом.