Comments 14
Годно написано и по существу! Вопрос, что называется, на злобу дня, в поддержку/развитие этих автотестов вовлекается команда разработки или обеспечиваете их работоспособность и озеленяете их силами команды QA?
QA-инженеры пишут новые автотесты, актуализируют существующие, следят за ночными прогонами, помогают разобраться с падениями. Сценарии придумываем совместно с DevOps-инженерами, исходя из наших актуальных потребностей. DevOps-инженеры по желанию помогают с актуализацией тестов, но чаще с точки зрения изменения тестовых репозиториев, а не кода самих тестов.
как вариант точки роста: вместо pod.status"running" воспользоваться liveness пробой, ее результаты можно получать из команды kubectl
describe pod namepod
Warning Unhealthy 10s (x3 over 20s)
...
суть в том, что если у pod зависимость от другого сервиса (деплой которого наше изменение пайплайна опосредованно сломало), тестовый pod может начать ребутиться каждые 30сек но статус running у него будет присутствовать
Не совсем понятно, а что вы тестируете то? Вы проверяете действие каких-то уже готовых пайплайнов, с помощью которых все выкатывается? Но что будет, если этот пайплайн создаст что-то дополнительное, не ожиданое? или уничтожит левый pod?
А что если в пайплан настоящего сервиса добавят что-то свое?
Готовый пайплайн и скрипты, которые запускаются в джобах этого пайплайна, лежат в отдельном проекте, который развивают наши DevOps-инженеры. Этот пайплайн подключается в gitlab-ci.yml всех сервисов, написанных с ипользованием нашей платформы. DevOps-инженеры регулярно изменяют как сами скрипты, так и список джоб в пайплайне. Тесты помогают убедиться, что очередное изменение в скриптах или около того не разломало функционал выкатки сервиса, мы считаем эту часть пайплайна самой важной.
Если в пайплайне появится что-то неожиданное - если речь про новую джобу, то в зависимости от важности джобы будет и результат. Если эта джоба не относится к процессу деплоя - мы не будем смотреть на нее в тестах. Если эта джоба требуется для деплоя, тест без нее больше не проходит - надо актуализировать тест, автотесты не умеют предсказывать и делать аналитические выводы наперед.
Если в неймспейсе сервиса появится что-то неожиданное - тут мы знаем какой набор подов должен появиться, и в каком количестве должен быть каждый под. Например, если мы ждем, что поднимется 2 пода приложения, а их поднимается 1 или 4, то тест сообщит об этом. Если мы ждём, что должен подняться под с определенным ресурсом, а его нет - тест нам сообщит об этом. Если все что мы ждем поднялось, но сбоку образовался еще какой-то непонятный под - тест умеет работать только с заранее известной информацией. Можно посчитать общее количество подов и ориентироваться на него, но это не очень стабильная проверка и, на мой взгляд, ненужная. Автотесты не будут проверять 100% всех возможных кейсов и функциональности, они сосредоточены на самом важном. Аномальные изменения будем ловить при ручном тестировании.
Настоящий сервис может изменить свой пайплайн, у нас даже есть рекомендуемый способ расширения пайплайна (например, чтобы добавить свою задачу с тестами). Но это не имеет смысла с точки зрения пользователя-разработчика, если только он не пытается навредить себе. Если он переопределит джобу деплоя - он просто не сможет выкатиться. А в тестовых репозиториях, на которых гоняются автотесты, используется эталонный пайплайн.
Надеюсь, смог ответить на ваши вопросы)
спам тестов из-за частых коммитов
Подскажите, а как именно вы боретесь с этой проблемой?
Рядом с джобой с автотестами мы сделали еще одну джобу (пусть ее имя будет guard), которая в течение 5 минут ожидает, что джоба с автотестами была запущена. А саму джобу с автотестами перевели на ручной запуск.
Мы имеем следующие кейсы:
Автотесты не были запущены => джоба guard зафейлилась => пайплайн красный
Автотесты были запущены => джоба guard зеленая => автотесты нашли ошибку => пайплайн красный
Автотесты были запущены => джоба guard зеленая => автотесты успешно прошли => пайплайн зеленый
Таким образом, мы гарантируем, что у нас не будет МРа, который вмержили без тестов.
Интересная статья, спасибо большое. Предстаит задача создать нечто подобное, "в одно лицо", поэтому есть шкурный вопрос - а есть ли какой телеграм канал или что-то подобное где Вы и ваша команда присутствует и куда можно позадовать глупых вопросов? Не корпоративный канал - а именно такой, лампово-qa?
А разве для этих кейсов не подойдет kyverno или OPA? Также можно задать правила и автоматически проверять, что у разработчиков все правильно (в плане описания информации о сервисах команды, что установлены лимиты по ресурсам, есть пробы).
можно еще kind поднимать прямо в CI и прогонять тесты еще до деплоя в k8s - в этом случае, конечно, свои тесты имеют смысл.
Как написать автотесты деплоя и сэкономить нервы DevOps-инженеров