# Github Pages

В марте 2011 года я начал использовать Jekyll для своего сайта: [Сменил wordpress на jekyll](https://www.juev.org/2011/03/06/jekyll/)

Для деплоя своего сайта на сервера Амазона долгое время использовал [s3_website](https://github.com/laurilehmijoki/s3_website). Очень функциональный gem, много чего умеет, но имеющий один довольно неприятный недостаток. Для его использования необходимо иметь как ruby, так и java, так как в его коде используются groovy скрипты.

Ну используется, и что такого, спросите вы? Проблема заключается в поддержании рабочего окружения в актуальном состоянии. И к примеру, при обновлении версии ruby мы уже не сможем так же просто поднять версию java. Более того, как оказалось, s3_website не поддерживает версии java выше 8-й. И именно этот gem создавал мне массу неудобств.

В субботу, после того, как попытался опубликовать [Ссылки #10](https://www.juev.org/2019/01/26/weblinks-10/), оказалось, что я допустил ошибку в заголовке статьи, что сломало сборку. Не сразу разобравшись в чем дело, доломал сайт окончательно, выведя из строя тот самый s3_website за счет обновления используемой версии Ruby. В конце концом мне надоело решать проблемы с s3_website, и я его просто заменил на стандартный gem деплоя в Travis, что использовался для сборки сайта. Проблема была устранена, но в результате на сервера Амазона попала ломанная версия сайта и при этом была закеширована там на сутки.

Потратил еще несколько часов на решение создавшейся проблемы, но, что странно, даже инвалидация объектов в CloudFront не выводила объекты из кеша. Решился на миграцию сайта к другому хостеру. Только какому? Создавать свой сервер для статического сайта не хотелось, других вариантов не просматривалось. Мигрировать на s3, с потерей ssl тоже не хотелось. И тут вспомнил про Github Pages.

Изменить деплой с Travis на Github Pages заняло порядка 5 минут, плюс еще 10 на чтение документации. И уже через 15 минут чистого времени получил работающий сайт на серверах Github. В тот же день провел несколько экспериментов по использовании Github в качестве сборщика сайта, в замен Travis, но как оказалось, мой сайт к этому на тот момент времени еще не был готов. Причина в том, что Github Pages не поддерживают source отличную от текущей директории. И в результате работы сборщика Github в корне своего сайта наблюдал html-вариант README файла из репозитория.

Сборка в Travis всего сайта занимала порядка 2 минут, включая деплой. В то же время при комитах на Github при включенном Pages предупреждения получал уже спустя несколько секунд. То есть сборка на Github проводиться гораздо быстрее. Оно и понятно, окружение используется одно и то же для всех сайтов, и не нужно каждый раз при комитах готовить окружение заново, устанавливая каждый раз полный набор зависимостей. Несколько дней потратил на изменение структуры сайта, приводя его к виду, необходимому к использованию в Github Pages без использования сторонних сборщиков. При этом добивался того, чтобы в корне сайта оставалось как можно меньше файлов. В результате получилась следующая структура: [juev/juev.org](https://github.com/juev/juev.org/tree/464c4b804e5f4b644ac22107cbacd26511362bbf).

И на текущий момент времени сборка и размещение сайта полностью лежит на стороне Github. Проводил тесты по измерению [web page performance](https://www.webpagetest.org/result/190126_2G_82f9cdafc549d51a9536d03881d0a7d7/), результаты довольно хорошие, не смотря даже на то, что в Github Pages очень ограниченное время кеширования ваб-страниц. Для "персонального" сайта вполне оптимально, на мой взгляд.

Если ищете вариант размещения своего сайта, то рассмотрите Github Pages, мои рекомендации.