Présentation des rails dans une boutique PHP? Ou accumulez ce que nous utilisons déjà?

Voici la configuration de notre boutique:

• 1 très grande application PHP (Kohana 2) avec Beaucoup de devations et beaucoup d'infrastructure
• multiple (4-5 et croissance) petit PHP Applications avec 1-2 Dev travaillant sur ces

  Problèmes:

  • aucun test
  • pas de documentation
  • Un déploiement fragile et fastidieux processus

    Je suis déplacé de la seule grande application sur le côté de la maison avec les multiples applications plus petites. Le manque de test et un processus de déploiement approprié dans notre magasin me rend nerveux que je vais passer plus de temps à réparer les bogues et au déploiement de corrections que de rédiger un code pour de nouvelles fonctionnalités.

    solution A:

    • Introduisez PHPUNIT et SELENIUM
    • nous déplace vers le pHing et le dbdeploy

      problème avec A: La mise en place de PHPUnit a été relativement facile, mais les tests fonctionnels avec sélénium ont été une douleur totale. Notre travail de VM est idéal pour Dev, mais sélénium pince l'aiguille, plus quelques tests simples prennent pour toujours. Je ne doute pas que je puisse avoir toutes ces technologies qui jouent bien ensemble, mais tout ressemble à un gâchis et la complexité de ces travailleurs semble fragile.

      solution B:

      • Switch to Rails
      • Utilisez des tests intégrés et / ou Rspec / concombre (intégration du ce dernier semble simple)
      • Utilisez des migrations de dB intégrées
      • Utilisez Capistrano pour des déploiements

        Sur la base des principaux problèmes de test, j'ai commencé à regarder dans des rails. Basé sur la nature de ces autres sites que nous gérons, je pense que les rails peuvent être une bonne solution. Essais intégrés, grande communauté, beaucoup d'excellents outils et développement rapide.

        problème avec B: Chaque application que nous avons maintenant est sur Kohana 2 (cadre PHP) et personne de l'organisation ne connaît les rails. L'inconvénient d'introduire une nouvelle technologie serait fracturant les équipes. Si je migre les sites vers des rails, puis-je heurter un bus, nous sommes un peu vissés.

        Bottom Line:

        Sur la base de nos points de douleur (déploiements, tests, documentation, migrations de base de données de la DB), vaut-il la peine de passer aux rails? Ou devrions-nous rester mis à Kohana et continuer à essayer d'obtenir les autres outils construits?

        Toute suggestion? Quelqu'un est parti autre chose? La direction m'a déjà dit qu'ils sont ouverts à avoir entendu parler des rails et veulent simplement utiliser le meilleur outil possible - quoi que ce soit. Notre architecte principal devra toutefois nécessiter une conviction si je décide de changer de frameworks sur nos plus petits projets.