As one of the world's largest automakers, General Motors can't afford to fall behind its competition. And, given how much software is involved in vehicles today, especially with the transition to all-electric energy sources, teams working on these machines need new ways to handle the escalating complexities.
Jim DeMercurio, Director of Mobile Solutions in the Digital Business Team at General Motors (GM), recently spoke about the role feature flags are playing at GM and how LaunchDarkly is assisting. Currently, Jim is responsible for all customer-facing mobile applications, including Mybrand (MyGMC, MyChevrolet, MyCadillac, MyBuick) and Onstar Guardian.
If you've worked on mobile apps, you know how dizzying the variables for a smooth customer experience can be, and how software quality control can be extra difficult because of it.
"I have so many models of phones and different variations of the OS, and then my phone intersects with the vehicle," Jim says. "Well, I have so many makes, models, and years of the vehicle. Oh, and I have subscription accounts, and I have so many different types of subscriptions. And you take the permutation of all of those and it becomes impossible to test them all. I don't care how much automated testing you have and... You just can't, impossible."
According to Jim, adding more test cycles is not the answer. Instead, he's discovered a method with LaunchDarkly that has been very successful.
"The model here with LaunchDarkly is going to solve it a hundred times better, and it has proven for us already," he says.
In Jim's talk, he also covers a journey he’s personally taken numerous times: intersecting the combination of implementing Agile and many Agile methodologies in conjunction with feature flags and LaunchDarkly's capabilities.
As always, we recommend you watch the full session to get the full effect. In the meantime, here’s a quick breakdown of how Jim described his (and GM’s) journey with implementing LaunchDarkly.
The problem with big bangs
Jim’s main goal is to release value to customers as quickly as possible without compromising quality. However, traditional “big bang” releases weren’t cutting it. In Jim’s case, these big bang releases were problematic on several levels, including:
- Changing too much code at one time, requiring long triage sessions
- Long integration cycles
- Unstable test environments
- “All-or-nothing” releases
Initially, Jim introduced defensive feature flags as a kill switch to turn off problematic features without rolling back the entire release. However, this only solved one of the pain points. He observed that in a lot of cases, teams will do that, but without changing anything outside of delivering more often—so their overall cycle time is still the same.
Jim noted that this actually caused more problems than it solved. “So yeah, I can check the box that says I can get value to my customer quicker,” he says. “However, I can't react quicker because I still have the long lead time to get there. I'm deploying every month, but I have a four-month cycle, so it's four months to get anything out. And now I have three releases that I'm working on at the same time.”
The most crucial step was to reduce cycle time, aiming for continuous deployment and separating deployment from release. This approach allows for quick reactions to customer needs and makes deployments a non-event. By combining shorter cycles with LaunchDarkly, General Motors now delivers value to customers faster and with higher quality. (Hooray!)
Getting the most out of feature flags
Jim's team can now use offensive feature flags (for understanding, testing, and learning) as well as defensive ones (like a kill switch). This two-pronged approach provides flexibility in the release process, especially around areas such as deploying and releasing simultaneously or conducting A/B testing, beta, or pilot programs.
As mentioned earlier, Jim’s team has to test a high number of mobile app configurations to ensure things are working as intended. The solution with LaunchDarkly has been to test real-world permutations by leveraging production and gradually exposing features to a small subset of users, and then expanding out from there.
And because of this capability, General Motors has started testing early features in production with company vehicle drivers, which allows them to find issues and make adjustments based on internal feedback before releasing them to the public. And guess what? This approach has been more effective than increasing test cycles in early environments.
"We found a number of issues that, in the past, we would've never found until our customers got their hands on it," Jim said. "And so instead of using my customer to find issues, I'm able to do it internally."
Paving the road ahead
So, what’s next for Jim and GM? On the mobile side, all their features are currently wrapped behind flags in LaunchDarkly. Future plans include integrating LaunchDarkly into back office systems, growing their use of A/B testing, and automating the feature switch ramp-up and ramp-down process based on performance metrics. This will help minimize customer impact and streamline the rollout process. So many wins all around.
Again, you can view the full video here to get all of the details we couldn’t cover here while seeing Jim explain his use cases with some helpful visuals and extremely organized pain point bullet points that he tackles one-by-one with the most satisfying of strikethroughs.
.webp)
