Transcript

With over several thousand upgrades, Shift has a lot of experience on what makes a codebase easy to upgrade.

Here are a few suggestions specific to Laravel projects.

First, don't customize the App namespace. Just leave it App. Even the creator of Laravel recommends keeping this simple. In addition, this is one less difference for Shift to automate.

If you have changed it, you can change it back quickly by running php artisan app:name App

Next, the configuration files can be another maintenance nightmare.

Always be sure to leverage the default ENV variables wherever possible.

In addition, when adding several custom configurations, consider creating a separate config file. A simple name like system, core, or an app name work well.

Both of these will help limit unnecessary customizations to the core configuration files which change frequently between versions.

Another thing to avoid is adding application components outside the app folder. Doing so not only excludes them from Shift's upgrade process, but also becomes an additional area to maintain.

If you want to logically separate these components, you should create your own private package.

Finally, make an effort to use the components within the framework first.

While packages are awesome, but each one adds more weight to your project.

Becoming more and more you have to maintain.

Laravel often has built-in features that work for a majority of use cases. So try these first.

If you need to override framework level components, tag them with an @inheritdoc block. This way if the core method changes between versions you have a reminder to review the original reference.

In the end, you are of course welcome to customize as much of the code as you like. Yet sticking with the defaults and isolating customizations will not only keep your code in a Shiftable state, but also make it easy to reason about over time.