Home
Feature flags are awesome, they help us separate the technical process (deploying a feature) from the business process (activating a feature). What isn't awesome is having to redeploy code to activate a feature or modifying live code or a database value. These steps are very technical and sometimes go against CI/CD principles. There has to be a better way!
Imagine you just nailed your client demo. They are all excited about this new feature, and they ask when it can go live. Do you want to tell them "let me fire the code, do a new release" or "I need to modify a web.config file"? What if you or your client could just go to a website, click a couple of buttons and instantly your feature was activated? Wouldn't that be better?
Moggles is just that solution. We created a web interface, API and client package that can handle all of that (and more).
Moggles comes in 2 parts, the server/web interface and the client package (available as NuGet package). Using our code, you setup your own private server and configure the Application, Environment and Features. Next, install the NuGet package in your .NET application (ASP.NET and .NET Core are both supported), register the service, and create a new class for your feature (we think class based toggles are the best). Now you can control your feature from anywhere.
If you are not familiar with Feature Toggles, you should read up on them first. Essentially, you wrap a feature, or some code, with an IF statement like if Is<MyFeatureToggle>.Enabled. You then have control over that switch from the server website.
Yes! In fact, I would say it is required. With CI/CD, you are pushing code to your live server as often as people make it and test it. However, you may not be ready for the code to be activated on the live server. That is where feature flags come in. Our setup supports multiple environments for the same flag. So, you can have the feature activated for Dev and QA, but deactivated for Production. Then, when you are ready, you just activate the flag on Production, and since your code bits are already there, the feature starts working.
While the developers are likely the ones who will implement the feature flags, you now have some options for who can control the feature flags. We found that Moggles gave control to the NON-developers, such as Business System Analysts, Scrum Masters, or Product/Project Managers. Creating and deploying the code is a technical detail, but activating a feature is a business concern, so it is the business-facing members of your team that will benefit the most.
- Generic Feature flag Management
- Multiple Environments
- Multiple Applications
- Permanent Feature flags
- Activate code during holidays
- Activate maintenance messages
- Tracking flag state across multiple environments
- Tracking code readiness across multiple environments
- Feature flag tracking (in order to delete later)
- Standby Functionality
- Direct control by Business
- Direct control by QA/Testers
We needed to. We easily lost track of which feature was supposed to be on in which environment, if it was live yet, and whether it was approved by the client. We tried web.config settings, or database settings, but we still had no visibility, and the people that needed to know the most, our BSAs, couldn't get that information directly. We considered using an online feature toggle management service, but cost was prohibitive. We looked for other projects to add to, but couldn't find any. So, we wrote our own. Now, we use Moggles every day to manage over 15 internal applications across 5 environments. Our team can easily manage over 100 feature toggles without dropping any balls.
We love open source, we use open source, but most of the code we write is proprietary, and can't be shared. So, when we saw the opportunity in Moggles to give back to the community, we jumped at it. We were inspired by other open source projects to write this project and we can only hope that this project will help and inspire someone else to go further.