Как настроить конвейер CI/CD для Cloudflare Worker

Использование действий GitHub с Wrangler, k6 и семантическим выпуском

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

Тестирование Cloudflare Worker немного не в порядке. Не поймите меня неправильно, я люблю Cloudflare Worker. Однако существующее решение кажется немного неинтуитивным. Вдобавок ко всему, dollarshaveclub/cloudworker больше не поддерживается активно, что является обломом.

TL;DR: как настроить конвейер CI/CD для проекта Cloudflare Worker с помощью GitHub Action и Grafana k6.

Обзор

Ранее Я создал клон сокращателя URL с помощью Cloudflare Worker. Используя этот существующий проект (ссылка на GitHub), мы рассмотрим настройку для него пайплайна CI/CD вместе с простыми интеграционными тестами.

Наш конвейер GitHub Action CI/CD довольно прост. Этапы (работы) следующие:

Lint-проверка или модульное тестирование
Развертывание в промежуточной среде
Запустите интеграционные тесты в нашей тестовой среде.
Запустить семантический релиз и развернуть в производственной среде

Конфигурация Wrangler

Для начала нам нужно изменить наш существующий wrangler.toml файл. Помните, нам нужна промежуточная среда для развертывания, чтобы запустить в ней наш интеграционный тест:

[env.staging]
name = "atomic-url-staging"
workers_dev = true
kv_namespaces = [
  { binding = "URL_DB", id = "ca7936b380a840908c035a88d1e76584" },
]

name — убедитесь, что name должен быть уникальным и буквенно-цифровым (допускается -) для каждой среды. Назовем нашу промежуточную среду atomic-url-staging.
worker_dev — Наши интеграционные тесты выполняются на <NAME>.<SUBDOMAIN>.workers.dev конечной точке. Следовательно, нам нужно развернуть наш Cloudflare Worker, установив workers_dev = true (ссылка).
kv_namespaces — Atomic URL использует KV в качестве базы данных для хранения сокращенных URL-адресов. Здесь я решил использовать предварительное пространство имен KV в качестве тестовой базы данных. Почему? Просто потому, что это то же самое пространство имен разработки KV, которое я использую во время локальной разработки (при запуске wrangler dev). Конечно, вы можете просто использовать обычное пространство имен KV. Просто убедитесь, что вы не используете Production KV id. Прочитайте, как создать пространство имен KV.

Затем нам также нужно создать производственную среду для развертывания с нашим рабочим пространством имен KV:

[env.production]
name = "atomic-url"
route = "s.jerrynsh.com/*"
workers_dev = false
kv_namespaces = [
  { binding = "URL_DB", id = "7da8f192d2c1443a8b2ca76b22a8069f" },
]

Раздел «Производственная среда» будет аналогичен предыдущему, за исключением того, что мы будем устанавливать worker_dev = false и route для производства.

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

Чтобы развернуть вручную с вашего локального компьютера в соответствующую среду, запустите:

wrangler publish -e staging
wrangler publish -e production

Тем не менее, мы рассмотрим, как сделать это автоматически через наш конвейер CI/CD с помощью GitHub Actions.

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

О, вот вам и шпаргалка по настройке wrangler.toml. Я настоятельно рекомендую вам использовать это!

Графана к6

Для интеграционного тестирования мы будем использовать инструмент, известный как k6. Как правило, k6 используется как инструмент для тестирования производительности и нагрузки. Теперь, потерпите меня, мы не собираемся интегрировать какие-либо нагрузочные тесты в наш конвейер CI/CD; не сегодня.

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

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

Что тестировать

По сути, вот несколько вещей, которые мы хотим проверить в рамках нашего дымового теста для нашего приложения для сокращения URL-адресов в группах:

Главная страница должна загрузиться, как и ожидалось, со статусом ответа 200.

group('visit main page', function () {
    const res = http.get(BASE_URL)
check(res, {
        'is status 200': (r) => r.status === 200,
        'verify homepage text': (r) =>
            r.body.includes(
                'A URL shortener POC built using Cloudflare Worker'
            ),
    })
})

Наша основная конечная точка POST API /api/url должна создать короткий URL-адрес с исходным URL-адресом.

group('visit rest endpoint', function () {
    const res = http.post(
        `${BASE_URL}/api/url`,
        JSON.stringify({ originalUrl: DUMMY_ORIGINAL_URL }),
        { headers: { 'Content-Type': 'application/json' } }
    )
check(res, {
        'is status 200': (r) => r.status === 200,
        'verify createShortUrl': (r) => {
            const { urlKey, shortUrl, originalUrl } = JSON.parse(r.body)
            shortenLink = shortUrl
            return urlKey.length === 8 && originalUrl === DUMMY_ORIGINAL_URL
        },
    })
})

Наконец, мы хотим убедиться, что когда мы посещаем сгенерированный короткий URL-адрес, он перенаправляет нас на исходный URL-адрес.

group('visit shortUrl', function () {
    const res = http.get(shortenLink)
check(res, {
        'is status 200': (r) => r.status === 200,
        'verify original url': (r) => r.url === DUMMY_ORIGINAL_URL,
    })
})

Для локального тестирования просто запустите k6 path/to/test.js. Вот и все! Вы можете найти полный тестовый скрипт здесь.

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

Действия на GitHub

Я буду замалчивать этот раздел, так как он довольно прост. Вы можете обратиться к окончательному файлу рабочего процесса GitHub Actions здесь.

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

wrangler-action — для развертывания Cloudflare Worker с помощью интерфейса командной строки Wrangler.
k6-action — Для запуска k6

Одно замечание о файле рабочего процесса — чтобы задание зависело (необходимо) от другого задания, мы будем использовать синтаксис need.

Действия Секреты

Для этого проекта требуется 2 секрета действий:

CF_API_TOKEN — будет использоваться Wrangler GitHub Action для автоматической публикации нашего Cloudflare Worker в соответствующей среде. Вы можете создать свой API-токен с помощью шаблона Edit Cloudflare Workers.
NPM_TOKEN — Этот проект также использует semantic-release для автоматической публикации в NPM. Чтобы включить это, вам нужно будет создать NPM_TOKEN через npm create token.

Чтобы добавить его в секреты репозитория GitHub, ознакомьтесь с этим руководством.

Если вы взглянули на окончательный файл рабочего процесса, вы, возможно, заметили синтаксис ${{ secrets.GITHUB_TOKEN }} и удивились, почему я ничего не упомянул о добавлении GITHUB_TOKEN в секреты действий нашего проекта. Оказывается, он автоматически создается и добавляется во все ваши рабочие процессы.

Заключительное замечание

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

Ну и что дальше? Прямо на моей голове, мы могли бы сделать лучше. Вот несколько улучшений, которые мы можем сделать:

Добавьте задание/этап, который автоматически откатывается и возвращает фиксацию при сбое дымовых тестов.
Создайте индивидуальную среду тестирования при создании PR, чтобы мы могли запускать на них дымовые тесты.
Вероятно, это перебор для этого проекта — реализация канареечного развертывания звучит как забавная задача.