Category: Software Delivery Automation

  • Free Tiers and Open Source LLMs – Mana for Developers, Platform Engineers and QA

    Free Tiers and Open Source LLMs – Mana for Developers, Platform Engineers and QA

    Development rarely follows one straight path. You sketch ideas, prototype, test, swap tools, iterate, and repeat. The increasing availability of free, limited-use AI tiers and locally run open-source AI LLMs is accelerating that loop. These tiers are not marketing fluff. They are practical on-ramps for developers and engineers. They offer the freedom to test, compare, and refine without upfront cost.

    Free Tiers For The Taking

    GitHub provides a free Copilot tier: up to 2,000 code completions per month, plus 50 premium requests (chat / “agent mode”) interactions. Available in VS Code, Visual Studio, JetBrains IDEs, and more. It includes access to Claude 3.5 Sonnet and GPT-4o models. (https://github.com/features/copilot/plans, https://docs.github.com/copilot/concepts/copilot-billing/about-individual-copilot-plans-and-benefits)

    Anthropic’s Claude is free to use on the web, iOS, Android, and desktop with usage limits. Its API is not free. (https://www.anthropic.com/pricing, https://docs.anthropic.com)

    OpenAI’s GPT-5 is available to free ChatGPT users with strict usage caps. Its API requires prepaid credits, minimum $5. (https://www.wired.com/story/openais-gpt-5-is-here, https://help.openai.com/en/articles/8264644-how-can-i-set-up-prepaid-billing)

    New AWS accounts get up to $200 in credits valid for six months. Generative AI services like Bedrock move to pay-as-you-go after that. (https://aws.amazon.com/about-aws/whats-new/2025/07/aws-free-tier-credits-month-free-plan)

    Google Cloud AI Studio and Firebase are free to access. The Gemini API has a free tier with lower rate limits; paid tiers offer higher capacity. (https://ai.google.dev/gemini-api/docs/pricing)

    Cursor offers a free plan with usage limits. Windsurf provides monthly prompt credits across free and paid plans. (https://cursor.com/pricing, https://docs.windsurf.com/windsurf/accounts/usage)

    Why This Matters to Developers

    Flexible Model Switching: You can test multiple models (GPT-4o, Claude) without changing workflow or integration. That removes friction from choosing the best fit for your task.

    Rapid Prototyping: No billing setup. You can try ideas, logic paths, and prompt styles immediately.

    Cost-Effective Scaling: Validate with free tiers. When it works, choose paid tiers intentionally, not by guesswork.

    Hybrid Model Approaches: Use GPT-5 or o1 for reasoning tasks, then cheaper models like Llama for bulk processing. Free access to each lets you refine that pipeline.

    AI in Your DevOps Pipeline

    Free models pair neatly with toolchains:

    • GitHub Actions could use a free model to auto-generate release notes, analyze test failures, or lint code.

    • Microsoft Azure DevOps can use GitHub Copilot Chat and Azure OpenAI Service to assist in pipeline creation, YAML authoring, and automated documentation generation.

    • Google Cloud Build can use Gemini to generate deployment docs or config templates.

    • AWS CodePipeline could incorporate Bedrock calls for compliance checks or IaC validation.

    • CLI tools across platforms can invoke these models for tasks like refactoring YAML, generating manifests, or annotating dashboards.

    These are just a few examples of how these tools can be used with AI models. Running these in staging pipelines gives you low-risk experimentation before you roll out to production.

    Go Local

    Open-source and locally run LLMs such as OpenAI’s GPT-OSS, Meta’s Llama 3, and Mistral’s Mixtral are giving developers new options for building AI-driven applications without relying entirely on cloud APIs. These models can be downloaded, hosted on personal hardware, or deployed within private infrastructure, allowing full control over data, latency, and customization.

    Running models locally means teams can experiment with fine-tuning for domain-specific tasks, integrate AI into environments with limited internet connectivity, and meet strict compliance or privacy requirements.

    While local models may not match the scale or capability of their largest cloud-based counterparts, they offer a powerful balance of cost efficiency, adaptability, and independence that can be especially valuable for development, testing, and edge computing scenarios.

    Who Else Should Care

    It’s not just about developers: Test Engineers can generate synthetic test data, edge-case inputs, and test scripts. DevOps Engineers can automate pipeline scaffolding, log review, and incident summaries. Platform Engineers can prototype developer automation, self-service templates, and internal documentation.

    Getting early hands-on experience helps you understand where AI adds value and where it doesn’t.

    If you code, automate, build pipelines, test, or run platforms, start exploring these free AI tiers today. Plug models into your editor, Actions workflows, test frameworks, and CLI tools. Use them on real tasks, not just sample prompts. Track what works, what stumbles.

    Experimentation costs almost nothing. Delay could cost your team time and innovation.

    Recent articles by Mitch Ashley:
    Kubernetes, AI, APIs, and YAML – A Future 2.0?
    We’re Not Being Replaced. We’re Inventing What Comes Next, Including Ourselves
    AI and You: Don’t Wait… Or Be Weight

     

    Mitch Ashley is VP and Practice Lead of Software Lifecycle Engineering at The Futurum Group. The voice of “AI across the SDLC”, Mitch is a serial-CTO, speaker, advisor, entrepreneur, and product creator. He leads analyst coverage of the Software Development Cycle (SDLC), with emphasis on AI-native and agent development, cloud-native, DevOps, platform engineering, and software security.

    See Mitch’s analyst research on the Futurum website.

    Subscribers can access Mitch’s Software Engineering Lifecycle practice, decision-maker data, insight reports, and advisories through the Futurum Intelligence Platform.

  • Application Modernization: A Catalyst for Fixing Sub-Optimal UX

    Application Modernization: A Catalyst for Fixing Sub-Optimal UX

    Today, some of the biggest government programs in existence are Medicare and Medicaid with the two health care insurance providers serving over 43% of the U.S. population. The Centers for Medicare and Medicaid (CMS) spent $1.6 trillion in 2021 and continue to grow in both size and cost on an annual basis. With this type of investment and permeation into the American populace, one would assume that this program would be running on the most up-to-date applications available. However, both public and private health care insurance carriers continue to operate on legacy systems.

    Recently, Andrea Fletcher, the digital services director of the CMS, described their system as operating on technology from the 1960s, which is alarming considering the responsibilities of the program. In fact, the Biden administration has only recently announced plans to modernize their organ matching system. This announcement came from a study conducted in February, which showed that only 26% of organs were procured from donors on average. This is just one example of how efforts to improve legacy systems, which are currently being used by over 40% of the population, allow both public and private organizations to operate in a more efficient manner as well as satisfy user needs. Further exploration will show how modernization improves other areas of business, such as creating user experiences that are both easier to navigate and more personalized as well as the ability to incorporate the latest cybersecurity updates.

    Modernizing as a Means to Improve User Accessibility and Personalization

    Given the size and diversity of the United States population, a modern flexible system is necessary for creating a smooth user experience for every individual. Today, users connect with insurance carriers using a variety of different devices while communicating using different languages and possessing different levels of technical expertise. The ability to create a personalized user experience for each individual will require a level of modernization that legacy systems were not built for. The importance of this flexibility is accentuated when considering that the purpose of Medicare and Medicaid, in particular, is to serve the elderly and underprivileged.

    Prioritizing the modernization of the consumer experience is not limited to just government organizations. In an independent survey conducted by Evolveware, 46% of private organizations measure the success of their application modernization efforts through an expected improvement in customer experience. As health care insurers continue to rely more heavily on analytics and the population continues to adopt digital technologies, the process of creating a streamlined and targeted approach to purchasing and managing health care becomes essential to staying competitive. For a multitude of companies in the marketplace, having an agile system that can be customized to each individual user can be a major differentiator, especially given the variety of factors that each individual has when it comes to making decisions about their health. Moreover, by prioritizing the user experience, organizations can improve their brand loyalty and customer retention, which are key factors when dealing with a competitive marketplace with a lot of players. Insurers have recognized this, as a recent survey of CIOs by Gartner showed that improving the customer experience and application modernization were listed as the highest priorities in the insurance industry. As customers become more judicious with their money due to current macroeconomic trends, providers will need to make sure their platforms’ user experiences are on par with their competitors.

    Modernization to Mitigate the Impact of Hidden Costs and Security Vulnerabilities

    The costs of not updating legacy systems should also be taken into consideration when making the decision to modernize. While the expense and process of moving away from legacy systems can seem like a significant obstacle, these systems, due to on-site maintenance and operational costs, are already expensive to maintain on a continuous basis. In fact, health care IT teams spend around 60% of their time trying to maintain and manage legacy systems. Furthermore, the opportunity cost of IT teams focusing on maintenance over innovation is significant, especially given the potential of the latest technologies to deliver a more intuitive user experience. There is also an understated but pressing labor cost with legacy systems, as members of the workforce who are familiar with these systems are aging and retiring, and the replacement workforce is not well-versed in legacy languages and technologies.

    Finally, legacy systems can also contain blind spots that are prime targets for cybersecurity breaches and hacks today. Legacy applications were built at a time when these types of attacks were not common and, therefore, don’t have the most up-to-date security capabilities embedded. Many of these systems also do not have up-to-date documentation, resulting in a high potential for hidden vulnerabilities. For health care organizations that have access to sensitive data, understanding and then shoring up these vulnerabilities using modern security features is critical.

    Health Care Modernization Example: Chatbots

    One prominent example of how application modernization can lead to organizational success is the integration of chatbots. As technology expands and businesses identify new ways to reach consumers, the addition of chatbots has become more prominent on platforms across industries. For the health care insurance industry, the bots provide both a cost-efficient way to process insurance claims as well as an enhanced user experience through ease of use. Recent estimations show that bots can handle the workload of two to five claims processors and can deliver 20 times the production relative to cost, allowing industry employees to focus on less tedious and more innovative tasks. Using generative AI models, chatbots will continue to become more sophisticated and varied in their responses to user input. As a result, modernizing legacy systems to optimize the integration of these bots becomes integral to remaining competitive in the marketplace.

    Legacy Systems and the Future

    As we look to the future, both government and private insurance carriers have plenty of internal and external factors that incentivize application modernization. As Medicare and Medicaid continue to grow due to the increasing number of eligible users, an agile system is integral for user accessibility. Meanwhile, macroeconomic factors such as high costs and an increasingly competitive marketplace will force private organizations to adopt systems that can integrate and adapt to the newest technologies for a better and more secure customer experience. With serious challenges facing both the public and private sectors of healthcare insurance, the necessity to modernize has never been greater.

  • Business Leaders Will Trade Speed for Security

    Business Leaders Will Trade Speed for Security

    A global survey of 600 C-level executives conducted by CloudBees found that when it comes to building software, more than three-quarters of respondents said it is more important to be secure and compliant than fast and compliant.

    As a result, more than three-quarters (77%) also noted their organization is implementing a shift left strategy for implementing security and compliance even though 58% recognized that those efforts created additional burdens for developers.

    Three-quarters of respondents also conceded that compliance (76%) and security (75%) challenges limited their company’s ability to innovate. Nevertheless, 83% said shift left is important for them as an organization despite the fact that 88% of executives said their software supply chain is secure or very secure. However, only 33% of respondents said their software supply chain is completely compliant.

    Not surprisingly, 86% are focusing on compliance more now than they were two years ago and, in the wake of a series of high-profile breaches of software supply chains, 82% are more concerned about attacks.

    CloudBees CEO Anuj Kapur said it’s clear there is a greater need to reduce security and compliance burdens for developers by putting guardrails in place that automate DevSecOps processes. The survey noted that only 22% of executives believed their software delivery supply chain is completely automated, while another 37% said it is close to being automated. Only 22% said their compliance process is completely automated, with 35% believing it is almost completely automated.

    Three in five (59%) executives said they have all, or mostly all, external tools for security and compliance issues and 29% said they have a mix of internal and external tools. Only 11% use mostly internal tools. A full 90% said their risk management team has the tools, knowledge and expertise to build and/or maintain a secure software supply chain.

    The real challenge, of course, is that while compliance issues are relatively static, new security issues arise all the time. Developers make mistakes or a new zero-day vulnerability is discovered after an application has been deployed in a production environment. It’s critical for organizations to embrace automation to enable developers to address those issues as part of a continuously automated update cycle, noted Kapur.

    As more responsibility for compliance and security is shifted left, the degree to which DevOps workflows will need to be adjusted will naturally vary by organization. However, the days when developers could ignore security issues during the application development process are all but over. The leadership of organizations of all sizes are making it clear they want to see a reduction in the number of security and compliance issues that arise in production environments.

    Ideally, efforts to build more secure and compliant applications would not slow down the rate at which applications are being built and deployed. However, the CloudBees survey made it clear that more executives are willing to prioritize security and compliance over speed of application development. The issue is how to strike a balance between what are clearly two competing priorities.

  • CloudBees Acquires ReleaseIQ to Advance DevOps Orchestration

    CloudBees Acquires ReleaseIQ to Advance DevOps Orchestration

    CloudBees announced today it has acquired ReleaseIQ, a provider of an orchestration platform for automating software delivery via a software-as-a-service (SaaS) platform.

    Sacha Labourey, chief strategy officer for CloudBees, said the addition of ReleaseIQ to the CloudBees platform will provide more visibility into and control over software delivery on an end-to-end basis.

    CloudBees already provides a Flow orchestration engine within its continuous delivery platform. However, ReleaseIQ provides a similar capability across multiple continuous integration/continuous delivery (CI/CD) platforms using a SaaS platform that is more accessible.

    The ReleaseIQ platform is designed to enable DevOps teams to both create and maintain pipelines using a no-code tool. That enables greater transparency into workflows via dashboards that also provide optimization recommendations. That capability makes it much simpler to troubleshoot software deployments.

    Labourey said that while ReleaseIQ can be integrated with multiple platforms including CloudBees CI, Jenkins, CircleCI, GitLab, Bamboo, ArgoCD and others, the primary focus will remain on the open source Jenkins platform that still owns the lion’s share of the DevOps market. The overall CloudBees goal remains to employ automation and remove as much friction as possible from DevOps workflows as part of an ongoing effort to improve developer productivity, he noted. CloudBees, however, regardless of the level of DevOps maturity within any organization, is committed to meeting customers where they are versus requiring them to rip and replace existing investments, Labourey added.

    The overall level of DevOps maturity may vary widely both within and between organizations. However, as more organizations realize the extent to which they depend on software to drive digital business transformation processes, the need to further automate application development and delivery becomes more apparent. While CI is widely used today, the number of organizations that have consistently implemented CD is fairly limited. The underlying infrastructure that software is deployed on typically has a unique set of application programming interfaces (APIs) that each CD platform needs to support. Platforms such as ReleaseIQ provide a higher level of abstraction through which managing the pipelines that deliver software becomes simpler.

    In general, most organizations are trying to strike some level of balance between centralizing the management of DevOps workflows and enabling development tools to adopt whatever tools they prefer. It’s not uncommon for application development teams to independently adopt any number of tools that ultimately need to be integrated with a DevOps toolchain. Each of those tools, however, contains metadata that needs to be shared with a centralized orchestration engine that automates a range of tasks across multiple pipelines based on the metadata collected from each tool.

    There are, of course, still a lot of manual DevOps processes that should be automated. CloudBees is positioning ReleaseIQ as the orchestration engine for both unifying the management of pipelines and, ultimately. enabling value stream management across increasingly complex application development environments. It may take a while to fully realize that ambition, but with the acquisition of ReleaseIQ, a new foundation is being laid.

  • The Power of Automation and Distributed Sources of Truth

    The Power of Automation and Distributed Sources of Truth

    Enterprise networks are vast, intricate systems with multiple methods for storing configuration and state information. The configurations of those networks are also constantly changing as new applications, services or other updates are added. When you consider the complexity and dynamic nature of an enterprise network, it may be alarming to learn how much data–including most network configurations–is still updated manually, often in the middle of the night. To make that process even less efficient, the people doing the updating are required to manually log those updates on spreadsheets or into a custom-built database.

    Relying on manual processes to maintain and manage the state of an enterprise network not only leaves the door open for errors but can also lead to the network spreadsheets or databases being out of sync with the actual current state of the network. Is the network correct? Or is the spreadsheet correct? Should we make the network look like the spreadsheet? Or should we update the spreadsheet to reflect the network? What is the actual source of truth?

    The good news is that the reality of modern networking has changed the paradigm. As programmable networks are deployed more broadly, manual CLI interfaces are no longer necessary. Reading and writing network configuration and reading network state can be accomplished quickly and easily with machines and automation.

    The Source of Truth

    More enterprises are embracing network automation because they recognize the efficiencies it can deliver when managing complex networks and the benefits those efficiencies can add to the bottom line. But if you’re going to automate your infrastructure, your automation solution will need to gather authoritative information about it from somewhere. This source of truth holds the knowledge needed to enable automation to make changes to the network.

    Many enterprise networking teams feel they need to rely on a single source of truth to know the true state of the network. They believe that building a single system/server/database that can synchronize with the configuration and state information of all devices across the whole network is a viable solution. But such a solution doesn’t currently exist. Given the multifarious nature of today’s networks, relying on a single source is both impractical and potentially expensive.

    Rather than asking “What is the single source of truth?” perhaps the better question is “What will provide better data: Creating a single source of truth that tries to synchronize to the entire network? Or accessing distributed sources of truth needed to accomplish the automation in real-time?”

    Instead of relying on a single source of truth, enterprises should focus on accessing multiple sources of truth to conduct proper and meaningful automation.

    Cast a Wider Net

    If you’re running a service provider network, for instance, your business is your network. If you’ve spent millions, or even a billion dollars on your network assets, it’s worth your time to have a system in place that accurately manages and maintains those assets. A single source of truth won’t provide that.

    Also, as the network scales in size and complexity, the time it takes to synchronize a source of truth to the network also grows, limiting how often you can synchronize and leading to a greater time delta between synchronization states.

    Finally, the process of trying to create a single source also doesn’t address the real issue, which is that enterprises are still relying on manual processes that will almost always result in the source of truth databases and the actual network status being out of sync at some point. And that can have serious negative effects on a business as well.

    The case for accessing multiple sources of truth is a relatively simple one: it allows for greater flexibility and enables enterprises to more easily leverage data to benefit their business.

    With the advent of programmable networks–machines talking to machines–the most current automation solutions can access multiple distributed sources of truth–different APIs and databases that are responsible for being the source of truth for different parts of the network – and federate and sync data from these systems in real-time, providing a truer window into the status of the network and more accurate, actionable data that delivers business value back to the enterprise.

    Automation Hesitation

    So why are some enterprises still hesitant to commit to a full network automation project? There are various reasons for this, but clearly, there’s concern that not having a single source of truth for network data – or data that may not be 100% accurate – will compromise the automation process. It’s a classic “fear, uncertainty and doubt” thought process: “What if the data is only 70% accurate? If we try to automate with bad data, we’re going to break the network 30%  of the time.”

    Some network teams may believe they can’t automate anything until they can combine their five or six sources of truth into one huge database. At the same time, leadership may be pushing those network teams to move forward with automation to get more value from the network. By choosing to wait until they finally have a “pristine” database, they could lose months or even years of time, to the benefit of no one.

    The solution is to take an incremental approach. Look at all the various network assets–programmable, cloud, legacy, etc.–and start the automation process in the areas where good data exists and where a source of truth doesn’t need to be built. In parallel, you can be cleaning up the other data and add automation when that data is ready.

    Being able to utilize multiple sources of truth is better than worrying about having a “perfect” source of truth and holding back on an automation initiative. In the long run, it will be beneficial to both the network team and the business.

    Just as important as committing to an automation solution that can integrate with multiple sources of truth to make decisions, is deploying the right automation solution. The most effective automation solution will embrace:

    ● API-first–The only way to integrate multiple sources of truth into a unified one is through an API-first approach, allowing systems to talk to each other.
    ● Data federation and transformation–Having unified sources of truth is only impactful when teams can fully integrate the data together while ensuring it speaks the same language.
    ● Unified view–An abstracted and federated view of the data, processes and logic from integrated systems enables a single pane of glass across an entire network, as well as management tools for simplifying automation across the organization.

    Multiple Sources Equal More Actionable Data

    With today’s modern, programmable networks–and the absolute necessity for enterprises to have access to accurate, real-time network data–relying on a single source of truth is based on a flawed assumption that we can always have a synchronized database, and therefore is not a viable strategy.

    By adopting network automation, organizations can adopt a distributed source of truth solution by enabling the multiple systems of record, and their collective data, to act as the source of truth, mitigating data quality issues and manual errors.

    As an enterprise implements its automation strategy, having multiple sources of truth within the network will result in more accurate, timely and actionable data for automation to succeed, which will increase efficiency and drive the business forward.

  • Fidelity drives Software Delivery Performance

    Fidelity drives Software Delivery Performance

    The following blog post is based on a presentation at CloudBees Connect. The full recorded session is available below.

    Wistia video thumbnail

    Few industries depend on software more than financial services. Jimmy McNamara, software engineering product manager at Fidelity, should know: He’s worked in the industry as a software developer and project manager for over two decades, most recently for Fidelity Investments, one of the largest investment firms in the world. Fidelity’s brokerage business alone manages multiple trillions of dollars for clients worldwide.

    With so much value at stake, McNamara says that Fidelity can’t afford to let its software products lag behind the industry. It’s why the company keeps more than 10,000 developers busy building and maintaining a broad range of business and customer applications. “Fidelity is a huge believer in IT,” he says. “It’s part of our core philosophy and business strategy. It’s something that’s constantly discussed at the highest levels in the company.”

    How great software is produced at Fidelity Investments

    McNamara’s job is to help Fidelity’s developers produce great software as fast as possible, but also as safely and securely as possible. Doing so requires him to strike a balance between enforcing security through a central platform and allowing developers to use the very best tools available. “Governance and security are non-negotiable,” he says. “But at the same time, we don’t want to get in the way of our developers if they want to leverage the latest technology.”

    To gain access to best-in-class development tools, Fidelity increasingly looks to the cloud. “There’s a huge number of new features and a ton of automation that can be achieved by operating in the cloud,” he says. “It’s a game-changer in terms of the ability to improve operational outcomes, realize market opportunities and grow the business.”

    To shift the balance toward cloud over time, McNamara prefers to pull rather than push the dev teams. “We establish new capabilities and we make sure those capabilities are better than before, so our developers are naturally drawn to them,” McNamara says. Almost always, developers find the cloud environments easier to use and more conducive to innovation. “Ideally they don’t need to worry about set up,” McNamara says. “They can just focus on innovation and writing code, and it’s a better experience than before.”

    Driven by data

    To stay on track, McNamara’s team is constantly measuring how well its evolving platform is performing and delivering value to the business. “We’re very focused on data,” McNamara says. “If you follow the data, you can get to where you need to go faster.” The team tracks a range of performance metrics, such as mean-time-to-recovery (MTTR) and how quickly they are providing the features that the business requests.

    The data helps his group prioritize new platform-improvement projects and spot trends early to get a jump on emerging problems. For example, his team may decide to add automation features ahead of time to prevent an issue from impacting the business. Moreover, having access to reliable data drives more fruitful discussions with stakeholders about the value of the group’s services. “It moves the discussion beyond opinion to a more accurate, value-based discussion that really drives our services roadmap,” McNamara says.

    In the past few years, the company’s embrace of cloud-based platforms has yielded tangible improvements, such as better operational resiliency, much of it driven by the cloud’s inherent elasticity.

    What’s more, the move has given developers a richer environment in which to learn and grow. “It’s great to see a team move to cloud-based platforms,” McNamara says. “You can witness the transformation of their skill set. Their whole role in the organization changes because of the new features available in the cloud. In the end, your developers are happier because they get access to more scale, more automation, and more features. Not only that, but their skills become more marketable.” McNamara also knows that having the best tools is key to recruiting and keeping top talent.

    To ensure a successful transition, McNamara suggests hiring engineers who are naturally curious and eager to embrace new things. “The key is to bring on really inquisitive people,” he says. “It’s all about people as far as I’m concerned.”

    For those who might be reluctant to give up on their traditional on-premise environments, McNamara suggests leading by example. “If you’re a central team or service like us, you should get your stuff out first. Show it off. Demonstrate how you’ve achieved the outcomes you’ve delivered.”

  • Testing with Feature Flags to Improve Developers Productivity

    Testing with Feature Flags to Improve Developers Productivity

    Feature Flags can improve your continuous integration process in a number of ways. This post will focus on how CloudBees Feature Flags can help improve your developer productivity and shorten the feedback loop with the Flag Override view for frontend validation.  It includes Javascript in examples, but the override view can be used in all available platforms.

    The flag override view is a lightweight UI element that is very useful for debugging purposes. This override view exposes the current status for each flag set by developers and allows users to override these flags. All this is accomplished from within a handy popup in the UI of your local development instance or other instances used for quality assurance or user acceptance testing.

    For organizations, this view improves developer productivity by enabling them to rapidly validate the functionality of their newest code additions in your local environment frontend. To get started, first import the CloudBees Feature Flags SDK to your application:

    import Rox from 'rox-browser';

    Then, you will want to add the flag override view to your code. For example, this line adds the override view and controls where to display the view:

    <button className="btn btn-flags" onClick={() => Rox.showOverrides('bottom left')}>Flags View</button> 

    Check out the Browser side Javascript API for a full list of parameters.

    Once you have the override view in your local environment, you can toggle any and all frontend flags in your code to validate various code blocks and how they interact together.

    Now you can merge your work back to the master branch faster AND with more confidence!

    Shorten Feedback Loops with Feature Flags

    Quality assurance team(s) without access to the flag override view are typically stuck chasing each feature developer and waiting for them to modify code anytime QA needs to compare new and old functionality. This feedback loop could take hours if the developer is busy or days if the developer is on vacation, not to mention put a damper on developer productivity. With CloudBees Feature Flags and the flag override view, QA can shorten the feedback cycle by having complete freedom to toggle flags in their environment with the click of a button. There is no need to rope in developers to modify code, rebuild, and deploy just to update a flag. Now QA is empowered to work independently, without asking developers to break their focus or wasting precious business cycles.

    In conclusion, the flag override view is a handy screen designed for use in local and testing instances of your application frontend. The view helps developers rapidly prototype new functionality so they can get it merged to the mainline codebase faster. The view also helps QA folks work more independently of developer input and with more control of their experimentation all within a shorter feedback loop. Try the flag override view today!

    image1