Workflow

Привет, в предыдущей статье «Why code review matters?» я анонсировал статью про воркфлоу. Вот она!

1. Техпроцесс

В каждой команде при разработке какого-либо продукта есть свой техпроцесс, иначе говоря тот самый воркфлоу — тот путь, который проходит задача через руки всех причастных к ее разработке. Однако, сегодня я хотел бы остановиться на том, как это было в нашей команде, как стало и как будет дальше. Ведь, если вы делаете серьезный продукт, а я наш таковым безусловно считаю, то вы рано или поздно столкнетесь с проблемами масштабирования и удобства разработки. Мы в Action Digital хотим, чтобы наш продукт был не только удобен пользователям, но и был удобен нам в процессе разработки. В конце статьи я приведу пару докладов, которые тоже стоит посмотреть или пересмотреть.

1.1 Как было (когда я пришел в команду)

Все было довольно просто:

  • PC
  • Visual Studio (далее VS)
  • Локально grunt

Сидишь себе в одном фича-бранче с бэкендером и выполняешь задачку. Как только ты напишешь код, он сделает пул и обновит страничку — новая статика от тебя прилетела.
Чуть сложнее, когда бэк внесет изменения — ты сделаешь пулл, а потом перезапустишь VS, пожалуй, самый муторный процесс. А еще бывает, что «А…ну тебе надо обновить референсы» или «Ну да, бывает студия просто падает» — ну спасибо, MS.

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

Не секрет, что у нас проект написан на AngularJS и C# — фронт и бэк соотвественно. Идея о том, что необходимо разделить фронт и бэк витала в воздухе еще до моего прихода в команду. Но однажды легла на мои плечи. В общем-то, решение проблемы было быстро найдено — все фронтовые шаблоны были положены в Template Cache, что позволило их кэшировать (они теперь лежат в виде строк в js), а также местами увеличить скорость загрузки страниц (нет больше дополнительных запросов для подгрузки шаблонов, они все доступны после загрузки Angular). Но это не все.

1.2 Как стало (когда пришел в команду Vitaly Glibin)

Когда в команду пришел шеф (читай Vitaly Glibin), то он наотрез отказался от использования PC, в качестве второго средства для разработки, так и появилось решение в виде локального фронтового сервера (на основе обычного плагина grunt-connect).

При запуске отдельной таски в grunt мы поднимаем локальный сервер, который отдает актуальную статику. В проекте на уровне шаблонов разведено подключение статики. Если это девелоперский стенд, то статика грузится с локального хоста. Имя его вы определяете однажды и на все время, например, static.dev это 127.0.0.1. Чтобы все заработало, необходимо в файле hosts (например в Windows) прописать матчинг этого домена на локальную машину, а в месте подключения статики в шаблоне проекта указать:

<script src="http://static.dev/build/bundle.js"></script>

Таким образом в режиме разработки ваши скрипты будут грузиться с локального хоста и будут всегда актуальными. При наличии API от бэкенда фронтендер может самостоятельно дальше вести разработку.

Да, еще один момент, до некоторого времени все билд-скрипты хранились в репозитории, что изрядно раздражало, но было необходимо, чтобы у бэка всегда был актуальный фронтенд. Эта проблема была решена настройкой git hooks, один из которых просто запускал сборку скриптом при git pull у бэкендеров.

1.3 Что изменилось?

Как видите, с пониманием того, что разработка бэкенда и фронтенда нашего приложения тесно связаны друг с другом мы начали изменять наш воркфлоу, чтобы он соответствовал новым требованиям команды.

2. Continuous Integration

Практически в то же время (год назад), был подключен в воркфлоу Continuous Integration (далее CI). Это позволило нам автоматизировать выкладку нашего кода.

2.1 Преимущества

Однажды правильно настроенная CI позволяет решать вам задачи в один клик:

  • Собрать свой фича-бранч? — Пожалуйста
  • Собрать develop? — Пожалуйста
  • Собрать релиз-кандидат? — Нет проблем
  • Собрать релизную ветку? — Держи, братюнь
  • Запустить smoke-тесты по расписанию? — Будет сделано
  • Прогнать все виды тестов, какие только возможно? — Легко

2.1.1 Преимущества разработки

Каждый поднятый стенд со своим доменом вида
fn-XXXX.%YOUR_COMPANY_HOST% доступен еще с префиксом dev-. Если вы обратились к стенду с таким доменом, то подгружаться все скрипты будут с локального хоста, я об этом говорил в пункте 1.2

2.1.2 Преимущества тестирования

Каждая задача теперь тестируется в 4 этапа, чтобы ни один баг не прошел на прод:

  • Фича-бранч (99% проблем отлавливаются тут)
  • develop (очень редко что-то всплывает, практически никогда)
  • release (аналогично)
  • prod (да и тут тоже)

2.1.3 Github flow

Код лежит на github. Еще раз пересмотрел Github Flow и убедился, что да у нас именно он. Клево, когда есть возможность делать ревью кода после создания PR разработчиком. Я лично очень рад такому воркфлоу, поскольку он позволяет другим членам команды быть в курсе того, что происходит на проекте, чем занимались вы в этой задаче, помочь вам найти ошибки или более оптимальные решения вашей задачи.

2.2 Недостатки

В виду того, что девелоперским стендам требуется хорошенький апгрейд, прямо сейчас сборка стенда может занимать от трех минут (если кроме вас никто ничего не собирает, а это бывает практически никогда) до 12 (было тут как-то у меня), а в среднем сборка среды занимает минут 7–8.

3. Светлое будущее

Прямо сейчас проект плавно переходит к трехслойной архитектуре. Эта идея инициирована Vitaly Glibin. Передаю ему слово.

3.1 Трехслойная архитектура

В текущей исторически сложившейся архитектуре осталось несколько вещей, которые мешают полноценно разделить frontend и backend.

  1. Обвязка сайта (aka layout) сделана в .cshtml шаблонах, что затрудняет работу с ней, так для ее изменения потребуется пересборка проекта на CI, а подсветка синтаксиса возможна только в VS или плагине для Sublime. А мы ведь хотим свободу выбора инструментария.
  2. Роутинг также рулится на сервере, поэтому если нужно сделать,
    например, лендинг, то нужно просить бэкенд-разработчика сделать контроллер и вьюху, ведь не лезть же frontend-разработчику в C# код?

Я уже не говорю про работу с cookies и прочими околобраузерными штуками.

Поэтому, в больших проектах разделение frontend и backend происходит и на серверной стороне в виде специальной “прослойки” на любимом и, как правило, скриптовом языке (NodeJS, Python, etc.).

Задача этой “прослойки” разруливать роутинг, заниматься шаблонизацией, а также ходить на бэкенды за данными, обрабатывать их и отдавать на клиент в нужном для frontend-разработчика виде. Такую архитектуру принято называть трехслойной (браузер <-> front-сервер <-> backend).

3.2 Чего ожидаем

Таким образом, основной задачей backend-разработчиков становится написание REST-сервисов с удобным покрытием тестами, а все что касается браузера и подготовки данных для него — обязанностью frontend-разработчиков.

Кроме этого, у frontend-разработчика появляется возможность удобно писать моки для интерфейсов: мы сразу пишем нужные урлы для получения данных, а с сервера отдаем готовые мок-данные, которые потом прозрачно подменяются запросами на backend без необходимости переписывать клиентский код.

4 Несколько докладов по теме

Михаил @ya_mishanga Трошев — общий цикл разработки

Slava Oliyanchuk — Яндекс.Авто 2.0 на Node.js

Sergey Sergeev — Роль разработчика интерфейсов в продукте

The end

Спасибо, что добрались до этого места. Поделитесь в комментариях о том, что бы вы добавили или оптимизировали, может быть, в этом процессе.