В течение последних нескольких лет я поддерживал монорепозиторий для своей основной работы. Этот репозиторий включал полное приложение Laravel и полное приложение Angular (сначала AngularJS, позже Angular). Все это хорошо работало вместе, но стало сложнее поддерживать, поскольку команда разработчиков со временем меняла состав и обязанности. В этом посте я проведу вас через старую ситуацию, через промежуточный сценарий к текущей архитектуре. Поскольку большинство архитектурных решений очень сильно привязаны к конкретному варианту использования и определенно не работают для всех, я четко объясню, какой у меня был выбор и почему я решил сделать это определенным образом.

В этом посте я пройду эти этапы:

  1. Моно-репозиторий: Laravel + AngularJS
  2. Моно-репозиторий: Laravel + Angular (от 6.x до новейшей версии)
  3. Два репозитория: размещены для обеспечения обратной совместимости с предыдущим этапом
  4. Два репозитория: размещены отдельно

Этап 1: Моно-репозиторий с Laravel и AngularJS

Этап 1 — это этап, на котором я учился создавать готовые к эксплуатации приложения. Это означало, что я устанавливал наименьшее количество «внешних» подключений. На мой взгляд, внешнее соединение имело дело с двумя отдельными физическими местами, в которых я запускал какой-то код. На этом этапе Laravel обслуживал очень простой блейд-файл, который, в свою очередь, загружал приложение AngularJS. Это было довольно просто, так как AngularJS можно было очень легко использовать в качестве встраиваемого внешнего интерфейса. Так что все, что мне нужно было сделать, это заставить сервер обслуживать правильный HTML-код в браузере, а оттуда взял на себя AngularJS и загрузил приложение для посетителя.

На этом этапе я уже работал с вызовами API, а это означало, что Laravel отвечал за обслуживание базового HTML для загрузки AngularJS, а также мог отвечать на вызовы API правильными данными. Это работало очень хорошо в течение очень долгого времени (2 года).

Этап 2: Моно-репозиторий с Laravel и Angular (от 6.x до новейшей версии)

На этапе 2 я много узнал о JavaScript и оптимизации. Поскольку AngularJS начал стареть, а приложение становилось все больше и сложнее в управлении, я решил перейти на Angular, который в то время был версии 6. Я создавал другие приложения с помощью нового фреймворка Angular в сочетании с Laravel и был очень впечатлен скоростью загрузки приложения. Для полной загрузки AngularJS требовалось несколько секунд, иногда до 6 секунд. Это было неприемлемо, но мне нечего было оптимизировать… приложение было готово к обновлению.

На этом этапе я перенес все приложение AngularJS на Angular. На это ушло около 4 месяцев, но это время того стоило. Приложение загрузилось очень быстро и управлять им стало намного проще. Поскольку все было на TypeScript, а не на JavaScript, у нас было меньше ошибок во время выполнения, а приложение было построено с использованием модулей и компонентов. Это означало, что мы могли очень легко фрагментировать и лениво загружать модули, что сделало приложение намного более легким.

Вроде бы все отлично, но пока это только на 2 этапе из 4, так что же случилось? Итак, в команде изменились участники и обязанности. Раньше я управлял Laravel и приложением Angular (и AngularJS). Но я пытался больше двигаться в сторону Laravel, а не в сторону Angular. Поэтому мой коллега взял на себя некоторые из моих задач, когда дело дошло до разработки внешнего интерфейса. Мой монорепозиторий со сложными и нестандартными задачами по сборке ушел в историю.

Этап 3. Два репозитория: размещены для обеспечения обратной совместимости.

Этап 3 странный, но это тоже большой шаг в правильном направлении. Мы решили полностью исключить Angular из репозитория Laravel. Это дало много больших преимуществ, но самым важным было то, что использование Angular CLI стало намного проще. Это означало, что мы могли начать использовать «ng serve» впервые. Это упростило разработку приложения Angular.

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

Во второй части заголовка этого раздела упоминается, что два приложения были размещены для обеспечения обратной совместимости. Это звучит странно, но позвольте мне объяснить, почему я это сделал. Это было сделано по той простой причине, что не требовалось никакого нового или обновленного кода в приложении Laravel. По сути, у нас было два разных приложения, которые каким-то образом нужно было объединить, чтобы снова стать одним для производственной среды. Поскольку приложение Laravel зависело от наличия приложения Angular. Laravel по-прежнему обслуживал и API, и приложение Angular в одном. Это означало, что мне пришлось написать сценарий bash для выполнения полуавтоматического развертывания, когда приложение Angular было создано в моей локальной среде, затем заархивировано в tar-файл, загружено на сервер через SSH, извлечено и, наконец, очищено. было сделано. Да… очень сложно, но идеально подходит для упрощения работы с приложением Angular.

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

Этап 4: Два репозитория: размещаются отдельно

Стадия 4 счастлива. Я наконец-то добрался сюда после почти 4 лет работы над рабочими процессами «незавершенного производства». Так что же такое 4 стадия? Что ж, на этапе 4 все делается с учетом удовлетворения разработчика. Автоматическое тестирование и автоматическое развертывание. Этап 4 — это полноценный конвейер CI/CD, поэтому любой может внедрить изменения самостоятельно.

Вам может быть интересно, как я дошел до этого этапа. Что ж, начнем с Netlify. Я открыл для себя Netlify совсем недавно, после того как весь Twitter был в восторге от него в течение очень долгого времени. Я понимаю, что очень опоздал с шумихой по этому поводу, но до недавнего времени у меня никогда не было возможности взглянуть. Поэтому просто для наших внутренних целей я подписался на Netlify и поставил на него наше приложение Angular. В основном это использовалось для тестирования и просмотра предварительных версий развертывания, когда на GitHub поступали запросы на вытягивание. Проделав это около 3 недель, я подумал: «Эй, почему мы не используем это в продакшене?». Итак, я приступил к работе, и через неделю я был готов. Приложение Angular теперь размещено на Netlify, и любые изменения развертываются автоматически. Это означает, что мне не нужно беспокоиться о развертывании изменений, а мои коллеги могут развертывать свои изменения, запускать A/B-тесты и показывать предлагаемые ими изменения остальной команде.

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

Вывод

Так стоило ли это огромное изменение всего? 1000% да! Я смог дать своим коллегам возможность постоянно вносить изменения в рабочую среду без простоев и помощи со стороны коллег. Таким образом, это изменение сделало работу над приложением Angular еще раз потрясающей. Одно только это изменение полностью стоило всей работы, которую я вложил в него, но это еще не все. Интерфейсный сайт также стал быстрее. Постобработка Netlify позволила этому веб-сайту работать намного лучше по сравнению со старой ситуацией, и баллы маяка доказывают это (было от 7 до 45, а теперь 67). Это все еще не самый высокий балл, но, по крайней мере, теперь мы можем очень легко довести его до 100%.

Мне понравилось писать этот пост! Я очень рад, что мне удалось создать все это за годы проб и ошибок, чтобы сделать нашу платформу лучше и способствовать удовлетворению разработчиков при исправлении ошибок и создании новых функций. Спасибо, что дочитали до этого места! Если у вас есть какие-либо вопросы или вы просто хотите поздороваться, вы можете связаться со мной в Твиттере.

Опубликовано: 13 ноября 2019 г.

Первоначально опубликовано на https://roelofjanelsinga.com.