One step that, in hindsight, was natural and is highly likely to continue, is basing GitOps on a continuous delivery (CD) tool or a deployment automation tool. This allows the GitOps tool to be more tightly aligned with the actual rollout process and placed at the end of the DevOps toolchain.

Likewise, aligning with “worker” tools allows GitOps to focus on the coordination of a rollout rather than the work of the rollout, as underlying workers like FluxCD and ArgoCD handle a lot of the deployment and configuration and can be told what to do for things they don’t specifically know.

Security and Compliance in GitOps

The fact that GitOps handles all of the final steps to deployment, and even deployment to production, means that the tool will hold an increasingly critical place in the DevOps hierarchy. The best place for security policy enforcement is in the tool that will set up the final, complete solution. It’s also the best place to focus on compliance. Where better to build a software bill of materials (SBOM) than at the tag end, when you know what the software, support applications, environment, and even the OS are loading up?

We expect vendors to continue folding in security, and we expect that the tooling will do a better and better job of it. At the same time, we see this space increasingly involved in active—or runtime—security. GitOps can already watch for changes to config as they’re pushed, but we see vendors moving toward monitoring the running application to detect change, and running the processes to keep them in line with the system of record, eliminating drift caused by things like installations on the running system.

The Future of GitOps

This space will likely end up as a feature set in other products—not because it isn’t important enough to remain a separate space, but because the trend of bundling with CD tools or configuration management tools is already pretty set, and we expect similar consolidations to continue. This will keep the solution set stable, but we hope won’t completely lock in the feature set to a single CD tool.

Customers will rightly be concerned by the failures and ownership changes that this space has recently seen. However, we consider the risk to be minimal at this point. There are a lot of reasons that we don’t think customers should worry too much—primarily because, at this point, bundling with other tools is the norm for remaining products, and that will buffer revenue concerns while GitOps is taken up.

GitOps Methodology: Beyond the Technology

GitOps, like DevOps, is as much a methodology as technology. You absolutely need the tools to enable it, but without a culture that promotes end-to-end deployment automation, the best infrastructure as code (IaC) and GitOps tools won’t solve the problems.

This is why we recommend that prospective customers study the GitOps process separately from studying tools before making a large commitment. Understanding how and when all of the moving parts, like network configuration and app testing, fit into the overall GitOps architecture will help a lot when choosing a product that suits your organization’s needs, and training is available from a variety of places.

Is DIY GitOps Worth It?

Some organizations may want to use GitOps but do not wish to bring on another vendor. Like so many parts of IT, GitOps can be done in-house, it will just take more work—both up front and in long-term maintenance. GitOps tools are enablers and standardizers, so both the enablement and standardizations will have to be implemented and maintained independently if an organization wishes to run homebrew GitOps.

A large number of companies have tacked GitOps methodologies onto DevOps practices as changes in the GitOps space—like pull-based approaches, for example—force them to consider if they want this newer technology and how to get it implemented. While pull-based tools exist, a full GitOps solution would be less complex than integrating a separate tool into an internally developed GitOps toolchain. For this specific example, some organizations will be well positioned—via Argo, for example—but there is an array of improvements in the space that create similar issues for homebrew solutions.

The Final Case for GitOps

Simply put: the benefits of GitOps far outweigh the risks and implementation costs. The ability to easily check in a code or configuration, build all that needs building, apply policies (both corporate and security), build a deployment environment and deploy the application into it, kick off dynamic testing if required, and even promote to production if a specified set of conditions are met is powerful. GitOps solutions offer stable releases by ensuring each release meets standards defined both in the GitOps tooling and in tools like security scanners that are integrated into the GitOps process.

IT is a complex environment, and exceptions do and will exist, but as a rule, GitOps has grown to the point that it can handle more than 90% of IT needs and even more in a cloud-first environment.

Next Steps

To learn more, take a look at GigaOm’s GitOps Key Criteria and Radar reports. These reports provide a comprehensive overview of the market, outline the criteria you’ll want to consider in a purchase decision, and evaluate how a number of vendors perform against those decision criteria.

• GigaOm Key Criteria for Evaluating GitOps Solutions
• GigaOm Radar for GitOps

If you’re not yet a GigaOm subscriber, you can access the research using a free trial.

The post From Here to GitOps and Back Again appeared first on Gigaom.

The post Dr. Shane C. Archiquette appeared first on Gigaom.

Recent changes in the capabilities of automated testing platforms help to ease this burden. A quality automated testing platform, like Perforce’s BlazeMeter, speeds up software delivery by empowering DevOps teams to conduct extensive performance tests on mobile apps, websites, or APIs at a massive scale, leveraging powerful tools for flexibility and efficiency. BlazeMeter stands out with its blend of open-source agility and robust, scalable testing capabilities, catering to a broad spectrum of developers, including top global brands​​.

Effective automated testing tools will support a broad range of environments (web, desktop, mobile), multiple region support, and accessibility testing. They will also support an extensive catalog of test data (including platforms that offer AI-driven test data) that can closely approximate your app requirements and use cases. In addition these tools should offer services to complement your needs for testing, as they vary from application to application and company to company. A one-size-fits-all approach is not a good idea.

The post CxO Decision Brief: Mastering Continuous Testing with Automation appeared first on Gigaom.

In the GitOps model, application code and declarative infrastructure artifacts are stored, managed, and applied to target environments using a common set of tools, workflows, and automations. Storing everything in codified form in common repositories and using automated delivery tools make an organization’s source code management system a reliable control plane for the desired application and infrastructure state. Simple code management commands, such as merge or tag, are translated through automation into corresponding actions against target environments.

Depending on their starting point, organizations seeking to adopt GitOps may follow different paths. A source code management system—most commonly Git—is the basic technical prerequisite. Although frequently associated with cloud-native infrastructure generally and Kubernetes specifically, GitOps is equally applicable to virtualized infrastructure as a service (IaaS) and hybrid environments. Beyond these scenarios, GitOps capabilities can be found as integrations with some continuous integration and continuous delivery/deployment (CI/CD) suites and container platforms. General-purpose infrastructure as code (IaC) automation tools are also useful building blocks for implementing GitOps. Increasingly, container repositories and cloud vendor marketplaces are core to GitOps, providing the base images that applications are built on.

Organizations already using some of these tools will find the effort to adopt GitOps to be more procedural or cultural than technical, and focused solutions are likely to meet their needs better than platform offerings can. Organizations with none of these tools can expect a non-trivial effort in technical, procedural, and cultural dimensions of adoption. These organizations may find that offerings with a broader scope than GitOps can give them the technical capability to help evolve their practices on several fronts simultaneously.

Business Imperative
The GitOps model makes the collaborative benefits of using code management tools, such as working together via pull or merge requests, available for infrastructure artifacts. In alignment with DevOps, this approach helps to bring the often disconnected domains of development and operations closer, improving overall efficiency, visibility, and reliability. Traceability is also improved, and changes to environments are easily audited and followed, from the originating code change, to the approved code, to deployed objects in the target environment.

Moreover, GitOps can reduce security risks by restricting the way changes may be applied to deployment environments and who may make them, while at the same time reducing cycle times through automation.

Sector Adoption Score
To help executives and decision-makers assess the potential impact and value of a GitOps solution deployment to the business, this GigaOm Key Criteria report provides a structured assessment of the sector across five factors: benefit, maturity, urgency, impact, and effort. By scoring each factor based on how strongly it compels or deters adoption of a GitOps solution, we provide an overall Sector Adoption Score (Figure 1) of 3.8 out of 5, with 5 indicating the strongest possible recommendation to adopt. This indicates that a GitOps solution is a credible candidate for deployment and worthy of thoughtful consideration.

The factors contributing to the Sector Adoption Score for GitOps are explained in more detail in the Sector Brief section that follows.