Розробка на Symfony: виділена команда для нових продуктів і оновлень

Чому варто обрати компанію з розробки на Symfony, а не окремих розробників?

Компанія з розробки на Symfony дає вам робочу команду зі спільними практиками з першого тижня, замість того щоб самим збирати окремих людей і керувати ними. Фрилансери добре підходять для невеликих, чітко визначених завдань. Найм у штат добре працює на довгу перспективу, але зазвичай займає місяці на кожного senior-розробника Symfony. Виділена команда від компанії закриває цю прогалину: архітектура, код-рев'ю, QA та DevOps уже включені, а команда може збільшуватися чи зменшуватися відповідно до вашої дорожньої карти.

Symfony для нас не побічна навичка. PHP/Symfony - основний бекенд-стек Lytvynov Production, і на ньому працює багато бізнес-платформ, які ми створили, від власної ERP до маркетплейсу для авторів.

Яка вона, виділена Symfony-команда?

Виділена Symfony-команда - це стабільна група інженерів, які місяцями чи роками працюють лише над вашим продуктом і всередині ваших процесів. Поширений стартовий склад: один senior-інженер Symfony, що відповідає за архітектуру, плюс один-два Symfony-розробники, а фронтенд-розробник (React, Vue або Angular), QA та DevOps долучаються на часткову зайнятість за потреби.

Команда працює у ваших репозиторіях і системі тікетів, бере участь у ваших стендапах і дотримується ваших правил код-рев'ю й релізів або приносить власні, якщо у вас їх ще немає. Ми працюємо англійською (і французькою, коли це доречно), з перетином робочих годин для часових поясів Європи й США. Усередині команди ми використовуємо ШІ-агентів для написання коду під наглядом senior-інженерів для рутинної роботи на кшталт тестів, міграцій і рефакторингу, тож більша частина бюджету йде на те, що потребує людського судження. Як робота з українською командою виглядає порівняно з іншими варіантами, читайте в статті про аутсорсинг розробки ПЗ в Україну.

Як ми створюємо нові застосунки на Symfony?

Нові застосунки на Symfony починаються з предметної області, а не з фреймворку. Спершу ми моделюємо бізнес-сутності й правила, потім відображаємо їх на сутності Doctrine, сервіси й обробники повідомлень і тримаємо бізнес-логіку поза контролерами, щоб її можна було тестувати й використовувати повторно.

Наше стандартне налаштування для нової розробки:

• Symfony на актуальному PHP 8.x, strict types, PHPStan на високому рівні з першого дня.
• Doctrine ORM з PostgreSQL або MySQL і версіонованими міграціями.
• API Platform для продуктів за принципом API-first або Twig із Symfony UX для інтерфейсів із серверним рендерингом.
• Symfony Messenger з Redis або RabbitMQ для фонових завдань, листів, імпорту й інтеграцій.
• Mercure для оновлень у браузері в реальному часі.
• EasyAdmin для бек-офісів, які потрібні швидко.
• Docker, CI/CD і автоматизовані тести (PHPUnit, функціональні тести) у конвеєрі ще до виходу першої функції.

Так була створена власна ERP для американської компанії з обслуговування літаків: шість місяців на Symfony/PHP, React, SQL і Mercure. Керування клієнтами й замовленнями, планування обслуговування літаків, зміни персоналу, синхронізовані з календарями Google, Apple і Team, складський облік у реальному часі й контроль відповідності регуляторним вимогам. Нею щодня користуються всі, від наземного персоналу до CEO.

Як оновити старі проєкти на Symfony 4 чи 5 до 6.4 або 7?

Оновлення старого проєкту на Symfony означає рух по одній мажорній версії за раз, виправлення застарілих викликів перед кожним стрибком і збереження можливості розгортати застосунок протягом усього процесу. Проєкти на Symfony 4.4 давно вийшли за межі підтримки, а Symfony 5.4 вийшов із періоду звичайних виправлень помилок, тож такі проєкти більше не отримують регулярних виправлень і часто прив'язані до старих непідтримуваних версій PHP. Ціль сьогодні зазвичай актуальний реліз із довгостроковою підтримкою в лінійці 6.4 або 7.x, залежно від вашої версії PHP і залежностей.

Наш процес оновлення:

1. Аудит (1-2 тижні): версії PHP і Symfony, журнал застарілих викликів, бандли та стан їхньої підтримки, покриття тестами, хостинг.
2. Страхувальна сітка: додаємо smoke- і функціональні тести для критичних сценаріїв, якщо покриття слабке.
3. Оновлення PHP: спершу переходимо на підтримувану версію PHP 8.x, більшість змін синтаксису бере на себе Rector.
4. По одній мажорній версії Symfony за раз: 4.4 до 5.4, 5.4 до 6.4, 6.4 до 7.x, з усуненням застарілих викликів перед кожним кроком.
5. Заміна покинутих бандлів на підтримувані альтернативи чи невеликий власний код.
6. Конфігурація й атрибути: переносимо анотації на PHP-атрибути, оновлюємо конфігурацію безпеки під нову систему автентифікаторів.
7. Поетапний реліз із моніторингом, щоб кожен крок можна було відкотити.

Для дуже старого коду на Symfony 2 чи 3 або на чистому PHP без фреймворку ми зазвичай радимо поступову міграцію: нові функції в новому застосунку на Symfony, а старі частини переносяться модуль за модулем за тими самими URL.

Як ми створюємо API на API Platform?

API Platform - найшвидший спосіб створити добре задокументований REST- чи GraphQL-API на Symfony. Він генерує ендпоінти, документацію OpenAPI, пагінацію, фільтрацію й валідацію з ваших ресурсів, тож команда витрачає час на бізнес-правила, а не на шаблонний код.

Ми використовуємо API Platform для бекендів, що обслуговують вебзастосунки на React чи Vue, мобільні застосунки на React Native чи Flutter та інтеграції з партнерами. Там, де бізнес-операції не зводяться до простого створення, читання, оновлення й видалення, ми пишемо власні state providers і processors або відкриваємо явні ендпоінти для дій. Правила безпеки задаються для кожної операції й покриваються тестами, а фільтрація за тенантами застосовується на рівні Doctrine, тож жоден ендпоінт не може розкрити дані іншого клієнта. Такий самий підхід ми використовуємо в розробці SaaS.

Як розв'язати проблеми з продуктивністю Symfony і PHP?

Проблеми з продуктивністю Symfony майже завжди лежать у шарі бази даних або в роботі, яка виконується під час запиту, хоча має йти у фоні. Ми починаємо з вимірювань профайлером на реальних патернах трафіку, а потім усуваємо найбільші витрати першими.

Типові знахідки й рішення:

Ritoria, платформа на Symfony, яку ми створили, з 54 доменними сутностями, трьома платіжними провайдерами й бек-офісом на EasyAdmin із 38 розділів, два з половиною роки працювала в продакшені на AWS і пройшла через 120 міграцій бази даних. Довговічні продукти на кшталт цього лишаються швидкими, лише коли перевірки продуктивності є частиною звичайної розробки, а не аварійним проєктом.

Як ми працюємо з Symfony-командами

Ми починаємо з короткого дзвінка, а для наявних проєктів з аудиту коду, що завершується письмовим звітом і планом. Для нових розробок починаємо з оцінки обсягу й фіксованої ціни першого етапу. Далі ми або виконуємо етапи з фіксованим обсягом, або надаємо виділену Symfony-команду на щомісячній основі, а код та інфраструктура завжди лишаються у ваших акаунтах. Якщо ви ще обираєте фреймворк, прочитайте порівняння Symfony чи Laravel для SaaS.

Запишіться на дзвінок із лідом Symfony-команди і розкажіть про ваш проєкт, поточну версію Symfony і те, що не працює.