Партизанский DevOps: Как мы сбежали на GitHub Actions
· 3 min read
В крупных компаниях процессы рано или поздно начинают жить собственной жизнью и диктовать условия. Мы споткнулись о публикацию документации. Раньше техписатели весь месяц мучительно собирали правки, чтобы потом торжественно выкатить один ручной релиз. Меня эта рутина дико раздражала. Хотелось нормального CI/CD, где всё собирается само после каждого пуша. Но просто хотеть мало — нужно было наглядно показать коллегам, что автоматизация реально работает.
Для перехода на генераторы статических сайтов (SSG) требовался парсер в Markdown. Старый внутренний инструмент умел выплевывать только XML. Причем на больших объемах он намертво задумывался на несколько часов. К счастью, параллельно с этими страданиями мы уже собрали рабочую связку Python ➡️ HTML (о ней я рассказывал в прошлой части). Оставалось перепилить её в Python ➡️ Markdown и начать генерировать документацию для самой Flude. Ведь движок тоже написан на Python.
Дальше дело встало за инфраструктурой. И тут корпоративные шестеренки заскрипели. Наш Infrastructure Lead (тот самый, кто подкинул идею с SSG) оказался завален задачами, а потом вообще ушел в отпуск. Сидеть и ждать его возвращения, чтобы выбить ресурсы на внутреннем сервере? Это означало похоронить проект минимум на пару месяцев. Поэтому я решил уйти в партизаны.
План побега
Раз внутренняя сеть недоступна, значит, выносим эксперимент наружу. GitHub идеально подходил под эти задачи. Исходники движка и список требований я спрятал в приватных репозиториях. А вот пользовательскую документацию (User Docs) и справочник API (API Ref) мы спокойно развернули в облаке. В конце концов, это опенсорсная Flude. Никакого корпоративного кода мы не светили.
Поскольку проект пилился с нуля и «под себя», мы решили немного поэкспериментировать. Для разных порталов взяли абсолютно разные SSG-фреймворки. Задачу это слегка усложнило, зато мы отлично набили шишки в настройке зоопарка технологий.
Архитектура пайплайна получалась на редкость изящной. Портал User Docs автоматически тянул свежий код из закрытого репозитория. Дальше просыпался Flude и на лету парсил исходники в Markdown. Готовую разметку подхватывал SSG, собирал из неё статический сайт и сразу пушил на хостинг (GitHub умеет бесплатно раздавать HTML-страницы из публичных реп).
Слепой архитектор
В теории я отлично понимал механику CI/CD. Проблема была сугубо практической: я в глаза не видел синтаксис YAML и ни разу не настраивал GitHub Actions. Прямо как на старте с Python, я снова включил режим слепого архитектора.
Всю черновую работу забрал ИИ-напарник. Я просто описывал человеческим языком, что должно происходить на каждом шаге. Нейронка в ответ выплевывала готовые файлы для папки .github/workflows. Иногда она даже била меня по рукам и заставляла внедрять best practices (например, настраивать кэширование зависимостей или бить монолитные задачи на отдельные джобы). Мы пушили конфиги, смотрели на красные логи упавших сборок, матерились, правили баги и запускали всё по новой.
Момент истины
Спустя несколько вечеров непрерывной возни я сделал очередной пуш. GitHub Actions завел шарманку. Репозиторий скачался. Зависимости встали. Flude пробежался по коду, выплюнув Markdown. SSG мгновенно скомпилировал HTML. Деплой прошел.
На экране наконец-то зажглась зеленая галочка. Я кликнул по URL сайта и увидел свежую документацию. Она обновилась сама, вообще без моего участия.
В этот момент я заорал «Да! Да! Да! Заработало!» так, что перепугал семью, волнистых попугаев и пару соседей. Это потрясающее чувство. Твоя концепция только что ожила на мониторе. Рутинный месячный релиз только что скукожился до двухминутного автоматического процесса.
Корпоративную инфраструктуру мы изящно обошли, и партизанский конвейер затикал как швейцарские часы. Но впереди маячил главный босс — легализация инструмента внутри компании. Нам предстояло доказать службе безопасности и руководству, что самописный генератор не хуже старого стандарта. Как провести регрессионное тестирование на закрытых данных и заставить менеджмент поверить в наш парсер? Об этом — в следующем эпизоде.