testomat.io управление авто тестамиУ нас для хранения логинов, паролей, серверов и т.д. в тестовых environments используется закриптованный текстовый файл - базовая защита скорее не от злостных хакеров, а от случайного попадания этих данных случайным людям (ибо все те же данные можно получить из других источников в незашифрованном виде).
С продакшеном тут было бы сложнее, но с ним мы не работаем.
Ну да, это многое объясняет.
Правда, непонятно, как может быть проект заточен под Java 7 без возможности перехода. Кто-то кому-то вашает лапшу на уши. Всё, что работает на Java 7, можно легко перевести на Java 8. Ну да ладно, я понимаю, что это уже не к вам вопросы.
А вас не смущает то, что многие либы и фреймворки требуют обновления версии для саппорта 8ки? А то, что чисто “теоретически”, некоторые API могут стать деприкейтед (или вовсе исчезнуть) в новой версии, что может повлечь за собой значительный рефакторинг продакшен кода, значит тоже никого не должно смущать? Главный вопрос - кто за это заплатит? Второй вопрос - сколько времени на это уйдет, включая багфикс? Ну и последний - каков профит? Восьмерка релизнулась год назад. Неужели вы считаете, что огромные проекты, стартанувшие ранее, так прям и разгонятся обновляться? Ответ - нет. Еще и ради автомейшена? Пфф, тем более нет.
А, ок, проблема понятна. Ну, все инструменты надо периодически обновлять. Нельзя же вечно сидеть на старье. Оно постепенно замедляет движение вперёд, а рано или поздно и оно устареет настолько, что остановится всё. Автоматизация тут не при чём, это вопрос жизнеспособности проекта. Он должен как-то организованно решаться.
Плотник же не спрашивает, кто ему
оплатит время на заточку пилы или покупку новой дрели.
Любое обновление должно быть чем-то обосновано. Если система уже отлажена и заведена в продакшен, то доводы о том, что якобы когда-то она остановится чисто из-за того, что версии библиотек не самые последние, - звучат как-то абсурдно. Часто вы сталкиваетесь с тем, что заказчик оплачивает рефакторинг рабочей системы просто потому, что кому-то захотелось обновить либы? Сравнения с пилой и дрелью уместны только для случая, когда есть реальная проблема, которую не решить без новых инструментов. В остальном, подобные мероприятия не окупаются.
2 лайка
У нас проект только в самом начале своего пути. Пока что 5 тестов готово. Логины/пароли + данные для теста храним в csv-файлах. Пока что все удобно и все устранивает.
Есть очень хорошая практика: помимо продакшн репозитория есть пре-продакшн(именуемый тестовым), на котором по хуку после коммита запускаются все нагрузочные тесты, регрессионные тесты, обновляются если нужно лонг-ран тесты и т.д. Перед коммитом естественно для девелопера в тестовый репозиторий запускать только юнит-тесты, которые в изоляции будут проверять слой API, если таковой имеется, ну или по сути представляет собой атомарную функциональность. Свалились юниттесты до коммита - это проблема разработчика. Свалились комплексные тесты после коммита - анализ соответствующих логов и проблема разработчика или составителей комплексных автотестов. Не свалились комплексные тесты - эта пред-продовая ветка улетает в продакшн репозитарий, в котором по сути должны получиться релиз кандидаты(и в эту ветку допустимо напрямую коммитить ТОЛЬКО в исключительных ситуациях).
Автоматическое тестирование интерфейсов и прочие вещи должны иметь свою кодовую базу, свой энвайронмент, свои пермиссии на запуск соответсвующих задач.
p.s. Описываю как есть для моей команды из 4 девелоперов и 1 инженера по автоматизации.
2 лайка