Инфраструктура переднего плана кажется деспотичной. Зачем нам еще больше усложнять интерфейс? Что ж, ответ: это сложно. За последние несколько лет я опросил около 20–30 разработчиков и обнаружил следующее.

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

Почему? На это есть множество причин, но лучшая причина, которую я могу придумать, - это то, что все очень сухо и люди хотят заняться написанием кода. Это, вероятно, нормально, а во многих случаях даже желательно. Однако есть компромиссы.

Передача вашей инфраструктуры через стену другой команде может привести к избыточности и неидеальному процессу. Чтобы определить процесс, вам нужно знать, как он работает.

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

  • Разработка приложений
    - Компоненты / Руководство по стилю
    - Управление версиями
    - Объединение
    - Общие конфигурации
  • Локальная разработка
    -     Настройка среды
    - Веб-сервер
    - Горячая перезагрузка модуля
  • Развертывание
    - непрерывная интеграция
    - Доставка
  • Мониторинг и отслеживание событий
    - Мониторинг ошибок
    - Ключевые показатели эффективности

Имейте в виду, что я формирую это на основе стека, который я использую профессионально, который основан на React и Node. Я пытался держаться подальше от незнакомой территории. Я не хотел, чтобы это превратилось в разговоры о «лучших практиках» для фреймворка «x». С учетом сказанного, вы можете применить этот процесс к любому набору технологий.

Это во многом основано на работе, которую я проделал в Smartling, где я являюсь фронтенд-лидом. Наша команда много сделала для улучшения нашей инфраструктуры за последние четыре года. Мы продолжаем улучшать наш процесс ежедневно.

Разработка приложений

Компоненты

Компоненты являются строительными блоками всех внешних приложений. Они поощряют повторное использование и композицию. Они мешают разработчикам изобретать велосипед.

Даже если вы планируете использовать фреймворк с открытым исходным кодом, вам все равно следует обернуть компоненты. Определение собственного API позволяет отказаться от деталей реализации, не нарушая контрактов.

Руководство по стилю компонентов

Теперь, когда у вас есть библиотека компонентов, вы должны разместить ее, чтобы группы могли наблюдать и утверждать изменения. Для этого вы можете использовать руководство по стилю, например Storybook.

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

Компонент управления версиями s

Если вы собираетесь использовать свои компоненты более чем в одном проекте или устройстве, управление версиями компонентов является обязательным.

Для версии ваших компонентов вам понадобится частный реестр модулей, например NPM Enterprise.

Сначала кажется, что управление версиями замедлит вас. Обновление с помощью кнопок (монолит) для всей платформы выглядит быстрее. На самом деле это кошмар QA. Это также требует, чтобы все команды были готовы к обновлению сразу, что может быть непросто.

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

Комплектация

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

Многие производители обещают нулевую конфигурацию, но я не испытал этого на собственном опыте. В какой-то момент вам придется запачкать руки. Бесценно иметь рядом кого-то, кто знает, как все это работает.

Бандлеры - не единственный способ решить некоторые задачи. Некоторые люди предпочитают использовать решения, ориентированные на задачи, такие как Gulp или Grunt. Несмотря на то, что они считаются «олдскульными», нельзя отрицать их простоту.

Во многих смыслах связывание может быть отравой для Front End разработки. То, как мы создаем Front End, стало очень сложным, и мы, вероятно, могли бы отступить и провести некоторую переоценку.

Вместе с тем, сборщики пакетов решают множество проблем, которых невозможно избежать. Вы не хотите вручную ссылаться на файлы, которые необходимо объединить и уменьшить? Вам понадобится упаковщик. Хотите воспользоваться горячей заменой модуля? Вам понадобится упаковщик. Вы хотите беспрепятственно взаимодействовать между модулями CJS и модулями ES6? Упаковщик вам обязательно понадобится!

Общие конфигурации

Опыт разработчика - ключ к написанию хорошего программного обеспечения. Обеспечение единообразия при переключении проектов помогает облегчить когнитивную нагрузку переключения контекста.

Совместное использование конфигураций между проектами может помочь обеспечить согласованность. Общие конфигурации отвечают на такие вопросы, как «В какой версии JavaScript мы пишем», «Какие ошибки линтинга нас волнуют» или «На какие версии браузеров мы ориентируемся».

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

Местное развитие

Настройка среды

Ваша первая цель должна заключаться в создании локального процесса разработки, который требует минимальной установки. Вся установка займет около 10–15 минут.

Веб сервер

Для загрузки веб-сервера должен использоваться сценарий npm из одного слова. yarn start или npm start. Сам сценарий может содержать цепочку команд, например: yarn webpack-dev-server && yarn etc.

Приложения могут обслуживаться чем-то таким простым, как webpack-dev-server. Однако, если вы не пишете библиотеку пользовательского интерфейса без сохранения состояния, вам потребуются некоторые данные. Для этого вам понадобится какой-то прокси. Для меня золотое правило состоит в том, что обращение к этому прокси должно быть без проблем. Разработчикам не нужно редактировать файлы конфигурации, чтобы заставить его работать.

Чего вы абсолютно не хотите, так это принуждения разработчиков к созданию среды, которой они не владеют. Это только вызовет головную боль для вашей команды переднего плана и увеличит их рост. Я упорно работал над тем, чтобы в Smartling мы ускорили переход новых разработчиков от «git pull» к активному кодированию за несколько часов.

Горячая перезагрузка модуля

Помимо быстроты настройки и запуска, вы также хотите, чтобы фактическая разработка была быстрой. Вот тут и появляется горячая перезагрузка модуля.

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

Развертывание

Непрерывная интеграция

После того, как разработчик объединился с мастером, ему нужно передать свой код пользователям. Не так просто загрузить все в корзину S3. Перед развертыванием вам нужно будет собрать и проверить свои изменения. Вот тут-то и пригодится CI-сервер.

CI-серверы бывают самых разных видов. Некоторые требуют большой настройки разработчика, как Jenkins. Некоторые будут более под ключ, например Travis CI или Codeship.

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

В Smartling мы используем три типа активов. Модули NPM, веб-компоненты и приложения. У каждого свои требования. Например, модули npm требуют от нас публикации.

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

Доставка

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

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

Даже если Front End не владеет напрямую веб-инфраструктурой, команда должна хорошо это понимать. Они должны убедиться, что у ресурсов есть правильные заголовки или что содержимое сжато с помощью gzip.

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

Мониторинг и отслеживание событий

Отслеживание ошибок

Когда ваше звездное приложение станет доступно миллионам людей, вы захотите убедиться, что все идет не так, как надо. Вот почему вам понадобится мониторинг, чтобы вы знали, что происходит. Существует множество решений, многие из которых, такие как Sentry, Rollbar или TrackJS, требуют очень небольшой настройки.

Ключевые показатели эффективности (KPI)

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

Для этого вам понадобится что-то, что может обрабатывать и агрегировать события по миллионам записей. Некоторые инструменты, которые следует учитывать, - это New Relic Insights или даже Google Analytics.

Заключение

Ну вот и все. Звучит много, но цель должна заключаться в уменьшении трений между написанием кода и развертыванием приложений. Если вы не подойдете к этому целостно, вы получите много избыточности.

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

Мой совет: найдите самые элегантные решения, чтобы уменьшить сложность. Расставляйте приоритеты в обслуживании (обновлениях, ошибках и т. Д.), Даже если это неудобно (потому что это всегда неудобно). Работы по разведке и добыче будут способствовать развитию переработки и сбыта. Самое главное, не воспринимайте это как должное. Ты пожалеешь об этом.