Документ обсуждает внедрение практики непрерывной интеграции в разработку программного обеспечения, акцентируя внимание на совместной работе front-end и back-end команд. Он выделяет проблемы традиционных процессов, такие как необходимость высококачественного технического задания и сложности с версткой, и предлагает решения, включая использование full-stack разработчиков и автоматизацию сборки. В результате таких подходов ожидается улучшение качества продукта, уменьшение сроков разработки и возможность гибкого реагирования на требования заказчиков.

1. Continuous Integration,
или как мы подружили
Front-end и Back-end

3. Почему?

4. Типовой процесс разработки
Проектирование
Front-end
Back-end
Продукт
Дизайн

5. Типовой процесс разработки
Проектирование
Дизайн
Front-end
Back-end
Продукт
.PSD
.html .css .js
Прототип

6. Что в этом плохого?
— Экспоненциально растущие риски
— Необходимость килограммового ТЗ
— Невозможность применять Agile

7. Типовые проблемы с “версткой”
— Не все макеты
— Логика ломается из-за скорости работы
back-end
— Верстка расползается на реальных
данных

8. Кто виноват?
Никто
— Спроектировали то что знали
— Нарисовали то что спроектировали
— Сверстали все макеты
— Интегрировали все что было

9. Что делать?
— Возврат к этапу с ошибкой и правят
— На текущем этапе “колхозят” как умеют
— Full-stack разработчик
— Работать сразу над конечным продуктом,
избегая промежуточных артефактов

10. Возврат на предыдущие этапы
Минусы
— Колоссальные затраты
— Недоступность исполнителей
Плюсы
— Можно освоить гигантские бюджеты

11. “Колхоз”
Минусы
— Требуется доп.квалификация сотрудника
— Низкое качество конечного продукта
Плюсы
— Дешево

12. Full-stack разработчик
Минусы
— Таких не существует
— Низкое качество проектов
— Высокие риски связанные с
исполнителем
Плюсы
— Очень просто для менеджера

13. Отказ от артефактов — тренды
— Дизайн в браузере
— Continuous Integration

14. “Непрерывная интеграция
(CI, англ. Continuous Integration)
— это практика разработки программного
обеспечения, которая заключается в
выполнении частых автоматизированных
сборок проекта для скорейшего выявления и
решения интеграционных проблем”.
© Википедия

15. Что значит CI для Front-end
разработчика?
— Применять автоматизацию сборки
— Верстать сразу на CMS/Framework

16. Как это внедрить в 1C-Bitrix
— Применять шаблонизатор (Twig)
— Готовить back-end и данные ДО front-end

17. Front-end CI для 1С-Bitrix — MVC
M C V
Модуль Компонент Шаблон

18. Front-end CI для 1С-Bitrix — Шаблоны

19. Структура
— Исходники front-end в том
же .git репозитории, что и
сборка Bitrix
— Все “исходники” вне
публичной папки
— Grunt собирает assets
сразу в шаблона Bitrix

20. Фактические изменения для
Front-end разработчика
— Нужен локальный web-сервер для работы
— Работа с Twig вместо HTML
— Grunt/Gulp собирает сразу “внутрь” Bitrix
— Тесная работа с back-end разработчиком

21. Что это дает?
— Улучшение качества продукта
— Командная работа
— Уменьшение сроков разработки
— Возможность гибко реагировать на
изменяющиеся требования (Agile)
— Continuous Deployment

22. Уменьшение сроков — как было
Дизайн
Интеграция
+ Back-end
Front-end
Прототип
QA

23. Уменьшение сроков — получше
Дизайн
Front-end
Прототип
Back-end
QA

24. Уменьшение сроков — идеально
Дизайн
Front-end
Прототип
Back-end
QAQA

25. Гибкие методологии — Agile
Дизайн
Front-end
Прототип
Back-end
QAQA
x N = Agile

26. Так зачем нам все это?
Чтобы делать
более крутые проекты
с меньшими усилиями

27. Спасибо за внимание
Подрубный Константин
email: support@wlbl.ru
fb: http://fb.com/podrubny
web: http://wlbl.ru/