php - español - typo3 templates
¿Cómo gestionar y desarrollar grandes proyectos TYPO3? (3)
Absolutamente recomiendo comenzar a usar PHPUnit para la prueba de unidad, pero recuerde que la prueba de unidad es realmente acerca de cómo crear el código en primer lugar, generalmente no es algo que agregue más adelante. Pero claro, mejor tarde que nunca.
Debería considerar configurar un servidor de compilación como jenkins / hudson o atlassian bamboo . Este último es bastante bueno y se integra con zend studio, que en mi opinión es la mejor opción cuando se desarrolla en PHP. En general, los productos atlassian son ampliamente utilizados para proyectos de software. (Jira + confluencia + greenhopper en particular)
Estoy desarrollando proyectos TYPO3 desde 2006 ahora, y los proyectos son cada vez más grandes y complejos. La configuración de un sitio CMS simple con un formulario de contacto y lista de noticias es una rutina.
En este momento, terminamos un proyecto más grande: una plataforma para una compañía internacional con innumerables extensiones: inicio de sesión y registro, noticias, registros de bases de datos de listas, formularios de contacto dinámicos, encuestas y estadísticas, funciones de intranet: carga y descarga de documentos, varios "ajustes" en el backend por modificaciones de TCA, etc.
Los gestores de proyectos se enojaron con nosotros los desarrolladores, porque a veces, después de que termináramos en la función X y luego confirmáramos la función Y en el servidor de desarrollo, la función X se rompió. Esto estaba relacionado con la configuración de errores tipográficos, las interdependencias de extensión, los errores de versiones o, a veces, errores de programación simples y errores tipográficos. Sé cómo cuidar de estos últimos, pero en general:
Desde su experiencia:
¿Cómo podemos desarrollar un sistema a prueba de errores en TYPO3, donde todo funciona a la mano y las extensiones no se interponen en su camino? En otras palabras: ¿Cómo podemos asegurar y aislar funcionalidades (extensiones) y evitar esos problemas de interdepencia?
Estamos trabajando en un equipo de DEV con dos desarrolladores, y ya usamos:
- Repositorio Subversion
- Servidor local de DEV para desarrollo y pruebas
- Archivos de configuración de typoscript externos, divididos en archivos individuales para cada extensión
Editar para cazarrecompensas:
Lo que busco es un resumen de mejores prácticas que pueda incluir estos temas:
- Hábitos generales de flujo de trabajo.
- Hábitos generales de codificación.
- Fiabilidad de nuestros compromisos de subversión (o Git)
- Pruebas unitarias (PHPUnit, Selenium?)
- Implementación (aún no he descubierto cómo la implementación automatizada puede ayudarnos)
- Mejores prácticas tipográficas
Los problemas que podemos encontrar en grandes proyectos de TYPO3 no son muy diferentes de cualquier proyecto de desarrollo.
Prácticas generales:
- configurar la plataforma de integración continua con herramientas de despliegue continuo ;
- Desarrollo dirigido por pruebas con pruebas automatizadas;
- Arquitectura robusta (dB, enrutamiento de URL, ...);
- pruebas de rendimiento durante el desarrollo;
- utilizar versiones con comentarios formateados;
- use IDE de gran alcance como PHPStorm, Eclipse, Netbeans;
Prácticas comunes de TYPO3:
- usar API oficial ;
- siga la pauta del código de TYPO3 API ;
- use los ganchos TYPO3 donde pueda si necesita modificar la lógica de las extensiones Core o de terceros;
- utilice constantes de TypoScript para separar los datos de la lógica en su configuración;
Referencias adicionales:
- Taller de Mejores Prácticas TYPO3
- Mejores Prácticas de TYPO3 (de)
- TDD y mejores prácticas con TYPO3 (de)
Las extensiones podrían ayudar a administrar la instalación compleja de TYPO3:
Utilizar metodologías y herramientas modernas de gestión de proyectos.
- Scrum, Kanban, principios de desarrollo lean
- Bugtrackers como Redmine, Trac
Libros
También recomendaría configurar phpunit en jenkins: vea http://jenkins-php.org/ como plantilla, aunque he leído buenos comentarios sobre Teamcity. Luego, según el código que escriba, configurará las pruebas de unidad (para código php en bruto, quizás un poco de simulacros), pruebas de integración (API y conectividad de módulos) y pruebas de sistema (selenio).
Una vez que lo ejecute después de cada compilación, puede estar seguro de que al menos la funcionalidad cubierta está funcionando. Sin embargo, el problema es que pasará más tiempo escribiendo pruebas y su soporte, así como pensando en el código comprobable. También tenga en cuenta que no puede abarcar todo, ese no es el punto. Debes tener caminos críticos cubiertos.