It's sort of normal. Legacy software can be (re)defined as "what runs in production." It generates revenue but has accreted significant tech debt.
Not saying normal isn't dysfunctional--no tests at all is a little insane. At the same time, it enabled the business.
With better tooling now, of course some issues are more obvious. Maybe the codebase has its own patterns or way of doing things; some fixes might be more risky than others.
There are upgrade branches but somehow they are stale and not worked on anymore. Probably so hard to and test everything manually that they stoped trying at all. How would you go on a project like this if you were to be the new lead there?
After buy-in from higher-ups and the associated teams, look at the development cycle and build process, how a change goes from local to production.
Add automation around linting, running the test suite, and build & deployment. A lot of it can go in dark, in case there's concern about blocking urgent things. Lay down a skeletal pipeline.
Create a couple template projects, for front- and backend, so future projects can start at the highest quality bar and with latest dependencies.
Partner with QA to collect and document test scenarios. On the frontend, at least you'll be able to mock or stub the backend.
Eventually, you'll want this system to block merges and deployments based on agreed-upon criteria. Exceptions can be made, so long as it's documented.
Throughout, it would be nice to add tests. It's an opportunity to understand the domain with fresh eyes as well.
At least its maintained, but yeah a lot of old dependencies that are not maintained anymore. Is it worth updating every dependency one by one and try to upgrade the whole thing?
It's sort of normal. Legacy software can be (re)defined as "what runs in production." It generates revenue but has accreted significant tech debt.
Not saying normal isn't dysfunctional--no tests at all is a little insane. At the same time, it enabled the business.
With better tooling now, of course some issues are more obvious. Maybe the codebase has its own patterns or way of doing things; some fixes might be more risky than others.
There are upgrade branches but somehow they are stale and not worked on anymore. Probably so hard to and test everything manually that they stoped trying at all. How would you go on a project like this if you were to be the new lead there?
After buy-in from higher-ups and the associated teams, look at the development cycle and build process, how a change goes from local to production.
Add automation around linting, running the test suite, and build & deployment. A lot of it can go in dark, in case there's concern about blocking urgent things. Lay down a skeletal pipeline.
Create a couple template projects, for front- and backend, so future projects can start at the highest quality bar and with latest dependencies.
Partner with QA to collect and document test scenarios. On the frontend, at least you'll be able to mock or stub the backend.
Eventually, you'll want this system to block merges and deployments based on agreed-upon criteria. Exceptions can be made, so long as it's documented.
Throughout, it would be nice to add tests. It's an opportunity to understand the domain with fresh eyes as well.
Add mutation testing too.
you should upgrade to symfony 6.4, which is the long term release
you can still use 5.4 up until 2026, but you need to update your packages
https://symfony.com/releases
this will show you how to upgrade: https://symfony.com/doc/6.4/setup/unstable_versions.html
At least its maintained, but yeah a lot of old dependencies that are not maintained anymore. Is it worth updating every dependency one by one and try to upgrade the whole thing?
the errors are most likely coming from the custom code, you might need to update those yourself
yeah I'm sure they are, thanks alot