Symfony 2.6, как лучше обновится до современной версии?
Доброго времени суток. Краткое вступление: Достался интересный проект, сделан на симфони 2.6 и mysql(doctrine), планируется много новых функций и отладка уже существующих. Проект старый, но раскручивать планируется только сейчас, потому клиентов пока было мало, но ожидается рост.
В процессе работы понадобились популярные бандлы, пока это knp-pagination и doctrine-migrations-bundle, и если первый поставился, какая-то старая версия, то второй не желает, все версии перепробовал. Я так предполагаю, в дальнейшем еще ждет много подобных проблем, когда дойдет дело до интеграции с популярными сервисами, и стоит переехать на версию по свежее.
Подскажите пожалуйста по следующим вопросам: 1) Как проще всего обновится до актуальной версии симфони и до какой именно? Я пока выбрал 3.4, она поддерживает PHP7 и это LST выпуск.
2) Я уже перечитал манов, и похоже придется мигрировать транзитом, т.е. сперва до 2.8, потом уже до 3.4, верно ли я это понял?
3) Проект тестами не покрыт, и для упрощения переезда, и вообще, на будущее, я думаю написать подобие тестов на postman, чтоб он хотя бы проверял все страницы, на 200 заголовок. Стоит это делать? (на юнит тесты и пр. к сожалению пока ресурсов нет).
4) Если у Вас есть опыт подобных переездов, сколько примерно это заняло и какого примерно размера был проект. И что непредвиденное в процессе возникло?
examplee, Спасибо) Думаю все таки на 3.4 переходить, а то нет всех нужных бандлов по по Вашему списку. Хотя я выборочно посмотрел, excel-Bundle, redis-Bundle, friendsofsymfony/comment-bundle и другие, и их уже начали оптимизировать под 4 версию.
Был опыт переезда с 2.8 на 3.4. Но там была легкая достаточно ситуация, потому что сторонних бандлов по минимуму, а в тех что есть практически ничего не поломалось при обновлении версий. Один бандл пришлось переключить на форк, потому что создатель на него забил.
Могу порекомендовать использовать статические анализаторы кода в PHPStorm с Symfony-плагином. Проверяет код на различные депрекации в объявлении сервисов, аннотациях, deprecated - классы и константы. 90% работы лично у меня свелось к заворачиваю в апострофы %вот_таких_параметров%. Кое-что правилось в security.yml (практически безболезненно).
1. Обновиться до 2.7
2. Обновиться до 2.8
3. Обновиться до 3.*
Так делали на своем проекте и получилось проще чем сразу перескочить на 3.* . Слишком много изменений, а так пошагово уберёте deprecations и подготовите код к следующему шагу
- обновить до 2.8, пройтись по всему сайту в дев-окружении, проверять функционал (скорее всего ничего не сломается), отслеживать в дев-панели deprecated, фиксить
- когда их не останется переходить на 3.4 и еще раз пройтись по сайту проверяя что всё ок
Самая главная проблема, которая может возникнуть - могут отвалиться некоторые бандлы, которые не работают на новой версии, и придется искать им замену.
3) Проект тестами не покрыт, и для упрощения переезда, и вообще, на будущее, я думаю написать подобие тестов на postman, чтоб он хотя бы проверял все страницы, на 200 заголовок. Стоит это делать? (на юнит тесты и пр. к сожалению пока ресурсов нет).
Средний
