Understand your feature’s development, and stay connected to its changes

As teams become more autonomous and remote, it can be difficult to keep track of everything that is happening with your team’s feature development. This shouldn't be seen as a negative ever — it means that your teams are releasing features and functionality regularly! This can however bring up some problems — such as WHEN did something get released, and WHO will be receiving it?

We’ve all been in these situations: You do your best to manage everything that is going on and being worked on, but, with so much going on you might not be able to keep tabs on absolutely everything going out to your users.

When you get to a healthy development lifecycle, there will be a lot of features and feature flags going on and off all the time. Sometimes you might find yourself wondering “when did this get done?”, or, “why is this user seeing this feature right now?”. We at DevCycle felt this pain, and because DevCycle has become the main point of feature management for teams (not just us!), we put effort into providing this type of information directly in the platform!

With this history, your team will be able to identify exactly when something was released, or even why when looking at the targeting rule changes. This has already been extremely useful here at DevCycle — there have been a few times when a piece of functionality is behaving unexpectedly. Rather than triggering the bug ticket flow and having engineers investigate at a technical level, we’ve been able to quickly see that these features were simply not targeting the right individuals! The erroneous changes were clearly stated in the change-log and we were able to correct them without needing to dive down the entire QA and investigation path.

Available everywhere, right now.

This history is directly available on any feature within the platform, right now! Any time anyone saves any change to a feature, this information will be instantly available in the history section. This is broken down into types.

What information is available?

Any change at all is tracked and is parsed into a readable format for you to understand exactly what is going on.

Even if a targeting rule is modified and has a different method of targeting, the information will contain exactly what has been changed.

Why is this important?

Let me walk you through an example where this history has already been useful to us here at DevCylce...While an embarrassing tale, it clearly highlights why this information is important to have.

Within DeVCycle there was a brand new feature release recently, and it was specifically targeted to internal users on one of our teams as they developed it. Now, being on the product side, I wanted to give this feature to myself early and test it out. So, I added a rule, which enabled this feature for my email address.

After I made this change, I did not see this feature.

This became a problem immediately! If I am unable to see this feature, how will our users? Is this a bug? Is this an implementation issue? Maybe an SDK problem?

Well, historically this type of situation would lead to a bug ticket investigation which can take a lot of engineering time and resources... However, instead of that, a team member was able to look at the history.. and they saw that I had simply entered my email address incorrectly at the time.

Having this history gave our team the ability to quickly investigate a potential issue within a feature and solve it on the spot without any extra engineering work.