devopsy.kinsta.cloud

Tag: feature management

  • Feature Management’s Role in DevOps with Trevor Stuart

    Feature Management’s Role in DevOps with Trevor Stuart

    Trevor Stuart, general manager and senior vice president of Harness, explains how feature management is becoming a critical extension of DevOps workflows a year after the acquisition of Split Software. 

    Feature management is fast becoming a critical pillar in modern DevOps workflows, especially as organizations seek to keep up with the rising volume and velocity of software development. Stuart discusses how the evolution of feature flags has reshaped deployment practices and the expectations of software delivery teams.

    The core value of feature flags lies in their ability to enable safer, faster releases. They give teams the flexibility to toggle functionality without redeploying code, making it possible to mitigate risk during production rollouts. Initially used sparingly and often managed via manual config files, feature flags are now a mainstream method for progressive delivery. They help organizations validate features with specific user segments, reduce blast radius when issues arise, and support experimentation in real-world conditions.

    Stuart highlights that the growing use of AI-generated code, modular microservices, and increasing product personalization have only amplified the need for robust feature flag systems. These tools now serve not just as toggles, but as real-time control layers for dynamic configuration, adaptive experimentation, and telemetry-based feedback. Companies are increasingly using them to fine-tune AI models, personalize customer experiences, and refine software quality using real-time performance data.

    Despite broad awareness, many teams still rely on homegrown or brittle solutions, leading to maintenance issues and outages. The challenge is often organizational: determining whether to build, buy, or integrate these capabilities into broader CI/CD pipelines. Stuart argues that deeply integrating feature flagging into delivery workflows—particularly as part of a unified platform—is essential for scale and consistency.

    As software complexity grows, so does the need for intelligent automation. Stuart envisions pipelines that not only deploy features but also observe impact, run experiments, adapt based on results, and even feed signals back into models. It’s a shift from manual gates to data-driven automation, marking a pivotal transition in how DevOps teams manage risk, velocity, and innovation.

  • Harnessing Generative AI for Feature Management Testing

    Harnessing Generative AI for Feature Management Testing

    When it comes to DevOps, the emerging integration of generative AI into feature management testing marks a significant evolution. We’re going to take a no-nonsense look at how this technology is revolutionizing the way we create testing environments. 

    Using artificial intelligence to generate tests allows us to mimic a vast array of user scenarios and environments, which means we can develop and deploy features that aren’t just good but great—robust, efficient and ready for whatever the real world throws at them. 

    Embracing Generative AI in DevOps Testing

    Artificial intelligence is dramatically transforming the world around us, impacting a wide variety of industries at breakneck speeds. A stunning 83% of companies assert that AI is a critical component of their business strategies, particularly when it comes to software development.

    Generative AI has quickly become a transformative tool when it comes to DevOps, particularly when it comes to feature management testing, by leveraging machine learning algorithms to generate data and test scenarios that closely mimic real-world conditions.

    Traditionally, DevOps teams have relied mostly on manual and a couple of automated testing methods to validate their features. However, these methods often fail to accurately simulate the wide variety of complex and unpredictable user interactions and environmental variables. 

    By creating nuanced and diverse test cases, generative AI can fill this gap, enabling a more thorough evaluation of features under various conditions. Even now, on a smaller scale, WordPress site owners are using predictive analysis and even simple comparisons to properly orchestrate the rollout of new features–with over 60,000 plugins to choose from, generative AI has the potential to prevent lag, which can often be the result of a single shoddy plugin. 

    Simply put, AI is actively improving how features are implemented and tested across various platforms by intelligently crafting diverse test scenarios. 

    Enhancing Test Coverage and Efficiency

    The significant expansion in test coverage is one of the key benefits of integrating generative AI into DevOps testing. Traditional testing methods are typically limited by the scenarios that testers can foresee and manually script.

    In contrast, AI-driven testing tools can generate a multitude of unique, unexpected test scenarios, capturing edge cases that might otherwise go unnoticed, which is crucial in identifying potential bugs and vulnerabilities early in the development cycle, saving time and resources in the long run. 

    Additionally, AI can automate both the creation and implementation of these tests. This simplifies the testing workflow, allowing human testers to dedicate their full attention to more intricate and challenging tasks.

    Simulating Real-World Scenarios

    Another key advantage of generative AI in DevOps is its ability to simulate real-world user behavior and environments. 

    AI models can create realistic and diverse user scenarios by analyzing historical data, user patterns, and environmental variables. This type of functionality is a huge asset in feature management, where understanding how new features will perform in the real world is paramount. 

    To use a couple of examples, an AI model can generate test cases that mimic peak usage times, varying network conditions, or different user demographics. Furthermore, companies like Netflix, Google and IBM are already actively using generative AI to simulate real-world scenarios for various applications, such as content delivery optimization, predictive maintenance, and software testing. 

    Accelerating Feature Development in DevOps

    The integration of generative AI into feature testing also accelerates the feature development and deployment process. 

    A well-constructed prompt chain can set up an environment where DevOps teams can effectively compare different products/services, especially when it comes to more sensitive software, such as cloud management platforms and even find the best ways to escape vendor lock-in without actually wasting time manually comparing and testing everything. 

    Applying generative AI can also drastically cut down on the time it takes to validate a new feature by generating and running through thousands of test scenarios in quick succession. In DevOps environments, where rapid iteration and continuous deployment are key, this is essential. 

    AI-driven testing can also provide developers with immediate feedback, allowing for quick adjustments and improvements. This ensures that features are developed faster while meeting the highest quality standards before proper deployment.

    Potential Challenges and Considerations

    While the potential of generative AI in DevOps testing is immense, there are challenges and considerations that teams must navigate and work to overcome to successfully apply this powerful new tool. 

    One key issue is the quality and relevance of the data used to train AI models; since inaccurate or biased training data can lead to suboptimal or even harmful outputs, carefully selecting and curating data is a crucial step​​​​.

    Incorporating generative AI into established DevOps processes can also present challenges in terms of complexity and resource demands. Organizations may face significant challenges in modifying their existing pipelines and processes to accommodate AI technologies, which often require substantial investments in hardware, software and skilled personnel.

    Lastly, the need to continuously improve and update AI models cannot be overstated. As new technologies and security threats emerge, these models must be regularly refined and adapted to remain effective and relevant, which will require ongoing investment in AI systems and a commitment to staying abreast of evolving technologies and methodologies in what is a rapidly evolving and advancing field.

    Future Directions of Generative AI

    Looking forward, the role of generative AI in DevOps is poised to grow even more prominent, and as AI models become more sophisticated and data-rich, their ability to generate realistic and complex test scenarios will only improve. 

    But let’s look beyond just creating testing environments and isolated testing environments: A well-executed, AI-aided process can reduce costs during SAP staff augmentation and can also streamline processes in other high-level enterprise systems such as Oracle ERP and Salesforce CRM. Overall, ERP software is a perfect candidate for DevOps feature management, as it allows devs to use generative AI for everything from writing code to custom tests. 

    We can also expect to see further integration of AI in other aspects of DevOps, such as monitoring and performance optimization. The ultimate goal is to create a seamless, AI-enhanced pipeline that tests and deploys features efficiently and continuously learns and improves from real-world feedback.

    To better illustrate this transformative impact, some key examples of how generative AI will further impact DevOps in the future include the following: 

    • AI-Augmented Development: Generative will assist developers with code suggestions, bug fixes, and even making architectural decisions, thereby streamlining the development workflow​.
    • Improved Infrastructure Management and Automation: The use of predictive analytics, driven by generative AI, will play a crucial role in anticipating infrastructure requirements, facilitating preemptive scaling, and efficient distribution of resources.
    • Adaptive Problem Resolution and Incident Handling: Generative AI is set to revolutionize the way operational problems are identified, diagnosed, and resolved swiftly, greatly boosting the dependability and steadiness of DevOps practices. This is evident in platforms such as Google Cloud’s operations suite, where such AI capabilities are already making a significant impact. 
    • Generative AI in Proactive DevOps: This emerging trend focuses on leveraging generative AI to anticipate potential issues before they manifest, which enables preemptive maintenance strategies and is aimed at reducing system downtime.
    • AI-Driven Testing and QA: AI-powered testing will become more sophisticated, with capabilities such as automated test case generation, test data creation, and advanced anomaly detection​.

    Harnessing Generative AI in DevOps

    Integrating generative AI into DevOps is a groundbreaking development poised to revolutionize how we approach software development, testing, and infrastructure management. 

    This innovative technology offers immense potential to automate complex tasks, enhance efficiency and improve the quality and reliability of software products. However, as with any emerging technology, its adoption comes with its own set of challenges and considerations.

    Enterprises aiming to leverage generative AI within their DevOps practices must address challenges associated with data integrity, intricate integration processes, adherence to privacy laws and the necessity for ongoing enhancement of their AI models.

    Despite these challenges, the benefits of adopting generative AI in DevOps are quite substantial, ranging from increased efficiency and cost savings to enhanced scalability and improved overall software quality.

  • LaunchDarkly Previews Generative AI Testing Tool for Feature Management

    LaunchDarkly Previews Generative AI Testing Tool for Feature Management

    At the AWS re:Invent 2023 conference, LaunchDarkly today previewed an ability to leverage generative artificial intelligence (AI) capabilities to create experiments for its feature management platform.

    Based on the Bedrock foundational large language models (LLMs) made available via AWS, this extension to the company’s Product Experimentation platform promises to make it simpler to use historical data to create a wider range of offerings that might be made available within an application.

    LaunchDarkly is making a case for a SaaS platform that can be used to centrally manage features across multiple workflows and platforms.

    Robert Neal, director of engineering for LaunchDarkly, said the company is now extending its testing capabilities using a managed Bedrock service provided by AWS that will enable leveraging generative AI to define a testing hypothesis more easily. That should also make it possible to involve more stakeholders in an iterative testing process within the context of a set of well-defined guardrails, he added.

    As more organizations start to deliver different tiers of digital services at varying price points, there is a clear need to be able to restrict access to those digital services. Application development teams have been employing feature management since the 1970s to isolate the development of various components into a branch that can be worked on and tested without impacting the primary build the application is based on.

    Feature management enables development teams to experiment with adding new capabilities in a way that doesn’t disrupt the application. When a project is completed, that branch is then usually merged into the primary build or can be deployed as a microservice that might be invoked via an application programming interface (API) by other modules with the application or another external application.

    At the core of that capability are what are known as feature flags, also known as feature toggles or feature switches, that make it possible to dynamically turn services on or off based on who is accessing them. Rather than being limited to the application development process, those feature flags are now being employed in production environments to enable the continuous delivery of multiple types of digital services to various classes of users of an application. A feature flag management platform enables an organization to keep track of all the flags being employed to keep the overall application environment consistent.

    It’s still early days in terms of understanding the extent to which generative AI can be applied to DevOps workflows, but it’s clear many of the manual processes that conspire to slow down the pace at which applications are built and deployed are going to be either reduced or outright eliminated. Each DevOps team will naturally need to determine for itself to what degree DevOps workflows can be automated using AI, but the overall pace at which applications can be built and deployed is going to clearly accelerate. The challenge now will be finding ways to keep pace with a rate of application development that is about to exponentially increase.

  • The Life and Times of Feature Flags

    The Life and Times of Feature Flags

    A while back, I had the opportunity to look closely at DevSecOps tools (as the market currently defines them). There was a lot to like, and they are moving forward to a “Find all of the vulnerabilities, all of the time” future … Except there will be new vulnerabilities that aren’t as easy to catch once we get there, and our journey will continue.

    More recently, I’ve had the pleasure of diving into application and API protection, which I can’t (actually, I’m not certain if I can or can’t, so won’t) say too much about at this time, but which are also moving forward in a similar direction, if not in a similar manner.

    And as a developer, feature flags have intrigued me since they first appeared.

    Sing the Sesame Street song with me: “One of these things is not like the others.” Feature flags are … a feature.

    When they first hit the scene, it was literally developers writing #if and #ifdef statements in their code to turn bits on and off at compile time. That reminds me of nothing so much as the Seinfeld episode where they’re explaining to network execs what the show is about. “A developer does his job … that’s a product!”

    The market has come a long way since then. But, honestly, I just don’t see these as stand-alone products. Take a look at the breadth of things most products are doing these days—CI/CD tools, either of the two markets I just mentioned or just about any other market in a similar space. Feature flags are still just about “turn this functionality off, turn it back on”. Newer iterations allow this without rebuilding the entire app. But it’s just not up there with the potpourri that current tools markets offer.

    My take is that these tools will end up as part of a larger toolset. Microsoft, Atlassian and Cloudbees (to name the ones I’ve seen without looking too hard) already implement feature flags, shrinking the available market. And they implement them because it’s a perfect fit with several markets. DevOps tools—which is where each of these vendors implements them—are one of the best market fits.

    Which market will end up with them? I have no idea, and that’s part of the fun as an analyst. The best on-the-surface fit would be DevOps toolchain systems like Atlassian offers, where no matter your toolchain, you can use them to speed acceptance testing or save a release without re-releasing. But I can make valid arguments for other locations too, so I guess you all will decide as options come available—decide with your dollars, that is.

    Watch for it. I’m not at all saying “Avoid feature flag companies because it’s not a real product!” I’m just saying that your feature flag vendor is likely to become part of a larger solution at some point, so make sure you have a plan to move off of it in case the larger solution is something your organization just doesn’t want to deal with.

    I am saying, “If you don’t have a feature flag solution—even a homegrown one—in place, it’s time to put one in place. The ability to say “Oh, yeah, that feature is mucking things up, let’s turn it off, quick!” is huge. For larger sub-projects that take multiple sprints, the ability to have the code right in the stream with regular check-ins, but feature-flagged out of the build, is also huge. No merging or other craziness, just “BuildNewFunction=FALSE” in the source or config file. The more advanced the feature flag system in place the better—the newest ones can turn things on and off with an environment variable from a dashboard. This makes feature flag code inclusion far easier and more intuitive than, “Did we account for that database update not happening?” of hand-rolled solutions. Still not perfect—because this is a journey—but store-bought is now better than anything you’re likely to hand-roll.

    And keep rocking it. Feature flags or not, you’re making systems that power the world—or at least your corner of it—and not getting the recognition you deserve. So once again, thank you. For all those people who don’t even know that they should thank you.

  • Prevent Technical Debt by Knowing When to Remove Feature Flags

    Prevent Technical Debt by Knowing When to Remove Feature Flags

    As more organizations use feature flags and experiments, it’s critical to understand that some of these changes should exist for only a short or specific period of time, and then be removed from your codebase. Removing flags when appropriate avoids technical debt and complexity that can make your code fragile, harder to test and more difficult to support.

    The simplest ways to evaluate when a feature flag or experiment should be removed include looking at how long it’s been in the system and how many different states it’s in. If the feature flag has been in your system for a long time and all of your users have the same state of the feature flag, then it should likely be removed.

    However, evaluating based on just those two factors isn’t enough. It’s smart to also evaluate the purpose of a flag or experiment before finalizing the decision to remove it. The appropriate lifetime of a feature flag or experiment, and when it should be removed from your codebase, depends heavily on its use case. 

    When to Remove Temporary Flags and Experiments

    If a feature is designed to be rolled out to everyone and you don’t expect to experiment on the feature once it’s launched, then you’ll want to ensure you have a ticket tracking its removal as soon as the feature has been fully launched to your users. These temporary flags may last weeks, months or quarters. Examples include:

    • Painted-door experiments: These experiments are intended to be used only in the early phases of the software development lifecycle and aren’t intended to be kept in the product after they have validated or invalidated the experiment hypothesis.
    • Performance experiments: These experiments are intended to put two different implementations against each other in a live, real-world performance experiment. Once enough data has been gathered to determine the more performant solution, it’s usually best to move all traffic over to the higher-performing variation and remove the related flag.
    • Large-scale refactors: When moving between frameworks, languages or implementation details, it’s useful to deploy these rather risky changes behind a feature flag so that you have confidence they won’t negatively impact your users or business. However, once the re-factor is done, you hopefully won’t go back in the other direction.
    • Product re-brands: If your business decides to change the look and feel of your product for brand purposes, it’s useful to have a gradual rollout to gracefully move to the new branding. After the new branding is established, it’s a good idea to remove the feature flag powering the switch.

    How to Review the Lifetime of Permanent Flags and Experiments

    If a feature is designed to have different states for different customers, or if you want to control its configuration for operational processes, then it’s likely the flag will stay in your product for a longer period of time. Examples of these flags and experiments include:

    • Permission flags: These flags are useful if you have different permission levels in your product, such as “read-only” that doesn’t allow edit access to the feature. They are also useful if you have modular pricing like an inexpensive “starter plan” that doesn’t have the feature, but a more costly “enterprise plan” that does have the feature.
    • Operational flags: These flags control the operational knobs of your application. For example, these flags can control whether you batch events sent from your application to minimize the number of outbound requests. You could also use them to control the number of machines that are used for horizontally scaling your application. In addition, they can be used to disable a computational expensive, non-essential service or allow for a graceful switchover from one third-party service to another in an outage.
    • Configuration-based software:  For any software or product that is powered by a configuration file, this is a great place to seamlessly insert experimentation that has a low cost to maintain and still allows endless product experimentation. For example, some companies may have their product layout powered by a config file that describes in abstract terms whether different modules are included and how they are positioned on the screen. With this architectural setup, even if you aren’t running an experiment right now, you can still enable future product experimentation.

    Note that even if a flag is meant to be permanent, it’s still critical to regularly review these flags in case they become obsolete or should be deprecated, which would then add technical debt to your codebase.

    Establishing a Feature Management Process 

    Creating an always-on feature management process goes hand-in-hand with using feature flags and experimentation effectively. Some organizations use a combination of a task tracking system and their feature flag and experiment platform to manage this cleanup process seamlessly and quickly. If the state of feature flags and experiments can be synced with a ticket-tracking tool, then an engineering manager can run queries for all feature flags and experiments whose state has not been changed in the past 30 days, and track down owners of the feature flags and experiments to evaluate their review. Other teams schedule recurring feature flag and experiment removal days to ensure engineers review the oldest items on a regular basis to minimize technical debt.

    The benefits of feature flags and experimentation to help teams ship code and launch new features quickly and safely far outweigh the needed management to minimize codebase technical debt and complexity. When managed as a recurring process, looking at all key factors (lifetime, state and use case), teams can feel confident that their systems will remain efficient and reliable.

    — Asa Schachar