Harness today revealed it has acquired Split Software as part of an effort to extend the features management capabilities of its DevOps portfolio.
As with all Harness add-on tools, the features management platform developed by Split Software will continue to be made available across multiple continuous integration/continuous delivery (CI/CD) platforms even after Harness has completed its integration.
Harish Doddala, senior vice president and general manager for Harness, said Split Software adds an experimentation capability that goes beyond the existing features management capabilities that are currently provided to enable DevOps teams to better manage multiple software development projects.
Split Software president Trevor Stuart said those experimentation capabilities were created to make it simpler for organizations to progressively provide a range of capabilities to different types of end users after an application has already been deployed in a production environment.
That capability will become more crucial as organizations embed multiple artificial intelligence (AI) models to address different use cases, noted Stuart.
Features management is already widely employed in A/B testing but the number of organizations using feature management to provide varying levels of application experiences in production environments is comparatively rare.
However, with the rise of digital business the number of organizations that provide additional capabilities at a higher cost within an application has steadily risen.
Rather than having to engage multiple vendors to provide that capability, Harness is now moving to invoke features management as code alongside all the other services built into its CI/CD platform, including AI models it is providing to accelerate the building and deployment of application at higher levels of scale.
Application development teams have, of course, 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, in effect, 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 being used in the development of applications, 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 a particular application service.
Achieving that goal naturally requires DevOps teams to work closely with product managers to determine what capabilities will be made available to align with the business model adopted. The challenge, as always, is making sure those services provide a superior user experience without creating a set of dependencies that can’t easily be managed in isolation from the rest of the application.