Empresa de desarrollo Symfony: contrate un equipo Symfony dedicado para nuevos proyectos y actualizaciones

¿Por qué contratar una empresa de desarrollo Symfony en lugar de desarrolladores individuales?

Contratar una empresa de desarrollo Symfony le da un equipo que funciona con prácticas compartidas desde la primera semana, en lugar de reunir y gestionar usted mismo contrataciones individuales. Los freelancers funcionan bien para tareas pequeñas y bien definidas. La contratación interna funciona bien a largo plazo, pero suele llevar meses por cada desarrollador Symfony sénior. Un equipo dedicado de una empresa cubre ese hueco: la arquitectura, la revisión de código, QA y DevOps van incluidos, y el equipo puede crecer o reducirse según su hoja de ruta.

Symfony no es una habilidad secundaria para nosotros. PHP/Symfony es el stack principal de back end de Lytvynov Production, y muchas de las plataformas de negocio que hemos entregado, desde un ERP a medida hasta un marketplace de creadores, funcionan sobre él.

¿Cómo es un equipo Symfony dedicado?

Un equipo Symfony dedicado es un grupo estable de ingenieros que trabaja solo en su producto, dentro de sus procesos, durante meses o años. Una composición inicial habitual es un ingeniero Symfony sénior responsable de la arquitectura más uno o dos desarrolladores Symfony, con un desarrollador front end (React, Vue o Angular), QA y DevOps a tiempo parcial cuando hace falta.

El equipo trabaja en sus repositorios y su sistema de tickets, se une a sus reuniones diarias y sigue sus reglas de revisión de código y de publicación, o aporta las suyas si usted aún no las tiene. Trabajamos en inglés (y en francés cuando resulta útil), con horarios que se solapan con las zonas horarias europeas y estadounidenses. Internamente usamos agentes de programación con IA bajo la revisión de ingenieros sénior para el trabajo rutinario, como tests, migraciones y refactorizaciones, lo que deja más presupuesto para las partes que requieren criterio humano. Para ver cómo se compara trabajar con un equipo ucraniano con otras opciones, consulte externalizar el desarrollo de software en Ucrania.

¿Cómo creamos nuevas aplicaciones Symfony?

Las nuevas aplicaciones Symfony empiezan por el dominio, no por el framework. Primero modelamos las entidades y reglas de negocio y después las trasladamos a entidades de Doctrine, servicios y message handlers, manteniendo la lógica de negocio fuera de los controladores para que pueda probarse y reutilizarse.

Nuestra configuración por defecto para un nuevo desarrollo:

• Symfony sobre PHP 8.x actual, tipos estrictos y PHPStan a un nivel alto desde el primer día.
• Doctrine ORM con PostgreSQL o MySQL y migraciones versionadas.
• API Platform para productos orientados a API, o Twig con Symfony UX para interfaces renderizadas en el servidor.
• Symfony Messenger con Redis o RabbitMQ para tareas en segundo plano, correos electrónicos, importaciones e integraciones.
• Mercure para actualizaciones en tiempo real en el navegador.
• EasyAdmin para back offices que deben estar listos rápido.
• Docker, CI/CD y tests automatizados (PHPUnit, tests funcionales) en el pipeline antes de que se publique la primera funcionalidad.

El ERP a medida para una empresa estadounidense de servicios aeronáuticos se construyó así durante seis meses sobre Symfony/PHP, React, SQL y Mercure: gestión de clientes y pedidos, planificación del servicio de aeronaves, turnos del personal sincronizados con los calendarios de Google, Apple y Team, inventario de almacén en tiempo real y seguimiento del cumplimiento normativo, utilizado a diario por todos, desde el personal de tierra hasta el CEO.

¿Cómo se actualizan proyectos heredados de Symfony 4 o 5 a 6.4 o 7?

Actualizar un proyecto Symfony heredado significa avanzar una versión mayor cada vez, corregir las deprecaciones antes de cada salto y mantener la aplicación desplegable durante todo el proceso. Los proyectos en Symfony 4.4 están ya muy fuera de soporte, y Symfony 5.4 ha dejado el soporte regular de corrección de errores, por lo que dejan de recibir correcciones normales y a menudo quedan atados a versiones antiguas de PHP sin soporte. Hoy el objetivo suele ser la versión actual de soporte a largo plazo de la línea 6.4 o 7.x, según su versión de PHP y sus dependencias.

Nuestro proceso de actualización:

1. Auditoría (1 a 2 semanas): versiones de PHP y Symfony, registro de deprecaciones, bundles y su estado de mantenimiento, cobertura de tests, alojamiento.
2. Red de seguridad: añadir smoke tests y tests funcionales en los flujos críticos si la cobertura es escasa.
3. Actualización de PHP: pasar primero a una versión de PHP 8.x con soporte, con Rector encargándose de la mayoría de los cambios de sintaxis.
4. Una versión mayor de Symfony cada vez: de 4.4 a 5.4, de 5.4 a 6.4, de 6.4 a 7.x, eliminando las deprecaciones antes de cada paso.
5. Sustituir los bundles abandonados por alternativas mantenidas o por pequeño código propio.
6. Configuración y atributos: pasar las anotaciones a atributos de PHP y actualizar la configuración de seguridad al nuevo sistema de autenticadores.
7. Publicación por etapas con monitorización, para que cada paso pueda revertirse.

Para código muy antiguo en Symfony 2 o 3, o PHP sin framework, solemos recomendar una migración gradual: las nuevas funcionalidades en una aplicación Symfony nueva y las partes antiguas trasladadas módulo a módulo detrás de las mismas URL.

¿Cómo creamos APIs con API Platform?

API Platform es la forma más rápida de crear una API REST o GraphQL bien documentada sobre Symfony. Genera endpoints, documentación OpenAPI, paginación, filtrado y validación a partir de sus recursos, de modo que el equipo dedica el tiempo a las reglas de negocio en lugar de al código repetitivo.

Usamos API Platform para back ends que sirven aplicaciones web en React o Vue, aplicaciones móviles en React Native o Flutter e integraciones con socios. Cuando las operaciones de negocio no se ajustan a un simple crear, leer, actualizar y eliminar, escribimos state providers y processors personalizados o exponemos endpoints de acción explícitos. Las reglas de seguridad se definen por operación y se cubren con tests, y el filtrado multi-tenant se aplica a nivel de Doctrine para que ningún endpoint pueda filtrar datos de otro cliente. Es el mismo enfoque que usamos en el desarrollo de SaaS.

¿Cómo se resuelven los problemas de rendimiento de Symfony y PHP?

Los problemas de rendimiento de Symfony están casi siempre en la capa de base de datos o en trabajo que se hace durante la petición y que debería ejecutarse en segundo plano. Empezamos midiendo con un profiler sobre patrones de tráfico reales y después corregimos primero el mayor coste.

Hallazgos y soluciones habituales:

Ritoria, una plataforma Symfony que construimos con 54 entidades de dominio, tres proveedores de pago y un back office en EasyAdmin de 38 secciones, funcionó en producción en AWS durante dos años y medio a lo largo de 120 migraciones de base de datos. Los productos de larga duración como ese solo se mantienen rápidos cuando las comprobaciones de rendimiento forman parte del desarrollo habitual, no de un proyecto de emergencia.

Cómo trabajamos con equipos Symfony

Empezamos con una llamada breve y, en proyectos existentes, con una auditoría de código que termina con un informe escrito y un plan. En nuevos desarrollos empezamos con la fase de alcance y un presupuesto cerrado para el primer hito. Después entregamos hitos de alcance cerrado o proporcionamos un equipo Symfony dedicado con facturación mensual, con el código y la infraestructura siempre en sus cuentas. Si todavía está eligiendo framework, lea Symfony vs Laravel para SaaS.

Reserve una llamada con un líder técnico de Symfony y cuéntenos su proyecto, su versión actual de Symfony y qué no está funcionando.