В прошлом Psono.com работал на Odoo v11. Odoo — это отличная CMS, но, как мы узнали, обновления даются нелегко. Особенно много проблем возникло с модулем сайта во время тестирования. Odoo v11 достигнет конца своего жизненного цикла к концу 2020 года, поэтому нам пришлось искать решение.
Мы обдумали разные варианты: обновиться до Odoo v13 и вручную мигрировать весь контент и кастомизации, нанять кого-то для миграции за нас или полностью перейти на новую CMS. Мы решили полностью мигрировать Psono.com и продолжим использовать v11 за файрволом, пока не мигрируем его позже (мы пока не решили, когда именно).
Причины, по которым мы приняли это решение:
- Для Psono.com у нас очень небольшой объем контента, который нужно мигрировать. В основном это несколько блог-постов.
- Миграция на Odoo v13 создаст ту же проблему через два года, когда v13 достигнет конца жизненного цикла, но уже с большим объемом данных для миграции.
- Мы были не слишком довольны возможностями кастомизации веб-сайтов в Odoo v11. Все крайне сложно, так как их шаблоны хранятся в базе данных.
- Затраты. Найм кого-то для миграции обойдется нам минимум в 5000 долларов США, а скорее всего, больше.
- Сообщество Odoo было очень активным, но с развитием в последние годы смен лицензий и миграции функционала и плагинов на платные решения, за стену оплаты, сообщество умерло.
- Psono.com — это в основном статический сайт со статическим контентом. Если нам понадобится динамический контент, мы сможем вытащить его через API.
Путь
Приняв решение о миграции, мы должны были выбрать фреймворк. Есть классические фреймворки, такие как hugo, которые мы уже использовали, но их функциональность ограничена. Ища альтернативы, мы нашли несколько решений в мире node / react.
Я хотел бы написать здесь "отличные решения", но не думаю, что что-либо в текущем разорванном состоянии фронтенд-разработки заслуживает этого звания. Разорванном, спросите вы? Помните времена, когда разработчики могли создать веб-сайт с index.html и тегом script для загрузки jquery и начать разработку веб-сайтов? Теперь вам нужен npm или yarn, вам нужно понимать package.json, скрипты webpack, современные фреймворки, такие как angular или react, которые все приносят свои собственные клиенты. JSX или Typescript. Функции, как hot reloading, не работают надежно (файл не мониторится, некоторые изменения требуют полного перезапуска, или hot reloading срабатывает слишком рано, так что приходится вручную обновлять страницу). В итоге вы убиваете сервер разработки и ждете минуты, пока он снова запустится (по крайней мере, в больших проектах). Я скучаю по временам, когда достаточно было нажать F5, и все работало без проблем! Не говоря уже о новых фреймворках или инструментах каждые полгода, где старые инструменты ежедневно забрасывают. Я мог бы легко заполнить страницы своим нытьем про текущее состояние фронтенд-разработки. Но вернемся к теме.
В отсутствие разумных альтернатив, лучшими вариантами (на момент написания этого текста) были next.js и gatsby. По крайней мере, так их продвигали некоторые статьи. Оба одинаково популярны, если сравнивать звезды на Github или коммиты. Единственная разница, которую мы могли заметить во время предварительной оценки, это необходимость серверного компонента для next.js, в то время как gatsby создает статические сайты (Пожалуйста, не убивайте меня, если есть возможность запустить next.js без активного сервера! :D)
Итак, мы немного поиграли с Gatsby, и он выглядел хорошо. Следующим шагом мы искали подходящую тему. Gatsby — это "новая" утилита, поэтому все найденные нами темы находились в очень базовом состоянии. Через тридцать минут и тридцать долларов у нас была визуально привлекательная тема, которая покрывала хотя бы некоторые из необходимых компонентов, и мы начали ее модифицировать.
На сегодняшний день можно выбрать среди множества хостинг-провайдеров, таких как Firebase, netlify, Cloudflare, Vercel, простое хранилище в GCP или AWS Cloudfront, собственные серверы, docker-контейнеры, работающие на Kubernetes (должен был это упомянуть!), ... (Помните старые времена, когда можно было арендовать веб-пространство за $5 в месяц с PHP и MySQL базой данных :D ... но это для другой статьи...)
После их сравнения, прочтения некоторых обзоров и проверки возможных сочетаний (например, Cloudflare перед Firebase) мы изначально попробовали Cloudflare. Как огромные поклонники их сервиса, это был естественный выбор, но, к сожалению, их утилита wrangler имела проблемы. Вначале она всегда выдавала ошибку, а затем мы не могли пройти аутентификацию ... Первоначальные ошибки исчезли на следующий день (возможно, новая оболочка bash помогла), но проблема с аутентификацией осталась. Думаю, я мог допустить какую-то ошибку и сдался после нескольких часов чтения документации и попыток разных решений.
Netlify был другим кандидатом, но вам приходится либо подключить его к git-провайдеру и позволить им строить сайт (мы хотели использовать GitLab CI), либо вручную загружать выходные данные сборки. Возможно, у них есть где-то возможность загружать выходные данные через API, но я не смог найти. Альтернативой был бы репозиторий, куда мы на самом деле пушим выходные данные сборки, но это казалось ненужным усложнением... Еще одна проблема для меня - их модель ценообразования. Они берут плату за каждого участника (!!!), и это довольно существенно. Имейте в виду, что это за статический веб-сайт. Такие фразы, как "4× пропускная способность", напоминают о плохих временах "честного использования веб-хостинга", когда людей отключали за чрезмерное использование...
Четвертой службой, которую мы попробовали, был Firebase (бесплатный для нашего объема трафика и запросов), и все работало из коробки. Их возможности перенаправления немного ограничены, поэтому сопоставление старых URL с более красивыми стало немного утомительным, но после нескольких правил перенаправления все заработало. Их ценообразование кажется разумным, и вы платите за ресурсы сервера. Следует избегать всех их дополнительных сервисов, чтобы избежать зависимости от поставщика, но нам нужно было только хостинг.
Мы также кратко рассмотрели vercel, но их требование войти через аккаунт Github и затем позволение "Действовать от моего имени" выбило меня из колеи еще до регистрации.
Блог был наиболее сложным для миграции. В конце концов, мы вручную перенесли весь контент. Это не то, что стоит делать с большим блогом, но у нашего было всего пятнадцать постов. Gatsby поддерживает несколько механизмов, но нам хотелось что-то простое, что мог бы сделать человек без технического образования. Мы решили использовать markdown, поэтому нам пришлось разобраться, как заставить gatsby читать страницы в этом формате. Сам механизм занял у нас около полудня вместе с обработкой изображений. Хорошая тема для блога и изображения заняли еще полдня.
После миграции всего контента и серьезной модификации темы мы автоматизировали наше развертывание с помощью Gitlab CI, так что простой пуш триггерил нашу сборочную линию и развертывал все на Firebase.
Почему Gitlab, а не Github? Github имеет преимущество по историческим причинам. На данный момент у них как минимум 80% всех разработчиков и проектов. Однако Gitlab предоставляет больше функций. Вот почему в прошлом мы решили использовать Gitlab, так как в Github годы не было реального развития функционала. Это кардинально изменилось после приобретения Github Microsoft, и Github Actions - значительный шаг вперед, но у Github еще долго впереди, если он хочет догнать Gitlab. Для нас, тех, кто размещает все свои проекты на Gitlab, это был естественный выбор для этого проекта.
Итог
И вот где мы сейчас находимся:
- Gatsby как CMS
- Коммерческая тема
- Блог на основе Markdown
- Gitlab CI для автоматизированного развертывания
- Хостинг на Firebase
Мы довольны этим результатом, и новый сайт выглядит гораздо лучше!
