I am currently maintaining a corporate Intranet built on Laravel 5.2. Alot has changed since then, and most of it for the better!
My question to all of you would be this: How would you go about updating the framework? Do any of you have any experience with Laravel Shift? I realize I would be responsible for custom code changes regardless, but it seems like it might handle the actual framework upgrades, which I'm less confident about (and imagine it would take forever).
I see the reasoning applying these changes, but I would really think about it, if it is necessary.
Also remember, before doing any changes/upgrade, make sure you back-up the project, so that you can simply go back if you anything went wrong.
This thread is similar topic.
Good luck.
@dleroari Thanks for the response! I have thought for a few months now on whether it is worth the upgrade. In the end I have come to the fantastic decision of Maybe.
The biggest problem would be if I leave that codebase as it is, it will become more and more problematic to place newer apps on the same server (without moving to a fancier solution like multiple php versions). I am not a server administrator, so I try to keep server dealings at a minimum.
Our current setup is we have a 3 tier server architecture internally for apps we want access to on our network (the Intranet, employee directory, various forms, front-ends to microsoft databases, etc). We also have a database server (for hosting all of these databases) and a file server (for storing all of these files). The current desire (maybe I need to be convinced otherwise) is to have a single server (think: we don't have unlimited IP addresses, even internally. My networking team might dislike me if I add too many) where I can run all of the various apps for internal use. This makes server management a little more simple, and is less complicated for our network team.
So, this is the main reason for thinking it might actually be necessary. It hasn't been deemed necessary for the 3 years or so since it was built, but now presents problems. I wasn't thinking and built a Laravel 5.6 app on the same server and Laravel 5.2 by default didn't like PHP7.1 with how the app was configured. So I can foresee many problems in the future if I want to continue having a single server without multiple versions of php and such.
P.S. I have a cloned development server (literally a cloned vm) so I can test with the exact configuration of the server. And backups are running. Definitely important! I'll also likely do a git branch specifically for the framework upgrade, just to track changes separately and be able to support the live/dev versions while I do the upgrades.
Depending on how much you've changed (overridden) or used (referencing methods and code) from Laravel, it could take a few minutes or a few days.
Find and replace could be enough for things like list() to pluck() (example).
Some big changes were made in emails (mailables) so there's that to think about, plus any packages that haven't been updated to 5.6.
If you don't want to upgrade every 6 months, maybe look at Laravel 5.5 LTS?
If you can afford the time investment, just do it.
Maintaining apps that depend on different framework versions is a pain. Context switching between different domains is hard enough without having to also remember which version of the framework you're on, which features are available, etc.
I currently maintain a few 5.5/5.6 apps. The 5.5 apps have not been upgraded mostly due to time constraints, but since 5.5 is LTS, works well with PHP7.1, and there aren't too many differences from 5.6, it's not an urgent matter. Anything under 5.4 that I catch instantly gets upgraded though.
I also maintain a corporate intranet that includes mega applications such as CRM, Project Management, POs, among others. I upgraded from 5.2 to 5.5 last year, and it went relatively smooth. I just started off with the upgrade notes for 5.3, and made my way through all the changes. I would run 5.3 on production for a week or so to make sure everything was stable, and then proceed with the next version.
I found upgrading from 5.2 to 5.3 to be the most intensive, the other jumps to newer versions were completely painless.
If by chance you have 100% test coverage, this gives you much more confidence to make the upgrades. IMO, the upgrade was definitely worth it, but that is a decision you need to make on your own.
@bashy @36864 Thanks for the input.
The biggest problem I foresee (its mostly the ones we dont that scare us) is this uses laravelcollective/html for alot of the forms (dozens I believe) throughout the app. I doubt there was much customization or overrides to the framework itself, just from what I know of the other developer who has worked on it.
I don't think upgrading a single version would be terrible if you keep up with the changes. Much of it can be scripted like in Laravel Shift (from my understanding). The biggest scare is upgrading from 5.2 to 5.6 or even 5.5, thats a LOT of changes to the framework and relevant packages (even the encryption method has changed from mcrypt to openssl, which is more due to PHP itself changing probably, but still).
I guess the biggest question would be is there a process you have that is tried and true, or do you just take it one version at a time and get it working then upgrade again? I feel it will likely need to be a version-by-version upgrade, rather than stepping from Laravel5.2 straight to 5.6. I have never done this part before though, so reaching out to y'all!
@Talinon that is very encouraging right there. And definitely good to hear that not every version upgrade was terrible for you. I'm hoping it won't be for me (no telling until you dive in, right?).
I like the idea of taking it one step at a time. I assume you just devoted a few hours a week to each upgrade, then tested it and pushed it live to ensure everything was working, then repeat? Sounds like a good plan.
Yeah, one step/version at a time. I would make a new branch for each version and just make my way through the change log and test everything.
I upgraded at a pace of one version per week. I'd apply the changes over a weekend, and pray on Monday morning that everything went well. If everything was smooth by mid week, I'd start a new branch and work on the next version.
FYI - laravelcollective/html was removed from the main laravel package, but you can still pull it in through composer to use with any version. I'm still using it with 5.5 without any problems.
Taking it one step at a time would be best. Every app is different and, short of laravel shift's automated tools for upgrading framework code, it's impossible to tell if your app will work well with the new features in each release.
As for the laravelcollective, packages, they should still work if you just upgrade them along with the framework. I would take the opportunity to move away from the HTML package, but that's more a personal preference than anything.
We can't know if your upgrade process will be painless since we don't know your app.
From personal experience, 5.3 to 5.5 had a few small issues, but what I'd call a simple mid-size app was done in an afternoon.
5.4 to 5.5 and 5.5 to 5.6 were generally quite painless.
Your mileage may vary.
If you make that more regular in the future, it will not be that scary any more.
Anyway, I would not skip an upgrade just because it could get complicated. After all, there are also security updates, not just new features, right? :)
Yup, one version step at a time. Just follow the Laravel docs;
I think I'll start the upgrade slowly over the next few weeks from 5.2 -> 5.3. This is (what I consider) a fairly large app (25 Controllers / Models / etc if that helps gauge the size. Lots of views and code).
To my knowledge, LaravelCollective/HTML stopped at version 5.4, but that might not necessarily coincide with the framework version. Either way, moving away from it will likely make maintainability and upgrades easier in the future (one less package to worry about in upgrades), I agree with you on that @36864.
Thanks again for all of your help!
@joshuabedford I use many libraries from the collective and they run fine in 7.1. Main issues I have is PHP code written for 4.x or early 5. Code written in a less (OOP) style in older PHP naming conventions will generate many warnings and will fail silently in certain situations (like pass by ref vs. pass by value) and packages not using Use causing namespace collisions.
@jimmck That's good to know! I have always had good luck with the packages I've used from the collective. I will continue using them where appropriate. I have not really been using the html parts lately in other projects though. I pretty much just build the form in normal html.
With the knowledge you shared with me, however, I might not go through all the trouble of removing the package and rewriting the forms if it will still work in the future.
Please or to participate in this conversation.