Sviluppo Symfony: un team Symfony dedicato per nuovi progetti e aggiornamenti

Perché affidare lo sviluppo Symfony a una software house invece che a singoli sviluppatori?

Affidare lo sviluppo Symfony a una software house vi dà un team operativo con pratiche condivise fin dalla prima settimana, invece di dover mettere insieme e gestire da soli singole assunzioni. I freelance funzionano bene per compiti piccoli e ben definiti. L'assunzione interna funziona bene nel lungo periodo, ma richiede tipicamente mesi per ogni sviluppatore Symfony senior. Un team dedicato fornito da un'azienda colma il divario: architettura, code review, QA e DevOps sono inclusi, e il team può crescere o ridursi in base alla vostra roadmap.

Symfony non è una competenza secondaria per noi. PHP/Symfony è lo stack back-end principale di Lytvynov Production, e molte delle piattaforme aziendali che abbiamo consegnato, da un ERP su misura a un marketplace per creator, girano su di esso.

Com'è fatto un team Symfony dedicato?

Un team Symfony dedicato è un gruppo stabile di ingegneri che lavora solo sul vostro prodotto, dentro i vostri processi, per mesi o anni. Una configurazione iniziale comune è un ingegnere Symfony senior responsabile dell'architettura più uno o due sviluppatori Symfony, con uno sviluppatore front-end (React, Vue o Angular), QA e DevOps aggiunti part time quando servono.

Il team lavora nei vostri repository e nel vostro sistema di ticket, partecipa ai vostri standup e segue le vostre regole di code review e di rilascio, oppure porta le proprie se non le avete ancora. Lavoriamo in inglese (e in francese quando utile), con orari sovrapposti sia ai fusi europei sia a quelli statunitensi. Internamente usiamo agenti di coding AI, con revisione di ingegneri senior, per il lavoro di routine come test, migrazioni e refactoring, il che lascia più budget per le parti che richiedono giudizio umano. Per un confronto tra lavorare con un team ucraino e le altre opzioni, vedete outsourcing dello sviluppo software in Ucraina.

Come sviluppiamo nuove applicazioni Symfony?

Le nuove applicazioni Symfony partono dal dominio, non dal framework. Modelliamo prima entità e regole di business, poi le mappiamo su entità Doctrine, servizi e message handler, tenendo la logica di business fuori dai controller così che possa essere testata e riutilizzata.

La nostra configurazione predefinita per un nuovo sviluppo:

• Symfony sull'attuale PHP 8.x, strict types, PHPStan a un livello alto fin dal primo giorno.
• Doctrine ORM con PostgreSQL o MySQL e migrazioni versionate.
• API Platform per prodotti API-first, oppure Twig con Symfony UX per interfacce renderizzate lato server.
• Symfony Messenger con Redis o RabbitMQ per job in background, email, importazioni e integrazioni.
• Mercure per aggiornamenti in tempo reale nel browser.
• EasyAdmin per back office che devono esistere in fretta.
• Docker, CI/CD e test automatici (PHPUnit, test funzionali) nella pipeline prima che venga rilasciata la prima funzionalità.

L'ERP su misura per un'azienda statunitense di assistenza aeronautica è stato sviluppato in questo modo in sei mesi su Symfony/PHP, React, SQL e Mercure: gestione di clienti e ordini, pianificazione dei servizi sugli aeromobili, turni del personale sincronizzati con i calendari Google, Apple e Team, inventario di magazzino in tempo reale e monitoraggio della conformità normativa, usato ogni giorno da tutti, dal personale di terra al CEO.

Come si aggiornano progetti legacy da Symfony 4 o 5 a 6.4 o 7?

Aggiornare un progetto Symfony legacy significa avanzare di una versione major alla volta, correggere le deprecation prima di ogni salto e mantenere l'applicazione rilasciabile per tutto il tempo. I progetti su Symfony 4.4 sono ben oltre la fine del supporto, e Symfony 5.4 è uscito dal supporto ordinario per le correzioni di bug, quindi non ricevono più le correzioni normali e spesso vincolano a vecchie versioni di PHP non supportate. Oggi l'obiettivo è di solito l'attuale release a supporto a lungo termine della linea 6.4 o 7.x, a seconda della vostra versione di PHP e delle dipendenze.

Il nostro processo di aggiornamento:

1. Audit (1-2 settimane): versioni di PHP e Symfony, log delle deprecation, bundle e loro stato di manutenzione, copertura dei test, hosting.
2. Rete di sicurezza: aggiunta di smoke test e test funzionali sui flussi critici se la copertura è scarsa.
3. Aggiornamento di PHP: passaggio prima a una versione PHP 8.x supportata, con Rector che gestisce la maggior parte delle modifiche di sintassi.
4. Una versione major di Symfony alla volta: da 4.4 a 5.4, da 5.4 a 6.4, da 6.4 a 7.x, eliminando le deprecation prima di ogni passo.
5. Sostituzione dei bundle abbandonati con alternative mantenute o piccole porzioni di codice interno.
6. Configurazione e attributi: passaggio dalle annotation agli attributi PHP, aggiornamento della configurazione di sicurezza al nuovo sistema di authenticator.
7. Rilascio per fasi con monitoraggio, così ogni passo può essere annullato.

Per codice molto vecchio su Symfony 2 o 3, o PHP puro senza framework, di solito consigliamo una migrazione graduale: nuove funzionalità in un'applicazione Symfony nuova, parti vecchie spostate modulo per modulo dietro gli stessi URL.

Come sviluppiamo API con API Platform?

API Platform è il modo più rapido per costruire un'API REST o GraphQL ben documentata su Symfony. Genera endpoint, documentazione OpenAPI, paginazione, filtri e validazione a partire dalle vostre risorse, così il team dedica tempo alle regole di business invece che al codice ripetitivo.

Usiamo API Platform per back end che servono web app React o Vue, app mobile React Native o Flutter e integrazioni con partner. Dove le operazioni di business non corrispondono a semplici creazione, lettura, aggiornamento e cancellazione, scriviamo state provider e processor personalizzati, oppure esponiamo endpoint di azione espliciti. Le regole di sicurezza sono definite per operazione e coperte da test, e il filtraggio multi-tenant è applicato a livello Doctrine così nessun endpoint può esporre i dati di un altro cliente. È lo stesso approccio che usiamo per lo sviluppo SaaS.

Come si risolvono i problemi di prestazioni di Symfony e PHP?

I problemi di prestazioni di Symfony stanno quasi sempre nel livello del database o in lavoro svolto durante la richiesta che dovrebbe girare in background. Partiamo misurando con un profiler su schemi di traffico reali, poi correggiamo per primo il costo più grande.

Riscontri e correzioni comuni:

Ritoria, una piattaforma Symfony che abbiamo sviluppato con 54 entità di dominio, tre provider di pagamento e un back office EasyAdmin di 38 sezioni, è rimasta in produzione su AWS per due anni e mezzo attraverso 120 migrazioni del database. Prodotti di lunga durata come questo restano veloci solo quando le verifiche delle prestazioni fanno parte dello sviluppo ordinario, non di un progetto d'emergenza.

Come lavoriamo con i team Symfony

Partiamo da una breve call e, per i progetti esistenti, da un audit del codice che si conclude con un report scritto e un piano. Per i nuovi sviluppi partiamo dallo scoping e da un preventivo fisso per la prima milestone. Poi consegniamo milestone a perimetro fisso oppure forniamo un team Symfony dedicato su base mensile, con codice e infrastruttura sempre nei vostri account. Se state ancora scegliendo un framework, leggete Symfony vs Laravel per il SaaS.

Prenotate una call con un lead Symfony e raccontateci il vostro progetto, la vostra versione attuale di Symfony e cosa non funziona.