Continuous Deployment refers to the ability to continuously deploy changes from the development environment to the production environment, where it can be utilized by users. In an ideal, and Agile organization, new development may take weeks or days to make it to the end user. Since FileMaker is a whole file application, meaning lines of code aren’t updated in production individually, when changes are deployed to production, it’s all or nothing. What does that mean for a complex development environment, where multiple features are being worked on, often in different stages of development? We can’t deploy a file where some features are complete and some are half finished. The answer is feature flags.
What is a Feature Flag?
Many developers are probably already using feature flags without even knowing it. This article hopes to clarify their usefulness and standardize their implementation. A feature flag is a variable or global that is used to turn on or off functionality. Usually this is a boolean value that tells the script or interface element if it should run or not. Feature flags can be used to determine if script steps are skipped, or if new interface elements are hidden. Consider the following script:
If [ $$_ff.newLayout = True ] Go to Layout ( “Layout.v2” )
Else
Go to Layout ( “Layout.v1” )
End If
If the global variable, $$_ff.newLayout, is set to True, the script will use the new layout the developer is working on. If it is not set, or set to False, the script continues to the original layout. This allows the development team to set the feature flag to false before deploying to production if the new layout is not ready for production on the next release.
An important aspect of feature flags is that they are set and stored in a common location. Perhaps all feature flags are set on the initial script when the application loads, they could be set by a layout object when the layout loads, or they could be set at the top of each script. Keeping them in one place makes their management much easier in the long run.
Development Flags
The first type of feature flag is the development flag. This is a simple boolean value that is set by the developer when they are developing and testing their work. These types of flags are usually set to true while the developer is working on the feature in development, but are set to false when deploying to production until the feature is ready to be released. There are a couple of ways the feature can be deployed once it’s ready. Either set and leave the flag set to true, or remove the conditional programming altogether so it always runs as true.
Consider keeping the conditional programming, at least on the initial deployment. Whenever users experience new programming, there is the possibility for errors. By leaving in the feature flag that determines if the new feature runs, the development can quickly be rolled back on production by re-setting the feature flag to false. This allows production to react quickly to any problems by falling back to the previous programming for just that feature.
Environment Flags
A second type of feature flag is an environment flag. An environment flag is set based on a calculation, and results in a boolean value based on environmental variables. Consider a feature flag that only allows a development feature to run on the development host. When the application is deployed to production, this feature flag automatically sets itself to false, preventing the new code from running.
Set Variable [ $$_ff.isDevelopment, Get ( HostName ) = “Development Server” ]
These can be very powerful in determining what programming will run on the client’s machine. A feature flag could be set to run only if a certain developer logs in, so they can test certain features without interrupting other developers testing their code. They can be used to determine what version of FileMaker the client is using, and prevent features that are unavailable in older version from running, instead falling back to the older version. They can be used to determine which operating system the user is running, and run the Mac or the Windows programming appropriately.
Timing Flags
The last type that’s worth mentioning is the timing flag. Sometimes, there are features that are not supposed to run or be available until a certain date. Maybe there is a specific launch time period, and the code has to be available and ready to run on a specific date, but not before then. Maybe a certain feature is being retired and it needs to stop running on a certain date. It can also be useful when coordinating multiple dependent features that all need to be ready to launch at the same time, so that one feature isn’t deployed without the other.
Set Variable [ $$_ff.isDevelopment, Get ( CurrentDate ) >= GetAsDate ( “10/1/2023” )
Using A Global Flag
The development team should agree on a standard practice for how to use feature flags in the application development. Imagine if two developers accidentally are using the same name for a global variable feature flag, with different parts of the code overwriting the variable to different values. One way to ensure consistency is to use a single, global feature flag for all flags. The approach works by encoding all the feature flags into JSON key-value pairs at the launch of the application.
This allows all the flags to be easily seen and compared. When developers are creating new flags. The single variable makes all flags easily determined at any point in the programming since there is one place to look, rather than multiple global variables. Any developer can review and update any flags individually using the Data Viewer, and their changes only apply to their session. This is very helpful when developers are working on different features and may need a combination of flags set a certain way in order to test their functionality, without disturbing how other developers have their flags set. Now, the conditional programming checks an element of a global variable:
If [ JSONGetElement ( $$_ff ; “newLayout” ) = True ] Go to Layout ( “Layout.v2” )
Else
Go to Layout ( “Layout.v1” )
End If
Feature flags can be extended to be as simple or as complex as your development needs. They enable developers to carefully select which features are deployed to production in a Continuous Deployment environment to ensure nothing is released without meeting the quality standards expected in production. Happy coding!
