Home

DevFlag in real-life practices

1. For new code

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>
}

2. New logic for existing code

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.

3. Additional info

• 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)

Conclusion

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.