Представляем Rails в магазине PHP? Или создать то, что мы уже используем?

Вот установка в нашем магазине:

  • 1 ОЧЕНЬ большое приложение PHP (Kohana 2) с много разработчиков и много инфраструктуры
  • Несколько (4-5 и растущие) небольших PHP приложения с 1-2 разработчиками работают над этими

проблемами:

  • без тестирования
  • без документации
  • хрупкое и утомительное развертывание process

Меня перемещают из одного большого приложения в сторону дома с несколькими небольшими приложениями. Отсутствие тестирования и надлежащего процесса развертывания в нашем магазине заставляет меня нервничать из-за того, что я буду уделять больше времени исправлению ошибок и развертыванию исправлений, чем написанию кода для новых функций.

Решение A:

  • Представьте PHPUnit и Selenium
  • ] Переместите нас в Phing и Dbdeploy

Проблема с A: Настроить PHPUnit было относительно просто, но функциональное тестирование с помощью Selenium было настоящей головной болью. Наша виртуальная машина отлично подходит для разработчиков, но Selenium играет важную роль, плюс несколько простых тестов займут вечность. Я не сомневаюсь, что смогу совместить все эти технологии вместе, но все это кажется беспорядком, и сложность их совместной работы кажется хрупкой.

Решение B:

  • Перейти на Rails
  • Использовать интегрированный тестирование и / или Rspec / Cucumber (интеграция последнее кажется простым)
  • Использование интегрированных миграций БД
  • Использование Capistrano для развертывания

Основываясь на основных проблемах тестирования, я начал изучать Rails. Судя по характеру других сайтов, которыми мы управляем, я думаю, что Rails может быть хорошим решением. Встроенное тестирование, отличное сообщество, множество отличных инструментов и быстрая разработка.

Проблема с B: Каждое приложение, которое у нас есть сейчас, находится на Kohana 2 (фреймворк PHP), и никто в организации не знает Rails. Обратной стороной внедрения новой технологии будет раскол в командах. Если я переношу сайты на Rails, а потом меня сбивает автобус, мы как бы облажались.

Итог:

С учетом наших проблем (развертывание, тестирование, документация, миграции БД), стоит ли переходить на Rails? Или мы должны оставаться в Кохане и продолжать попытки создать другие инструменты?

Есть предложения? Кто-нибудь прошел через что-нибудь подобное? Менеджмент уже сказал мне, что они готовы услышать о Rails и просто хотят использовать лучший инструмент - каким бы он ни был. Однако нашему ведущему архитектору потребуются некоторые убеждения, если я решу переключить фреймворки на наши небольшие проекты.

12
задан jmccartie 1 December 2010 в 14:12
поделиться