Коли стикаєшся з новим викликом, особливо в межах проєкту, перший крок — це обговорення з усіма розробниками, які беруть участь у ньому. Така дискусія надзвичайно важлива для того, щоб зрозуміти поточний стан проєкту, визначити основні пріоритети, забезпечити оптимальну продуктивність та з'ясувати вимоги. Однак часто Product Owner має чітко визначені функції, архітектуру, інфраструктуру та UX/UI дизайн. У таких випадках важливо бути гнучким, адаптивним та добре розуміти їхні цілі.
Саме так було з Mekanoid. Антон, CEO Mekanoid і один з його засновників, мав не лише чітке уявлення про кінцевий продукт, але й про його архітектуру. З самого початку, маючи на увазі масштабованість, Антон вирішив, що для Mekanoid буде використано безсерверну архітектуру. Безсерверна архітектура має перевагу в масштабованості, а також не потребує керування та обслуговування серверів. Однак є й недоліки — це вартість та складність.
Огляд архітектури
Уся програма працює на AWS Lambda. Традиційні lambda функції важко розгорнути без використання фреймворку. У цьому випадку для цього був обраний фреймворк SST (Serverless Stack). У поєднанні з Seed, повністю керованою платформою CI/CD (Continuous Integration/Continuous Delivery), створеною розробниками SST, програма буде розгортатися на середовищі для тестування щоразу, коли на GitHub відкриватиметься новий PR (Pull Request).
На стороні фронтенду застосунок React працюватиме з AWS S3.
Для зберігання даних були обрані бази даних AWS Neptune і AWS DynamoDB. Для управління користувачами використовуватиметься AWS Cognito.
Виклик
У монолітному застосунку, такому як Ruby on Rails, зазвичай налаштовують CI, щоб створити нову тимчасову базу даних, запустити застосунок і виконати деякі завдання, наприклад, лінтинг та запуск тестів. Зазвичай це буде тестовий набір Cypress.
У цій архітектурі звичний підхід не працює. Ми не можемо запустити застосунок SST локально (наприклад, CI), оскільки він працює лише в lambda, і не можемо так просто створити тимчасові ресурси бази даних у хмарі.
Як же протестувати безсерверний застосунок?
Рішення
Якщо ви використовували Cypress раніше, ви знаєте, що його тести виконуються в браузері, і якщо ви QA-інженер, то знаєте, що написання тестів — це як ручний QA, тільки автоматизований. Ось і все. Тобто тестування безсерверного застосунку має бути таким самим, як і тестування моноліту.
Але як же запустити всю розподілену інфраструктуру для виконання тестів?
Відповідь така: за допомогою іншої платформи CI/CD.
Замість того, щоб запускати тестування вручну, Seed налаштований правильно, і кожен раз, коли відбувається push на GitHub, Seed запускає лінтер, одиничні тести, а якщо вони успішні, створюються артефакти та деплоїться нове середовище для тестування в AWS.
За допомогою GitHub Actions, ми могли б слухати подію deployment_status event, і коли вона буде успішною, запускати задачу Cypress.
Якщо вам цікаво, ось як виглядає файл .github/workflows/main.yml:
name: CI
on: deployment_statusjobs:
cypress:
if: github.event_name == 'deployment_status' && github.event.deployment_status.state == 'success'
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- uses: actions/setup-node@v3
with:
node-version: 16
- uses: cypress-io/github-action@v4
env:
CYPRESS_baseUrl: 'https://app-$.secure-url.com'
CYPRESS_RECORD_KEY: $
with:
record: true
wait-on: 'https://app-$.secure-url.com'
browser: chrome
Примітка: secure-url.com — це не справжнє посилання. Сховано з міркувань безпеки.
Також варто зазначити, що повинна бути інтеграція seed (для створення тестових даних), яка виконується як частина процесу розгортання кожної гілки, і саме там будуть виконуватись тести. Інші середовища в пайплайні Seed захищені від запуску цих seed.
Висновок
Підсумовуючи, можна сказати, що правильно налаштована автоматизація QA для безсерверної архітектури не сильно відрізняється від автоматизації QA для монолітної архітектури. Як QA-інженери, виклик завжди полягає в розробці та наданні ефективних тестів.
Перекладено з: Quality Assurance automation on a serverless architecture