Рядом с джобой с автотестами мы сделали еще одну джобу (пусть ее имя будет guard), которая в течение 5 минут ожидает, что джоба с автотестами была запущена. А саму джобу с автотестами перевели на ручной запуск.
Мы имеем следующие кейсы:
Автотесты не были запущены => джоба guard зафейлилась => пайплайн красный
Автотесты были запущены => джоба guard зеленая => автотесты нашли ошибку => пайплайн красный
Автотесты были запущены => джоба guard зеленая => автотесты успешно прошли => пайплайн зеленый
Таким образом, мы гарантируем, что у нас не будет МРа, который вмержили без тестов.
Готовый пайплайн и скрипты, которые запускаются в джобах этого пайплайна, лежат в отдельном проекте, который развивают наши DevOps-инженеры. Этот пайплайн подключается в gitlab-ci.yml всех сервисов, написанных с ипользованием нашей платформы. DevOps-инженеры регулярно изменяют как сами скрипты, так и список джоб в пайплайне. Тесты помогают убедиться, что очередное изменение в скриптах или около того не разломало функционал выкатки сервиса, мы считаем эту часть пайплайна самой важной.
Если в пайплайне появится что-то неожиданное - если речь про новую джобу, то в зависимости от важности джобы будет и результат. Если эта джоба не относится к процессу деплоя - мы не будем смотреть на нее в тестах. Если эта джоба требуется для деплоя, тест без нее больше не проходит - надо актуализировать тест, автотесты не умеют предсказывать и делать аналитические выводы наперед.
Если в неймспейсе сервиса появится что-то неожиданное - тут мы знаем какой набор подов должен появиться, и в каком количестве должен быть каждый под. Например, если мы ждем, что поднимется 2 пода приложения, а их поднимается 1 или 4, то тест сообщит об этом. Если мы ждём, что должен подняться под с определенным ресурсом, а его нет - тест нам сообщит об этом. Если все что мы ждем поднялось, но сбоку образовался еще какой-то непонятный под - тест умеет работать только с заранее известной информацией. Можно посчитать общее количество подов и ориентироваться на него, но это не очень стабильная проверка и, на мой взгляд, ненужная. Автотесты не будут проверять 100% всех возможных кейсов и функциональности, они сосредоточены на самом важном. Аномальные изменения будем ловить при ручном тестировании.
Настоящий сервис может изменить свой пайплайн, у нас даже есть рекомендуемый способ расширения пайплайна (например, чтобы добавить свою задачу с тестами). Но это не имеет смысла с точки зрения пользователя-разработчика, если только он не пытается навредить себе. Если он переопределит джобу деплоя - он просто не сможет выкатиться. А в тестовых репозиториях, на которых гоняются автотесты, используется эталонный пайплайн.
QA-инженеры пишут новые автотесты, актуализируют существующие, следят за ночными прогонами, помогают разобраться с падениями. Сценарии придумываем совместно с DevOps-инженерами, исходя из наших актуальных потребностей. DevOps-инженеры по желанию помогают с актуализацией тестов, но чаще с точки зрения изменения тестовых репозиториев, а не кода самих тестов.
Information
Rating
Does not participate
Location
Краснодар, Краснодарский край, Россия
Date of birth
Registered
Activity
Specialization
Test Automation Engineer, Quality Assurance Manager
Чатика такого, к сожалению, нет. Создавать его немного побаиваюсь, он может сожрать много времени, а работать надо)
Скажу честно, я не сталкивался с этими инструментами, и даже не слышал. Но спасибо за наводку, почитаю, что это за зверь, может пригодится)
Рядом с джобой с автотестами мы сделали еще одну джобу (пусть ее имя будет guard), которая в течение 5 минут ожидает, что джоба с автотестами была запущена. А саму джобу с автотестами перевели на ручной запуск.
Мы имеем следующие кейсы:
Автотесты не были запущены => джоба guard зафейлилась => пайплайн красный
Автотесты были запущены => джоба guard зеленая => автотесты нашли ошибку => пайплайн красный
Автотесты были запущены => джоба guard зеленая => автотесты успешно прошли => пайплайн зеленый
Таким образом, мы гарантируем, что у нас не будет МРа, который вмержили без тестов.
Готовый пайплайн и скрипты, которые запускаются в джобах этого пайплайна, лежат в отдельном проекте, который развивают наши DevOps-инженеры. Этот пайплайн подключается в gitlab-ci.yml всех сервисов, написанных с ипользованием нашей платформы. DevOps-инженеры регулярно изменяют как сами скрипты, так и список джоб в пайплайне. Тесты помогают убедиться, что очередное изменение в скриптах или около того не разломало функционал выкатки сервиса, мы считаем эту часть пайплайна самой важной.
Если в пайплайне появится что-то неожиданное - если речь про новую джобу, то в зависимости от важности джобы будет и результат. Если эта джоба не относится к процессу деплоя - мы не будем смотреть на нее в тестах. Если эта джоба требуется для деплоя, тест без нее больше не проходит - надо актуализировать тест, автотесты не умеют предсказывать и делать аналитические выводы наперед.
Если в неймспейсе сервиса появится что-то неожиданное - тут мы знаем какой набор подов должен появиться, и в каком количестве должен быть каждый под. Например, если мы ждем, что поднимется 2 пода приложения, а их поднимается 1 или 4, то тест сообщит об этом. Если мы ждём, что должен подняться под с определенным ресурсом, а его нет - тест нам сообщит об этом. Если все что мы ждем поднялось, но сбоку образовался еще какой-то непонятный под - тест умеет работать только с заранее известной информацией. Можно посчитать общее количество подов и ориентироваться на него, но это не очень стабильная проверка и, на мой взгляд, ненужная. Автотесты не будут проверять 100% всех возможных кейсов и функциональности, они сосредоточены на самом важном. Аномальные изменения будем ловить при ручном тестировании.
Настоящий сервис может изменить свой пайплайн, у нас даже есть рекомендуемый способ расширения пайплайна (например, чтобы добавить свою задачу с тестами). Но это не имеет смысла с точки зрения пользователя-разработчика, если только он не пытается навредить себе. Если он переопределит джобу деплоя - он просто не сможет выкатиться. А в тестовых репозиториях, на которых гоняются автотесты, используется эталонный пайплайн.
Надеюсь, смог ответить на ваши вопросы)
О, спасибо за совет! Не сталкивался ещё с таким кейсом, но подумаем как это прикрутить в наших тестах.
QA-инженеры пишут новые автотесты, актуализируют существующие, следят за ночными прогонами, помогают разобраться с падениями. Сценарии придумываем совместно с DevOps-инженерами, исходя из наших актуальных потребностей. DevOps-инженеры по желанию помогают с актуализацией тестов, но чаще с точки зрения изменения тестовых репозиториев, а не кода самих тестов.