Comments 8
так и не понял при чем тут devops.
При том, что тестирование нужно
- встраивать в пайплайн
- автоматизировать по максимуму
- строить метрики качества кода.
В противном случае, мы имеем просто кучу лишней работы и просаживаем бабки заказчика (работодателя) вхолостую.
Ещё не могу не отметить две вещи:
- Принцип shift to the left. Он нам говорит, что банк проще и дешевле поправить на подлёте, пока она ещё не попала в релиз. Да, для этого необходимо менять процессы, строить культуру. Это действительно дорого. И это не нужно всем. Это очень важно. Но если компания действительно айти, причем реально, а не на словах, то это а необходимое условие ее выживания на рынке. Т.е. вложения в автоматизацию тестирования при промышленной разработке в долгосрочной перспективе окупаются.
- То же секьюрити продуктов. Это тоже по сути про тестирование, но немного на другом уровне. И цель простая — делать качественный продукт, с предсказуемыми сроками и предсказуемыми расходами.
так это все прекрасно существует без devops… ну или я чего-то не понимаю.
скажем, у нас релизы редко, ну так повелось и заказчики не готовы обновляться постоянно (за исключением случая критической баги).
при этом есть:
1) gerrit
2) автоматизированный анализ кода
3) несколько тысяч скриптованых тестов, накопленных за 18 лет
4) система, запускающая тесты на патчи в gerrit и отправляющая все результаты в БД
скажем, у нас релизы редко, ну так повелось и заказчики не готовы обновляться постоянно (за исключением случая критической баги).
при этом есть:
1) gerrit
2) автоматизированный анализ кода
3) несколько тысяч скриптованых тестов, накопленных за 18 лет
4) система, запускающая тесты на патчи в gerrit и отправляющая все результаты в БД
Как у Вас построен процесс нахождения у заказчика баги и потом фикса ее в следующем релизе?
Просто есть небольшая разница между "коробочным" софтом и "софтом как SaaS" в подходе. Но в общем — все одно и то же.
заказчики не готовы обновляться постоянно
а почему? Вот Вы знаете версию своей операционной системы или браузера хром, в котором пишете эти строчки?
заказчик обычно сам репортит проблему в jira, дальше просим ту или иную информацию (логи/дампы), пытаемся воспроизвести локально, обычно появляется regression test, фикс заворачиваем в минорный релиз(ы).
заказчики не готовы обновляться, потому что для обновления нужно останавливать систему (это не микросервисы, а большая система хранения данных). в некоторых ситуациях возможен постепенный upgrade через failover-сервера, но не всегда — даже такой failover, будучи прозрачным для приложений, занимает какое-то время и часть приложений простаивает.
очень часто обновления планируются за недели и даже месяцы, за исключением каких-то критических проблем. бывает так, что приходится выключать те или иные оптимизации на лету до обновления.
заказчики не готовы обновляться, потому что для обновления нужно останавливать систему (это не микросервисы, а большая система хранения данных). в некоторых ситуациях возможен постепенный upgrade через failover-сервера, но не всегда — даже такой failover, будучи прозрачным для приложений, занимает какое-то время и часть приложений простаивает.
очень часто обновления планируются за недели и даже месяцы, за исключением каких-то критических проблем. бывает так, что приходится выключать те или иные оптимизации на лету до обновления.
Ну то есть заказчики не готовы обновляться, потому что вы не умеете делать zero-downtime updates. То есть это не они не готовы, это вы не готовы. Не особо хороший повод хвастаться.
во-первых, я вроде бы не хвастался.
во-вторых, я не знаю что ты подразумеваешь под zero-downtime.
как я писал выше — приложения не видят failover на другой сервер, это все происходит прозрачно. но сама процедура failover'а по-определению не может не занимать времени — на сервере лежат общие данные для всех клиентов (часто десятки тысяч узлов). даже процедура обнаружения смены сервера занимает время. далее разные дополнительные задержки в виде холодного кэша на сервере и проч.
в силу масштабов систем, такие задержки рассматриваются как существенные и их стараются планировать заранее. за подробностями можно гуглить os jitter hpc.
во-вторых, я не знаю что ты подразумеваешь под zero-downtime.
как я писал выше — приложения не видят failover на другой сервер, это все происходит прозрачно. но сама процедура failover'а по-определению не может не занимать времени — на сервере лежат общие данные для всех клиентов (часто десятки тысяч узлов). даже процедура обнаружения смены сервера занимает время. далее разные дополнительные задержки в виде холодного кэша на сервере и проч.
в силу масштабов систем, такие задержки рассматриваются как существенные и их стараются планировать заранее. за подробностями можно гуглить os jitter hpc.
Тут идея состояла в том, что приход DevOps сейчас на уровне мейнстирма. Причем не всегда это делается органично, т.е. компания меняется, выстраивает процессы и потом при самоанализе видит, что по факту выстроили DevOps процесс. Чаще бывает, что приносится это в виде идеи и дальше принимается решения, что завтра мы будем строить DevOps. Открывают странные вакансии на hh.ru и пытаются сделать так как поняли. Суть данного поста, что если вы осознаете необходимость DevOps, то одна из функций, которую он затронет достаточно плотно — это тестирование. А вот что делать в тестирование и как реализовывать тестирование в рамках DevOps я и хотел раскрыть.
Sign up to leave a comment.
DevOps — хорошо, но что делать? Как сократить ручной труд и прийти к желаемому результату