Use devFlag to ensure no one can access your new code (methods, classes).

You can either return something simple (null, false,...) or throw an Exception.

// new method
public function transfer(): ?Transaction
{
    if (!useDevFlag('useTransfer')) {
        return null;
    }

    // handle transfer
    // ...
    return $transaction;
}

Same for Blade View, if this button is newly added and you don't want people to use it on production just yet, go like this:

@if (useDevFlag('useTransfer')) {
    <button>Transfer</button>
}

Eg we need to update some values after User is registered. I have a devFlag called useAddtionalDataAfterRegistration

public function register(RegisterRequest $request): JsonResponse
{
    $user = User::create(array_merge($request->validated(), [
        'password' => bcrypt($request->validated('password')),
    ]));

    if (DevFlag::can('useAddtionalDataAfterRegistration')) {
        app(AddtionalDataRegistrationService::class)->append($user);
    }

    return new JsonResponse();
}

And for my AddtionalDataRegistrationService service class, the append method would have the same check as #1.

• Once Feature is enabled on production, after a while (eg 2 weeks), you need to get rid of the devFlag check (to keep it clean)
• You can also do devFlag check when registering routes, to ensure other people won't access it.
• When adding a new flag, remember to add for ALL ENV (local, testing, staging, uat?, production)

With devFlag there, you can ensure you will follow the:

• Keep PR as small as possible (nobody like big PR).
• CI/CD best practice.
• Always up-to-date with the base branch.
• No merge/rebase hell.
• A healthy codebase for the long run.