DEV Community: Dragonsoft DevSecOps

Product Overview: Perforce Delphix – Test Data Management for DevOps

Dragonsoft DevSecOps — Mon, 27 Jul 2026 02:57:28 +0000

Today, while many software development teams reap the benefits of automated coding, they find themselves slowed down by traditional test data management (TDM). Manual requests, ticketing queues, stale data, and compliance gaps—these conventional TDM approaches are fundamentally at odds with modern DevOps practices, severely dragging down both developer productivity and software quality.

How can you break through the data bottleneck and accelerate software delivery? You need a modern, DevOps-ready test data management solution: Perforce Delphix.

In this article, DragonSoft—an authorized Perforce partner—explores how Delphix leverages an API-first architecture to seamlessly integrate data delivery into CI/CD pipelines. Discover how this helps your team power millions of monthly CI/CD runs and ship higher-quality software, faster.

Digital Transformation Requires a Modern Approach to TDM

Traditionally, organizations have gained economies of scale by centralizing test data management (TDM), often through the use of tools that subset, mask, and synthesize test data. However, with the adoption of DevOps, a new set of challenges has emerged. In particular, many software development teams still rely on a manual, ticket-driven request-fulfill model in which developers and testers often find their requests queuing behind others. These manual, legacy TDM approaches are completely incongruent with modern DevOps practices and CI/CD processes that depend on API-driven automation and fast feedback to development teams.

As a result, many of the DevOps benefits related to developer productivity and software quality remain constrained by slow, stale, and low quality test data. To address modern challenges, DevOps teams must expand past legacy TDM practices and automate data delivery to CI/CD pipelines via unified APIs.

Deliver Realistic, Compliant Test Data in Minutes Not Days

Delphix provides an API-first DevOps TDM solution for multi-cloud environments that combines continuous data compliance with continuous data delivery. Ephemerally delivering compliant data into unlimited parallel test environments unlocks Dev/Test/QA teams to build and run more exhaustive unit and integration tests without blocking shared data resources for adjacent teams. Administrators can also identify and protect sensitive data before provisioning to users through integrated data masking. Finally, the Delphix DevOps Data Platform provides software development and testing teams with data APIs—including the ability to refresh, rewind, bookmark, group, tag, branch, and share test data—to accelerate DevOps productivity and improve application quality.

Features

Sync with Any Test Data Source
Delphix works across all clouds and apps, synchronizing with multi-generational data sources to capture a complete record of data changes.
• Non-disruptive, continuous sync
• Connect to production data sources, backups, and staging replicas
• Efficiently store data with 100x space efficiency

Easily Manage & Distribute Data
Efficiently version and distribute datasets to non-production environments.
• Instantly deploy enterprise data with greater cost-performance & speed
• Quickly sync, version, and distribute compliant datasets
• Easily deliver versioned datasets to anywhere in the multi-cloud enterprise

Simplified Data Compliance
Automatically identify and mask sensitive data values to meet compliance for GDPR, CCPA, HIPAA, and more.
• Preserve referential integrity
• Produce realistic values for testing
• Predefined and customizable masking algorithms

Transform Environments to Test at DevOps Speed
Use APIs to refresh to the latest data, rewind for cleanup, branch datasets, bookmark, and version data alongside code.
• Integrate data delivery into CI/CD pipelines
• Clean up data following destructive testing
• Spin up/down ephemeral environments

Open and Extensible
Delphix provides APIs to manage data operations across multi-generational multi-cloud environments.
• Comprehensive set of REST APIs
• Integrate with CI/CD and monitoring tools
• Continuously sync with production data and refresh downstream

Key Benefits

Double Project Velocity
Automatically provision fresh, compliant, and complete production datasets. Run exhaustive unit and integration tests in parallel improving test speed so teams can collaborate with fast feedback.
Improve Software Quality
Masked production data maintains real data handling situations for developers to exhaustively test their code and catch potential defects before production.
Achieve Compliance
Identify and protect sensitive data in test environments to meet compliance with GDPR, CCPA, HIPAA, and other privacy laws.

How to Get Started with Perforce Delphix?

Experience how Perforce Delphix can unlock the full potential of your data. As an authorized Perforce partner, DragonSoft provides comprehensive Delphix consulting and technical support services to help enterprises accelerate data-driven DevOps transformation.

● In-Depth Scenario Consulting
Our technical experts will gain a deep understanding of your current DevOps environment and data challenges, then design a tailored solution covering the entire process—from data source synchronization and data masking strategies to CI/CD pipeline integration.

● Localized Implementation and Support
With rapid response capabilities, we support your journey from PoC validation to production deployment, ensuring seamless integration between Delphix, your multi-cloud architecture, and existing toolchains.

● Continuous Enablement and Optimization
We provide team training, best practice guidance, and long-term technical support to help your teams fully leverage data API capabilities and enable Delphix to continuously drive DevOps efficiency improvements.

Don't let slow, outdated test data continue to hold back your release cycles. Contact DragonSoft today to get your exclusive Perforce Delphix solution and product demo:

Website: www.hkdsdtech.com
Phone: 852-51679050
Email: marketing@hkdsdtech.com

DragonSoft Jira Add-on | WorkflowWise v2.12.1 Released: More Flexible Approval Strategies and Smoother Cloud Migration Paths

Dragonsoft DevSecOps — Mon, 27 Jul 2026 02:41:51 +0000

Recently, DragonSoft’s independently developed Jira core extension Add-on — WorkflowWise - Parallel Approval and Workflow Extension — has released a major update, with both the Data Center and Cloud editions upgraded simultaneously to v2.12.1.

This release focuses on two key areas: more flexible approval rule configuration and seamless enterprise migration to the cloud. Through a more intelligent workflow engine, WorkflowWise helps organizations handle complex business scenarios with greater agility while supporting their cloud transformation strategies.

Release Highlights: Two Major Feature Enhancements

1. Enhanced Approval Threshold Control (Based on User Count and Percentage)
In version 2.12.1, we redesigned the approval condition evaluation engine. Administrators can now configure approval thresholds based on both number of approvers and approval percentage when setting up approval steps. This allows approval workflows to move beyond rigid system constraints and better align with real-world business decision-making scenarios.

Through flexible rule combinations, organizations can easily implement common approval strategies, including:

· Single Rejection Rule (Veto Approval): Configure the rejection condition as “Number of Rejections ≥ 1.” Any single approver’s rejection can immediately reject the entire request, making it ideal for high-risk scenarios such as security compliance and financial approvals.

· Unanimous Approval: Set the approval condition to “Approval Percentage ≥ 100%,” requiring all approvers to approve before proceeding. This ensures critical decisions are fully aligned.

· Majority-Based Decision Making: Set the approval condition to “Approval Percentage ≥ 50%,” enabling agile collaboration scenarios such as technical review committees and product requirement reviews while balancing efficiency and consensus.

2. Seamless Migration Support from Data Center to Cloud
As Atlassian continues to accelerate its cloud-first strategy, more enterprises are planning migrations from Data Center to Cloud editions. To support this transition, WorkflowWise Data Center Edition introduces a dedicated DC-to-Cloud Migration Export Center. The system can now generate fully compatible Cloud migration configuration packages and approval history packages with one click.

Key migration improvements include:

· Intelligent Filtering to Prevent Migration Errors: The system automatically identifies and filters complex rules that cannot be seamlessly migrated to Cloud environments, such as certain script-based conditions, preventing migration failures at the source.

· Batch Export to Avoid Timeout Issues: For enterprise customers with large volumes of historical data, WorkflowWise supports exporting historical approval records in time-based batches, effectively resolving timeout challenges during large-scale data exports.

Migration Recommendation: Since cross-platform migration involves changes to underlying data structures, we strongly recommend testing migration packages in a sandbox environment before importing them into your production Cloud environment. This helps validate the compatibility of JQL queries, custom permission rules, and other configurations in advance, ensuring business continuity.

Who Should Consider This Upgrade?

● Jira Administrators Leverage the new threshold-based approval rules to easily configure approval workflows that match complex enterprise governance requirements. For organizations planning a Data Center-to-Cloud migration, the new migration export center helps reduce implementation risks and operational workload.

● Project Managers and Product Managers Dynamically adjust approval ratios based on team size and business requirements, eliminating the need for frequent workflow modifications caused by organizational changes and improving configuration flexibility.

● Enterprise Architects and Operations Leaders Use segmented historical approval data exports to support compliance archiving and governance requirements during migration projects.

● Security and Compliance Teams Implement veto approval mechanisms at critical approval checkpoints, ensuring high-risk operations receive review from designated roles before execution and better meeting compliance requirements.

How to Get and Upgrade WorkflowWise

WorkflowWise v2.12.1 is now available. Visit DragonSoft’s official Atlassian Marketplace page to access the latest version and view complete release notes and configuration guides.

→Get or Update Now:

WorkflowWise - Parallel Approval and Workflow Extension (Atlassian Marketplace)

→Professional Technical Support:

If you need assistance with configuring new approval thresholds, evaluating cloud migration strategies, or using WorkflowWise, DragonSoft’s expert team is ready to provide one-on-one consulting and implementation support.

Continue Enhancing Your Atlassian Investment with DragonSoft Add-ons
As an Atlassian Platinum Partner, DragonSoft continues to develop enterprise-grade Add-ons compatible with both Data Center and Cloud environments. We also provide customized development and Add-on development services to meet the diverse business needs of customers worldwide.

Explore DragonSoft’s popular Atlassian Add-ons:

DragonSoft | Atlassian Marketplace

The release of WorkflowWise v2.12.1 represents another important product evolution driven by customer feedback and continuous improvement. Whether you are looking to make approval decisions better aligned with business logic or planning your cloud migration journey, this update is designed to help you manage Jira workflows more efficiently and confidently.

*Contact DragonSoft today to upgrade and experience more streamlined approval management and smoother cloud migration.
*
Website: www.hkdsdtech.com

Phone: 852-51679050

Email: marketing@hkdsdtech.com

ITSM Guide | Jira Service Management Standard vs. Cloud Premium Comparison and Upgrade Guidance

Dragonsoft DevSecOps — Mon, 27 Jul 2026 02:34:48 +0000

Enterprise expectations for IT service management have long moved beyond the scope of traditional “ticketing systems.” Collaboration barriers between development, operations, and business teams, increasingly complex change management processes, and the growing frequency of security incidents are driving organizations to seek a service management platform that is more agile, intelligent, and scalable.

As a Platinum Solution Partner of Atlassian, **DragonSoft **has a deep understanding of the challenges and requirements Chinese enterprises face throughout their service management transformation journey. We have witnessed numerous customers begin their evolution with Jira Service Management Standard and gradually advance toward higher levels of service management maturity. Jira Service Management Cloud Premium represents a critical milestone in this journey. With capabilities including AIOps-powered intelligent operations, automated change management, advanced incident response, and robust asset management, Premium provides comprehensive support for building an end-to-end, high-speed service management framework.

So, what makes Premium significantly more powerful than Standard? Which advanced capabilities can truly help your teams improve efficiency and drive greater business value?

Jira Service Management Cloud Premium offers a complete, modern platform that scales.

Upgrade to Premium for a platform that empowers high velocity service management, from request intake to incident resolution, for all of your teams: DevOps, IT, HR and customer service.

Automated change management. Advanced incident resolution. Accelerated AIOps. Robust asset management. With Jira Service Management Cloud Premium, you get the tools your team needs to accelerate incident resolution and modernize service management at scale. Your organization gains:

Modernize end-to-end service management —

Deliver exceptional service experiences with advanced capabilities to streamline request intake, accelerate incident response, deploy changes faster, and more – all on a single platform.

Accelerate incident resolution with AIOps —

Enable Dev and Ops teams to intelligently detect, resolve, and prevent incidents to deliver high-performing services at scale. Reduce alert fatigue and swarm on incidents more efficiently with AI-powered alert grouping, incident creation, and PIR generation.

Securely scale service management —

Empower your admins with added controls and security safeguards. Provide teams with the keys to build and customize their own services using no-code capabilities within an IT-regulated environment.

60,000 customers trust Jira Service Management.
Leader in the 2024 Gartner Magic Quadrant™ for DevOps Platforms.
Leader in 2023 Forrester Wave for Enterprise Service Management.

Unlock high velocity service teams.

Whether you're just getting started, or looking to switch to a faster, more flexible ITSM solution, Jira Service Management has all the features your team needs to deliver great service, fast on the same platform where developers and business teams already work.

Over 55,000 customers worldwide trust Jira Service Management to help them centralize and resolve service requests, respond to incidents, streamline changes, collect and maintain knowledge, manage assets and configuration items, and more.

With intuitive workflows and the ability to work autonomously, Jira Service Management unlocks high-velocity service teams across the business, not just within IT.

Jira Service Management is built on Atlassian's unified cloud technology platform that powers open and efficient collaboration between teams, information, and workflows across your enterprise.

Atlassian's System of Work makes it easy for all teams in any organization to work together, fast. Jira Service Management is a key component. Give your teams a central view of their work and use integrations across the Atlassian portfolio and over 5,000 third party tools to make work flow.

"Jira Service Management has allowed us to centralize our information into one point, making it easy to perform queries or searches, or even simply run reports." — ANDREW TOOLAN, SOFTWARE ENGINEER, CANVA

See how Jira Service Management Cloud Premium stacks up.

Jira Service Management Cloud Premium is equipped with the advanced capabilities you need for modern IT service management. Compare with our Standard to see why it's the perfect time to upgrade.

Moving from Standard to Premium is not simply an accumulation of features—it represents a fundamental transformation in service management philosophy, evolving from reactive support to proactive prevention and intelligent enablement. Whether your team is struggling with incident response efficiency or looking to automate change management within a compliant framework, Jira Service Management Cloud Premium provides ready-to-use solutions designed to address these challenges.

Why Choose DragonSoft as Your Upgrade Partner?

● Deep Expertise in the Atlassian Ecosystem DragonSoft is an officially certified Atlassian Solution Partner with extensive experience in Jira Service Management implementation, migration, and upgrades. We have supported customers across a wide range of industries, including finance, manufacturing, internet services, and automotive.

● Localized Professional Services We provide technical consulting, solution design, and implementation support in both Chinese and English, eliminating communication barriers caused by language and time zones while ensuring seamless collaboration throughout the project.

● End-to-End Delivery Capabilities From requirements analysis and solution design to data migration, go-live training, and ongoing operations support, DragonSoft delivers full-lifecycle services through a one-stop approach, enabling your team to adopt the platform quickly and transition smoothly.

● Customized Best Practices We do more than provide licenses. By combining our expertise with your specific business scenarios, we help you maximize the value of Premium’s advanced capabilities—including AIOps, automation, and asset management—to unlock the full potential of modern service management.

Contact the** DragonSoft** team today to receive a complimentary upgrade assessment and a tailored solution plan. We will help you fully leverage the capabilities of Jira Service Management Cloud Premium and empower your business with more efficient, intelligent operations.

Website: www.hkdsdtech.com

Phone: 852-51679050

Email: marketing@hkdsdtech.com

Stop Waiting for Redeploys: How JRebel Keeps Java Developers in the Flow State

Dragonsoft DevSecOps — Mon, 29 Jun 2026 07:58:41 +0000

In the era of microservices and containerized environments, the "redeploy" cycle has become the silent killer of developer productivity. With 54% of Java developers reporting redeployment times of over five minutes, the friction is real. In this post, we explore the architectural challenges behind this trend and discuss how JVM plugins like JRebel can streamline the inner loop, allowing for instant code changes without the need for full redeployments.

Let's discuss how to reclaim your coding time.

Executive Summary

Java development environments are more complex than ever, and these complexities are creating barriers to innovation.
As your business looks to do more with less in 2025, keep these tenets in mind:

Enterprise development environments are growing more complex, leading to lower productivity for development teams.
Many Java teams are hesitant to add development staff in 2025, which makes arming these teams with the right productivity tools critical to achieving ever-expanding business requirements.

Read on for actionable insights for easing complexity and improving developer experience by incorporating the right Java tools.

The State of Enterprise Java Development

There’s a reason that Java is regarded as the stable backbone of business applications across industries. As the development language turns 30 this year, the ecosystem behind the language is as vibrant as ever. That’s a testament to the calculated evolution and continued investment that has kept Java so relevant for three decades running.

But that vibrant ecosystem comes as a double-edged sword: Enterprise Java development environments are more complex than ever.

Microservices may not be living up to their billing of efficiency. More and more developers are turning to more than one IDE as a part of their day-to-day development workflow. Cloud development environments — while popular for the flexibility they afford — are causing remote redeploy times to skyrocket.

These obstacles can put up barriers in developers’ workflows and limit a company’s ability to innovate. But with the right focus on developer productivity (and the right tools to back up that strategy), enterprise companies can carve out whitespace to innovate amid the complexity. Read on to discover how.

Understanding the Makeup of Enterprise Java Tech Stacks

To understand the development challenges faced by businesses that rely on Java, it’s important to understand the makeup of their development environments. In our recent survey of enterprise Java teams, we found ongoing shifts ranging from distribution selection, to architectural approaches, to IDEs.

Due to pricing pressure from commercial JDK distributions like Oracle Java, we’re seeing more and more enterprises every year choosing to use open source Java distributions like OpenJDK. With that shift, we’re also seeing most enterprises migrating to long-term support versions — ensuring that they have a secure and supported foundation for their applications.

At an architectural level, enterprise Java teams are continuing to lean into microservices-based architectures. Unfortunately for many teams, the move to microservices hasn’t resulted in decreased complexity or significantly faster redeploys.

As we note in a later section, microservices-based applications have a way of growing more complex over their lifespan — moving from a set of loosely-connected services to a big ball of mud. For enterprises still working with monolithic applications, that reality isn’t any better.

In 2025, we’ve noted that redeploy times for enterprise Java development environments have lengthened — showing that there will be development hurdles no matter which route you take.

Empowering development teams to overcome these hurdles — whether that’s with tools or improved processes — is critical.

Key Stats on Enterprise Java Tech Stacks

68% of enterprise Java developers say security is an important factor for upgrading JDK versions.
47% of enterprise Java developers use more than one IDE in their day-to-day workflows.
73% of enterprise Java developers are using remote, containerized, or cloud-based development environments.
54% of enterprise Java developers say that redeploys for remote development environments take 5 minutes or more.
21% of enterprises aren’t using cloud development environments, whether due to costs, regulations, security concerns, or other reasons.

Why Developer Experience Matters

Developer experience is the practice of eliminating friction in a developer’s workflow. This can take many forms, from implementing productivity teams to investigate and implement tools, to offering developers freedom to construct their individual development environments in the way they see fit.

And while developer experience may not seem like it contributes to the bottom line, happier developers write better code. More specifically, developers who can spend more time doing what they want to be doing, i.e., writing quality code, will produce better code more quickly.

Principles of crafting good developer experience can also be translated from IDEs and architecture types to developers’ toolsets.

Take AI tools, for instance. While AI may purport to do developers’ jobs for them, using such tools — especially in their infancy — can sometimes create more friction than freedom. Developers may spend more time trying to write a perfect prompt or correct an error than it would have for them to complete the task unassisted.

Improving developer experience through Java tools requires investing in the right tools that improve developer experience without adding overhead.

Now Is the Time to Invest in Java Tools

While headlines report widespread hiring freezes, 58% of enterprise Java users said their companies plan to add developer headcount in the coming year. That stat is heartening considering that economic headwinds continue to shift. But the undercurrent is concerning; 32% were unsure of hiring plans for the coming year and 9% were not planning to add headcount.

Java leaders are looking for solutions that can help fill the gap without the costs of adding an additional full-time developer. That’s where Java development tools come in. 36% of enterprise respondents said they expect to increase their Java development tool budget in 2025 and 51% are unsure. But our Java experts believe those numbers should be higher.

Why? 26% of enterprise developers say that insufficient developer tools are their biggest barrier to developer productivity. Java tools don’t replace a full-time developer, but the right tools can foster efficiency in enterprise development environments no matter how many developers are in seat — now or in the future.

Enterprises Demand Purpose-Built Development Tools

Enterprise developers and leaders value robust, enterprise-grade development tools — and the data backs that claim.When asked what AI tools they turned to, 52% selected GitHub CoPilot, whereas respondents from smaller companies favored ChatGPT*. This cohort recognizes the value of investing in robust, purpose-built development tools to improve their team’s productivity.

Many developers are finding that free tools don’t offer the support or integration they need for complex enterprise environments. Investing in purpose-built development tools yields dividends in increased productivity and reduced friction.

Recommendations for Decision Makers

Enterprise leaders play a critical role in setting their Java development teams up for success. Here are actionable recommendations to overcome complexity in your enterprise Java development environment and enhance the developer experience.

1.Invest in Developer-Centric Tools
Evaluate and adopt tools that solve specific bottlenecks, such as long redeploy times that break developer flow or fragmented environments that add hurdles. Solutions like JRebel can significantly improve developer productivity by helping developers stay focused.

2.Automate Tasks Where Possible
Automate repetitive tasks such as testing,deployment, and error detection using AI-powered tools. This allows developers to focus their time on coding.

3.Support Individuality in Developer’s Workspace
Empower your developers to choose tools and configurations that align with their individual workflows. Allowing flexibility in IDEs or plugins enhances the developer experience and improves productivity.

4.Make Developer Experience a KPI
Create cross-functional productivity teams to continually assess tools, test new possibilities, and optimize workflows based on developer feedback.

5.Track ROI for Developer Tools
Developer tools only help ease enterprise development environment complexity if developers actually use them. Teams should look for tools that offer real-time ROI reporting, or, for teams with more developer productivity groups, consider investing in a platform that consolidates productivity metrics across the breadth of your productivity toolset.

How JRebel Can Ease Java Development Environment Complexity

JRebel is a JVM plugin that enables users to visualize code changes instantly while maintaining application state.This enables Java developers to test code more frequently so your business can boost code quality and go to market faster. Developers also stay in “flow state,” i.e., they keep coding instead of checking email and grabbing coffee.

A few minutes here and there spent waiting on redeploys might not seem like a huge issue, but when extrapolated over an entire enterprise Java development team of 100+ Java developers, those minutes can quickly add up to months of development time wasted waiting.

With JRebel, your team can:

Accelerate time to market and increase code quality.
Integrate with all aspects of your Java development environment, including all popular cloud providers and IDEs.
Provide real-time reporting on ROI across your development team.

Enterprise Java development environments are complex enough; your tools shouldn’t be. Fortunately, JRebel integrates directly with all popular IDEs (including IntelliJ IDEA, VS Code, and Eclipse), and all popular cloud providers (including AWS, Microsoft Azure, and Google Cloud Platform).

Developers test code more frequently when they’re not hindered by long redeploys. With JRebel, developers aren’t tempted to batch code changes in an effort to save time. Visualizing code changes instantly with every small tweak helps developers write better code in less time.

Final Thoughts

Enterprise Java development environments are more complex than ever before, but with the help of the right Java development tools, your team can still innovate. By leveraging modern Java development tools and prioritizing the developer experience, enterprises can overcome the challenges of slow workflows, fragmented tools, and high turnover.

Improving developer productivity is an investment in your team’s ability to innovate and thrive in today’s complex enterprise Java environments.

About Perforce JRebel

Perforce JRebel is a Java developer productivity tool that allows developers to view code changes instantly and skip redeploys while maintaining application state. JRebel is trusted by leading brands worldwide to help Java developers write better code, faster.

Let’s find the perfect solution for your team — request a personalized JRebel quote today.

Make code changes instantly visible and say goodbye to redeploy wait times in Java development!

Dragonsoft is dedicated to helping enterprises eliminate friction within their development toolchains and build efficient, modern R&D systems. As an authorized Perforce Partner, we go beyond providing enterprise-grade licensing for JRebel; we offer comprehensive, end-to-end services encompassing consulting, evaluation, deployment, training, and technical support.

Whether you are looking to adopt JRebel to solve the bottleneck of long redeploy times in microservices and cloud environments, or planning to scale up your Java team's delivery speed and code quality across the enterprise, Dragonsoft delivers customized best-practice solutions tailored to your unique needs.

JetBrains Junie GA Release: Bridging IDE Toolchains with Agentic AI

Dragonsoft DevSecOps — Mon, 29 Jun 2026 07:56:43 +0000

In daily development, many AI coding assistants confidently write code in the wrong direction, forcing developers to waste significant time on subsequent reviews and troubleshooting. JetBrains' official AI coding agent, Junie, is dedicated to cracking this problem with remarkable results—it recently secured the number-one spot on the authoritative SWE-Rebench coding agent benchmark.
Junie has now officially left its Beta phase and is generally available. As a professional DevSecOps solution provider and an authorized JetBrains Partner, Dragonsoft provides an in-depth analysis of the heavyweight upgrades in Junie's official release:
It not only minimizes invalid executions and wasted tokens through an advanced "plan before coding" mode, but also directly drives the native IDE debugger for breakpoint troubleshooting, and performs code reviews while maintaining complete project context. Additionally, Junie supports a flexible, vendor-lock-in-free model strategy, empowering developers to utilize either frontier models or local runtimes.

Junie started as an experiment. We asked, “What if an AI coding agent didn’t just guess at the details of your project, but actually used the same tools you do?” Over the last year, that experiment turned into a product used by developers every day – inside the IDE and the terminal.

Today, the JetBrains AI coding agent is leaving Beta. This isn’t a rename or a repackage. The parts of Junie that matter most are stable, connected, and ready for real work. Junie plans before it codes, debugs with the real debugger, reviews PRs while considering your project’s context, and runs long tasks while you focus on other things.

On the latest run of SWE-Rebench – an independent agent benchmark – Junie placed as the number-one coding agent.

“SWE-Rebench draws fresh tasks each cycle to keep the evaluation honest, so results move from run to run. In this cycle Junie came out as the top model-harness, with 61.6% resolved and a 72.7% pass@5 — placing it ahead of the other agents and competitive with raw frontier models”
Alexander Golubev Research Lead at Nebius

We believe that delegating work to an agent should be something you can afford to do often, not just for heroic one-offs. Thus Junie supports any model, without lock-in – and that’s how you control cost. Use the latest models from frontier labs from day zero, or point Junie at a local runtime. It’s the lever that lets you decide what each task costs. Top-tier reasoning models are powerful but expensive; smaller models are fast and cheap. Junie lets you put each one where it does the most good. Cost efficiency stops being a property of the tool and becomes a dial you hold.

Here’s what comes with the move to general availability:

Advanced Plan mode: The agent thinks before it codes

One of the most common causes of failure in AI coding agents is unwavering confidence when they are totally incorrect – they start implementing before anyone has agreed on what they’re doing. You end up reviewing a PR that solves the wrong problem or burning tokens on a path you would have rejected in the first thirty seconds.

Plan mode fixes that by making the plan a first-class artifact.

Before Junie writes code, it produces a structured document with tabs for product requirements, technical design, delivery stages, and (when requested) testing strategy. You read the doc. You edit it directly in your editor. You approve it. And then Junie implements it.

This approach is superior to “better prompting”, for a few reasons:

The plan is a real document. It lives in .junie/plans. You can commit it, and it becomes living task documentation, not a throwaway chat message.
The agent asks the right questions. When requirements are ambiguous, Junie asks multiple-choice and freeform questions to pin things down, instead of guessing and hoping.
Junie plans before it codes – meaning fewer wasted tokens and fewer broken PRs. Every wasted implementation run is tokens you paid for and a review cycle you’ll have to do anyway. Plan on a strong model; implement on a cheap one. The agent doesn’t wander, so your bill stays low.

Enter Plan mode with Shift+Tab. Open the plan with Ctrl+P. And when you’re ready, hit Confirm to implement the changes.

Agentic debugging: Junie uses the debugger, not println

When something goes wrong, most coding agents add log statements. Junie opens the debugger.

With the GA version, Junie can drive your IDE’s debugger the way you would:

Start or join a debug session. Junie can launch a run configuration, debug a test, or take over an existing session you already have open.
Set breakpoints anywhere that matters, including project code, library code, SDK code – even decompiled .class files and sources inside JARs. If your IDE can step into it, Junie can set a breakpoint in it.
Inspect the real runtime state. Stack frames, thread state, expression evaluation, run-to-line – Junie collects actual evidence instead of theorizing about what your code might be doing.

This allows Junie to use debugging patterns that you previously had to work with manually:

“Debug and figure out why this test fails only on the second iteration.” Fully autonomous – Junie drives the whole thing.
“Prepare the debugger, I’ll trigger the UI flow.” Junie sets up breakpoints and waits for you.
“Continue my current debug session and tell me why this value becomes null.” Hand off routine inspection work while you think about the bigger picture.

Today this works end to end in JetBrains IDEs with an AI subscription.

Remote control: Start a task, and keep an eye on it from anywhere

Some work doesn’t fit in a focused 30-minute session, for example a Spring Boot upgrade, a migration to Java records, or adding test coverage to a legacy service. These are exactly the tasks autonomous agents are good at – and it’s even better when you don’t have to sit and watch.

Start a task from your laptop. Check progress from your phone during a meeting. Review the PR over coffee. Junie runs asynchronously and keeps the session available from anywhere you sign in.

Code review without lost context

Most review tools see your codebase for the first time when the PR opens. Junie reviews with the same project context it uses to write code: your build, your tests, your conventions, your past decisions.
Three entry points. Trigger a review from GitHub Actions or GitLab (including on-prem), or by using the /review command in the CLI or the plugin. Set the scope to unstaged changes, staged changes, or a diff against main – your call.
Interactive walkthrough. Junie highlights each meaningful change, explains the design decision behind it, and gives you accept/reject controls inline. Drop a PR comment on the spot when something looks wrong.
Adaptation to your focus. Ask a follow-up question and Junie reorders the remaining review around what you care about, instead of marching through files alphabetically.

Deep IDE integration: An AI coding agent that uses your IDE’s tools

Junie has always worked inside JetBrains IDEs. Earlier this year we showed you how to connect it. In Junie’s GA version, we’ve rebuilt that integration on top of ACP (the Agent Communication Protocol), the same protocol Junie CLI uses to talk to your IDE.

One engine, many surfaces. The same agent is behind the AI chat, the dedicated Junie tool window, and Junie CLI. Improvements ship once and show up everywhere.
Your IDE, the agent’s toolbox. Junie uses your IDE’s semantic index, build configurations, test runners, and debugger, not its own approximation of them.
Database integration. Junie connects to the databases configured in your IDE through DataGrip and the JetBrains Database plugin, and then it queries your real data and writes, fixes, and validates SQL in the same session that handles your code.

What this adds up to Individually, each of these features solves a specific problem. Together, they change what an agent is for.

An agent that understands your project, lets you approve the work before doing it, runs it while you’re doing something else, debugs it properly when things break, reviews your PRs with the full project context, and queries your real data – that’s an agent you can actually delegate to.

That’s the bar we set for leaving Beta.
Getting started

Junie is available in all JetBrains IDEs and through Junie CLI in your terminal. If you already have a JetBrains AI subscription, everything works out of the box.
Bring Your Own Key works too – enjoy access to Anthropic, OpenAI, Google, and others.
Junie connects to local model runtimes – point it at LiteLLM, LMStudio, Ollama and the agent runs using whatever model you have loaded on your own machine. Prompts and code never shared externally.

Install Junie, open your project, and test it out on a real task (maybe one you’ve been procrastinating on).

Then tell us what broke, what surprised you, and what you’d like to see next. Every feature above came from that feedback loop, and it doesn’t end with the move to GA.

Seamlessly integrate cutting-edge AI technology into your enterprise R&D pipeline!

Dragonsoft is dedicated to helping enterprises build secure, efficient, and modern R&D automation systems. As an authorized JetBrains Partner, we go beyond merely providing enterprise-grade licensing for JetBrains products. We offer comprehensive, end-to-end services encompassing consulting, evaluation, deployment, training, and technical support.

Whether you are looking to adopt JetBrains AI to unleash developer productivity or planning to scale standardized, automated AI coding workflows across your organization, Dragonsoft delivers customized best-practice solutions tailored to your unique needs.

Build Your Own CLI Assistant: Getting Started with GitHub Copilot Custom Agents

Dragonsoft DevSecOps — Tue, 23 Jun 2026 05:25:00 +0000

summary:GitHub Copilot CLI has introduced AI agent capabilities to the command line, but the key to truly unlocking its value lies in custom agents. By encoding your team's tech stack, standards, and toolchain into reusable Markdown configuration files, developers can transform one-off prompts into reviewable, version-controlled, and standardized workflows. As a GitHub Enterprise Partner, Dragonsoft takes you through an in-depth analysis of how custom agents work. This article will showcase complete configuration file examples for four major practical scenarios: security audits, IaC compliance, release docs generation, and incident response. Furthermore, we provide practical advice on choosing between off-the-shelf agents and custom-built agents, helping your team build automated workflows in GitHub Copilot CLI that truly fit your specific needs.

Custom agents let GitHub Copilot CLI understand your stack and team workflows, turning one-off terminal prompts into repeatable, reviewable processes.

Developers work across many surfaces like the CLI, IDE, and GitHub. The terminal is often where they turn to move fast, automate tasks, or work directly with systems and scripts.

Tools like the GitHub Copilot CLI already make this easier. You can generate commands, debug issues, and move quicker without leaving the terminal.

However, like any environment, the CLI can still accumulate friction: re-running the same commands, re-explaining context, or translating logs for your team into something they can act on. These small steps add up, especially when every team’s stack and standards are a little different.

But what if your terminal didn’t just run commands, it understood your stack, your tools, and your team’s standards?

That’s where custom agents come in. Instead of starting from scratch each time, you can encode your team’s context into reusable workflows that go beyond one-off prompts.

With custom agents in the CLI, you can turn repeated tasks and patterns into consistent, reviewable workflows that fit naturally alongside your other tools, further tailoring GitHub Copilot CLI with expertise for specific development tasks.

1.What are custom agents?

A custom agent is a Copilot agent that can be defined using a Markdown file. Instead of relying on generic behavior, you describe how the agent should operate, what tools it can use, what standards it should follow, and what outputs it should produce. The result: its behavior is consistent wherever it runs.

Each coding agent you create can act as a specialized agent tailored for a specific task. For example, a generic coding agent might suggest how to clean up your code. But a custom agent can apply your formatting rules, tooling, accessibility standards, review requirements, and safety requirements every time it runs.

Custom agents are defined using agent profiles, or files that live directly in your repository. Written in Markdown, these agent profiles let you specify:

· The agent’s role and area of expertise
· Which tools it can access
· Guardrails that keep outputs safe and consistent

The snippet below shows the beginning of an agent profile that acts as an expert assistant for web accessibility:

description: 'Expert assistant for web accessibility (WCAG 2.1/2.2), inclusive UX, and a11y testing'  
name: 'Accessibility Expert'  
model: GPT-4.1  
tools: ['changes', 'codebase', 'edit/editFiles', 'extensions', 'web/fetch', 'findTestFiles', 'githubRepo', 'new', 'openSimpleBrowser', 'problems', 'runCommands', 'runTasks', 'runTests', 'search', 'searchResults', 'terminalLastCommand', 'terminalSelection', 'testFailure', 'usages', 'vscodeAPI']
# Accessibility Expert  
You are a world-class expert in web accessibility who translates standards into practical guidance for designers, developers, and QA. You ensure products are inclusive, usable, and aligned with WCAG 2.1/2.2 across A/AA/AAA. 
# Your Expertise 
**Standards & Policy**: WCAG 2.1/2.2 conformance, A/AA/AAA mapping, privacy/security aspects, regional policies

Because the agent profile lives in your repository, your team can review it, version it, and share it so the same expectations follow the work from the CLI to the IDE and all the way into pull requests on GitHub.

2. How custom agents work in GitHub Copilot CLI

GitHub Copilot CLI is well suited for agent-driven work because it already runs scripts, calls APIs, and works directly with your repositories. Defining agents here lets you further tailor Copilot CLI by encoding execution-heavy workflows once, then invoking it from the terminal. The agent will execute your workflow the same way every time.

To add a new custom agent for GitHub Copilot CLI, you’ll need to:

1.Invoke the agent from Copilot CLI. From the terminal, run the Copilot CLI and use the /agent slash command. Select the custom agent you want to use.
2.Create an agent profile in the .github/agents directory of your target repository. The agent profile is a Markdown file with YAML frontmatter that defines the agent’s role, scope, capabilities, and guardrails, so it behaves consistently in your workflows. The agent profile file ends with .agent.md – for example, accessibility.agent.md.

Because the agent profile is a file in your repository, it can be reviewed, updated, and shared.

3. Common workflows you can automate with custom agents

The best place to start with custom agents is with tasks your team already repeats, many of which often begin in the terminal and continue in the IDE and on GitHub.

Here are a few practical scenarios:

Security audit agent
Run your team’s standard security checks across your repositories, summarize findings by severity, and output a pull request-ready checklist with owners and next steps.

# .github/agents/security-audit.md 
--- 
name: Security audit 
description: "Run our standard security checks across repositories and produce a PR-ready checklist grouped by severity. "
tools: 
# Keep this list aligned with what your team actually runs in CI. 
- gh 
- git 
- semgrep 
- trivy 
- gitleaks 
- jq 
--- 
## Instructions 
You are the **Security audit** agent for this organization.
### Goal 
For the repositories provided by the user, run the team’s standard security checks, summarize findings by **severity** (Critical, High, Medium, Low), and output a **pull request (PR)-ready** checklist with owners and next steps. 
### Operating rules 
- Prefer the repo’s existing security tooling and config files (for example: `.semgrep.yml`, `.trivyignore`, `.gitleaks.toml`) when present. 
- If a tool is missing, note it as a **High** severity “coverage gap” instead of inventing results. 
- Don’t paste secrets or full vulnerable payloads into output. Redact tokens and credentials. 
- Use inclusive language (use allowlist/denylist). 
- When referencing dates, use the format “March 23, 2026”. 
### Standard checks to run (per repository) 
1. Secret scanning locally: 
- `gitleaks detect --redact --no-git --source .` (or use the repository’s preferred invocation) 
2. Container scanning (if a container image or Dockerfile exists): 
- `trivy fs .` 
3. SAST (if semgrep config exists): 
- `semgrep scan --config .semgrep.yml` 
4. Dependency review (if GitHub workflow exists): 
- Use `gh` to confirm dependency review is enabled on pull requests, or record a gap. 
### Ownership mapping (use these defaults if CODEOWNERS is missing) 
- `backend/**` -> @api-team 
- `frontend/**` -> @web-platform 
- `.github/workflows/**` -> @platform-eng 
- `terraform/**` -> @infra-oncall 
- Otherwise -> @security-champions 
### Output format (copy/paste into a pull request description) 
Produce a single Markdown report with:
- A short **Summary** section with counts by severity 
- Sections for **Critical**, **High**, **Medium**, **Low** 
- Each finding formatted as a checklist item: 
Example item format: 
- [ ] **[H-1] <short title> (<repo>)** 
- **Repository:** `<owner/name>` 
- **Area:** `<path or component>` 
- **Owner:** `@team-or-user` 
- **What to do next:** `<1–3 concrete steps>` 
- **Command(s):** `<what you ran or what to run to verify>` 
### Final step 
At the end, add a “Next steps” section with: 
- who should open the follow-up pull requests 
- suggested sequencing (Critical within 24 hours, High within 7 days, etc.)

Infrastructure as code compliance agent
Review plans and manifests against your organization’s guardrails and policies. Highlight risky changes, and generate a concise, approval-ready summary.

# .github/agents/iac-compliance.md 
--- 
name: IaC compliance 
description: Review Terraform plans and Kubernetes manifests against our guardrails, highlight risky changes, and produce an approval-ready summary. 
tools: 
- gh 
- terraform 
- conftest 
- opa 
- kubeconform 
- jq 
--- 
## Instructions 
You are the **IaC compliance** agent for this organization.  
### Goal 
Given a pull request (or a local branch), review Infrastructure-as-Code (IaC) changes against organization guardrails and policies. Highlight risky changes and produce a concise, approval-ready summary that a human can use to approve (or request changes) quickly. 
### What to review 
- Terraform:
- `*.tf`, `*.tfvars`, `*.tf.json` 
- `terraform plan` output (when available) 
- Kubernetes: 
- `*.yml`, `*.yaml` manifests (including Helm-rendered output if provided) 
### Guardrails to enforce (examples) 
Treat the following as policy requirements unless the repository explicitly documents an exception: 
- No publicly accessible resources unless explicitly approved (internet-facing load balancers, `0.0.0.0/0` ingress, public S3 buckets) 
- No wildcard permissions in IAM policies (avoid `Action: "*"`, `Resource: "*"`) 
- Encryption required at rest for managed storage services 
- Require version pinning for Terraform providers and modules 
- Kubernetes manifests must: 
- Set resource requests and limits 
- Avoid privileged containers and `hostNetwork: true` 
- Avoid `latest` image tags 
- Use non-root users where possible  
### How to run checks (prefer what the repository already uses) 
1. **Terraform plan (if Terraform changes exist)** 
- `terraform fmt -check` 
- `terraform init -backend=false` 
- `terraform validate` 
- `terraform plan -out tfplan` 
- `terraform show -json tfplan > tfplan.json` 
2. **Policy evaluation** 
- If `policy/` exists, treat it as the source of truth for OPA policies. 
- Run: 
- `conftest test tfplan.json -p policy/` 
- `conftest test k8s-rendered.yaml -p policy/` (if manifests exist) 
3. **Manifest validation** 
- `kubeconform -strict -summary <file-or-dir>` 
### Risk scoring 
Classify each notable finding into: 
- **High risk**: likely security exposure or broad blast radius (public ingress, wildcard IAM, deletion of critical resources) 
- **Medium risk**: potential operational impact (autoscaling changes, node selectors removed, timeouts reduced) 
- **Low risk**: style, minor drift, missing metadata 
### Output format (approval-ready) 
Return a single Markdown section that a reviewer can paste into a pull request comment: 
## IaC compliance summary 
**Scope:** Terraform and Kubernetes changes in this pull request  
**Overall risk:** <Low|Medium|High> 
**Policy result:** <Pass|Fail|Pass with notes> 
### High-risk findings 
- [ ] <finding> — **Owner:** @team — **Path:** `<path>` — **What to change:** <1 sentence> 
### Medium-risk findings 
- [ ] <finding> — **Owner:** @team — **Path:** `<path>` — **What to change:** <1 sentence> 
### Low-risk findings 
- [ ] <finding> — **Owner:** @team — **Path:** `<path>` — **What to change:** <1 sentence> 
### Evidence (commands run) 
- `terraform plan ...` 
- `conftest test ...` 
- `kubeconform ...` 
### Recommendation 
<Approve / Request changes / Block, with 1–3 bullets explaining why> 
### Notes 
- Be explicit about what changed and why it matters (developer-to-developer tone). 
- If you can’t run a check (missing tooling, no plan output, etc.), call it out under **Evidence** as a gap. 
- Don’t include secrets or full credentials in the output; redact them.

Release docs agent
Gather merged pull requests since the previous release, categorize them, and draft release notes in your team’s style. Update the repo’s CHANGELOG.md and include a short release checklist that includes tests, migrations, and rollout/rollback notes.

# .github/agents/release-docs.md 
--- 
name: Release docs 
description: Draft release notes from merged PRs since the previous release, update CHANGELOG.md, and output a short release checklist (tests, migrations, rollout/rollback). 
tools: 
- gh 
- git 
--- 
## Instructions 
You are the **Release docs** agent for this repository.
### Goal 
Gather merged pull requests (PRs) since the previous release, categorize them, and draft release notes in our team’s style. Update `CHANGELOG.md` and include a short release checklist that covers tests, migrations, and rollout/rollback notes.  
### Inputs to request if missing 
- The previous release tag (for example: `v1.12.3`) 
- The new release version (for example: `v1.13.0`) 
- The target branch (default: `main`) 
### How to gather changes 
1. Identify the compare range: 
- Prefer `git` tags. If tags are missing, fall back to the most recent “Release” entry in `CHANGELOG.md`. 
2. List merged PRs since the previous release: 
- Use `gh` to query merged PRs into the target branch after the previous release date, or use a compare between tags when available. 
3. Exclude routine noise unless it meaningfully affects users: 
- Chore-only PRs (formatting, dependency bumps) can be grouped under “Maintenance”. 
### Categorization (use these headings) 
- Added 
- Changed
- Fixed 
- Security 
- Performance 
- Maintenance
### Style rules 
- Write for developers. Be direct and practical. 
- Use sentence case for headings. 
- Don’t anthropomorphize the agent. 
- Avoid “we” unless it’s necessary; prefer “you” where it’s actionable. 
- Don’t invent impact or claims. If a PR title is unclear, use the PR body or ask for clarification.
### Output requirements 
1. Produce a `CHANGELOG.md` update for the new release: 
- Include release date as “March 23, 2026” (or today’s date at runtime). 
- Include bullet points with PR numbers and short descriptions. 
2. Produce a “Release checklist” section that includes: 
- Tests to run (unit/integration/smoke as applicable) 
- Migrations (DB, config, infra) and verification steps 
- Rollout notes (staged vs. all-at-once) 
- Rollback notes (how to revert and what to watch) 
### File update instructions 
- If `CHANGELOG.md` exists, append a new section at the top. 
- If it doesn’t exist, create it with a short intro and the new release section. 
- Only modify `CHANGELOG.md` unless the user explicitly asks to edit other files. 
### Final response format 
Return: 
1. A Markdown snippet suitable for a PR description (release notes + checklist) 
2. The updated `CHANGELOG.md` content to commit

Incident response agent
Given a service name and time window, gather “first look” data such as recent deploys, error rates, top endpoints, and relevant logs. Produce an incident report using your team’s template and suggest next steps.

# .github/agents/incident-response.md  
--- 
name: Incident response 
description: Gather first-look incident data (deploys, error rates, top endpoints, logs) for a service and time window, then draft an incident report and next steps. 
tools: 
- gh 
- git 
- jq 
- curl 
--- 
## Instructions 
You are the **Incident response** agent.  
### Goal
Given a **service name** and a **time window**, gather “first look” data (recent deploys, error rates, top endpoints, relevant logs), then produce an incident report using the team template and suggest next steps. 
### Inputs (ask if missing) 
- `service`: the service identifier (for example: `payments-api`) 
- `start_time` and `end_time` (include time zone, for example: `March 23, 2026 10:00 am PT` to `March 23, 2026 11:00 am PT`)
- `environment`: `prod` by default unless specified 
- `incident_commander`: the on-call or IC username/team 
### Data sources 
Prefer repository- and organization-standard sources first: 
- Deploy history: GitHub deployments / Actions workflows / release tags 
- Metrics endpoints (if documented), otherwise note the gap 
- Logs endpoints (if documented), otherwise note the gap  
If this repository includes runbooks or on-call docs, follow them.  
### What to gather (first look) 
1. **Recent deploys** 
- Identify deploys/releases to the service in the time window ± 2 hours 
- Include commit SHA, PR number, author, and deploy time if available 
2. **Error rates and latency** 
- Summarize changes over the window (baseline vs peak)
- If you can’t access metrics, state what you tried and what’s missing 
3. **Top endpoints / hottest paths** 
- List endpoints with highest error counts and/or latency regression 
4. **Relevant logs** 
- Provide a small set of representative log lines (redacted)
- Focus on new error signatures, timeouts, dependency failures, and auth issues 
- Do not include secrets or customer PII 
### Output: incident report template
Produce a single Markdown report: 
## Incident report: <service> — <short summary> 
**Status:** <Investigating|Mitigated|Resolved>  
**Severity:** <SEV-1|SEV-2|SEV-3>  
**Environment:** <prod|staging|...>  
**Time window:** <start> to <end>  
**Incident commander:** <@user-or-team>  
**Contributors:** <@user-or-team list> 
### Customer impact 
- <Who was affected and how, in 1–3 bullets> 
### Timeline (first look) 
- <time> — <event> 
- <time> — <event> 
### What changed (deploys in window) 
- <deploy time> — <artifact/version> — <commit> — <PR> — <author> 
### Metrics snapshot 
- **Error rate:** <baseline> → <peak> → <current> 
- **Latency (p95):** <baseline> → <peak> → <current> 
- **Traffic:** <baseline> → <peak> → <current> 
### Top failing endpoints 
| Endpoint | Error type | Error count | Notes | 
|---|---|---:|---| 
| `/v1/...` | `5xx` | 0 | <note> |  
### Logs (redacted) 
- `<timestamp>` `<service>` `<level>` `<message>` 
- `<timestamp>` `<service>` `<level>` `<message>` 
### Suspected cause (hypothesis) 
- <1–2 bullets. Clearly label as hypothesis.> 
### Next steps 
**Immediate (0–30 min)** 
- [ ] <action> — **Owner:** <@team> 
**Short term (today)** 
- [ ] <action> — **Owner:** <@team> 
**Follow-up (this week)** 
- [ ] <action> — **Owner:** <@team>  
### Notes 
- Be explicit about uncertainty. If data is missing, write “Unknown (data unavailable)” and list what’s needed. 
- Use inclusive language (allowlist/denylist). 
- Use short, scannable bullets. Avoid hype and anthropomorphizing. 
- Redact secrets and personal data.

4. How to choose between off-the-shelf agents vs. your own custom agents

After working with our partners like JFrog, Dynatrace, Octopus Deploy, arm, and others, Github Copilot offer a number of off-the-shelf agents to help you get started quickly in areas like observability, infrastructure as code, and security.

These agents come with specific workflows and tool-specific knowledge baked in, making them a fast way to see immediate value without defining an agent from scratch (plus, you can always mod them to fit your exact needs). Teams often treat partner agents as a starting point to then create their own custom agent.

But you can also create your own custom agents with your own Markdown files that are more specific to your rules, tools, and conventions.

Use off-the-shelf agents when you want to:

· Try a working agent with minimal setup: No need to design prompts, outputs, or create guardrails from scratch.
· Lean on tool-specific expertise: You’re using a partner product and want an agent that already knows the commands and best practices.
· Standardize around a partner’s recommended practices: You want consistency with how a tool is intended to be used.
· Cover repeatable tasks across repos: For example, baseline security checks, common reviews, or other patterns that apply to multiple services.

Use custom agents when you want to:

· Define how your team gets work done: Your team has conventions like naming, review standards, and security checks, and you want the agent to follow them every time.
· Integrate with your exact stack and internal tooling: Useful if you rely on things like internal APIs or nonstandard tooling that a partner agent wouldn’t know about.
· Reduce glue work in your workflow: You can have an agent that runs the same sequence across incidents, releases, or audits.
· Version and evolve your workflow like code: You can improve the agent over time, review changes, and share it across your team as a maintained asset.

A good rule of thumb: Use off-the-shelf agents for speed and tool-specific best practices, and custom agents when you need precision, continuity, and control.

There’s a growing ecosystem of partner agents that your team can try immediately. Check out our Awesome Copilot list of custom agents.

5. How to get started with custom agents

First, you’ll need to install GitHub Copilot CLI.

Once you’re ready to go, start with a workflow you already repeat, then make it consistent. Choose a task that happens every week and turn it into an agent that runs the same checks, uses the same tools, and produces the same reviewable output.

If you’re new to agents, try a partner agent first to test the workflows and get a feel for the new workflow. Browse partner-built agents and try one in the CLI.

You can also create a small custom agent that you can continue to iterate on. For example:

· Take a pull request title plus labels, and generate a correctly formatted CHANGELOG.md entry.
· Turn a bug report into a structured issue comment with reproduction steps, environment information, severity, and suggested next steps.

Custom agents help standardize your workflows by taking the knowledge from scattered notes and one-use prompts and turning them into reusable, structured workflows you (and your team) can rely on.

This becomes especially valuable for teams, where the same task can be approached differently depending on who’s running it. With custom agents, these workflows become shared, repeatable, and easier to review.

They also let fast, execution-heavy tasks start in the CLI, carry context into the IDE, and land on GitHub as reviewable, shippable work. Rather than losing context between steps, agents help maintain continuity across your toolchain.

Once you encode the workflows that matter to your team, Copilot CLI becomes less about asking for help and more about reliably supporting how your team actually works day to day.

Make GitHub Copilot Truly Work for Your Team

As an authorized GitHub Enterprise Partner, Dragonsoft provides comprehensive GitHub Copilot enterprise licensing, backed by expert pre-sales consulting and dedicated technical support. From initial evaluation and seamless deployment to resolving everyday technical queries, Dragonsoft delivers practical support tailored to help your team effectively adopt Copilot into your existing tech stack.

Stop the Blame Game: 6 Ways to Supercharge Your Developer Workflow with JSM

Dragonsoft DevSecOps — Mon, 22 Jun 2026 05:36:41 +0000

Executive Summary:Amidst the wave of digital transformation, the "wall" between development and IT operations (DevOps) often leads to delivery delays and disconnected collaboration. As an Atlassian Global Platinum Solution Partner, Dragonsoft brings you the latest insights into connecting development, operations, and business teams via the unified Jira Service Management (JSM) platform. This article explores 6 core methods—including standardizing requirement intake, automating change management, and leveraging AI-driven incident response—to help enterprises break down information silos, minimize risks, and comprehensively accelerate software delivery and service management.

As every business is becoming digital-centric, high-quality software development is more important than ever. Development and engineering teams play a critical role in delivering customer value, revenue growth, and competitive differentiation.

However, while they are under pressure to ship more digital products and services faster, teams face challenges such as inefficient handoffs, extended lead times, and limited visibility from pipeline stages to final delivery.

To improve productivity, decrease time to market, and respond to incidents faster, development and engineering teams must prioritize and streamline the flow of work that matters while increasing visibility and collaboration with other teams, especially IT operations. Here are six ways to supercharge developer workflows with Jira Service Management:

Table of Contents
1.Unite development, IT, and business teams on one industry-leading platform
2.Streamline development work intake and prioritization
3.Create shared visibility into customer requests
4.Deploy changes faster while minimizing risk
5.Accelerate incident response and collaboration
6.Unlock visibility across teams with asset and configuration data

1.Unite development, IT, and business teams on one industry-leading platform

For many organizations, Atlassian has become the platform that unifies and accelerates work across development, IT operations, and business teams. Built on the same platform as Jira, Jira Service Management is uniquely positioned to help development teams provide more value to their customers by streamlining the intake of work, deploying faster while minimizing risk, and accelerating incident response with IT operations.

And because you’re on a single platform,developers, IT operations, and support teams have a shared view of every issue from start to finish. Collaboration is made easy—all issue context is visible, so there’s no need to hunt down details in other tools.

“We’ve really seen the value of being able to funnel requests into a central location, from both recording it to see trends and to streamline the workflow. It’s been a really positive cultural shift.”
Jeff Lai - Internal Infrastructure - Canva.

Don’t just take our word for it, analysts have recognized Atlassian as a leader

Gartner

2024 Magic Quadrant TM for DevOps Platforms

“Atlassian has effectively integrated Jira, Jira Service Management and Confluence to provide a platform that enables DevOps teams to collaboratively manage their work. Atlassian’s customers find that these tools become a core part of their way of working.”

FORRESTER®

2023 WaveTM for Enterprise Service Management

“Atlassian’s differentiated vision is to offer a comprehensive and integrated suite of tools that seamlessly connects development, IT, and business teams to foster enhanced collaboration and workflow efficiency across the entire service delivery lifecycle.”

2.Streamline development work intake and prioritization

Developers use Jira Service Management as a single source of truth to streamline work intake. This enables them to classify and prioritize work before it hits their backlogs and allows for proper resource allocation. Jira Service Management’s customizable self-service portal makes it easy for customers to report bugs, feature requests,incidents, and other development-related requests. Teams can also utilize dynamic forms to build user-friendly request screens to capture relevant information up front and eliminate time-consuming back-and-forth conversations.

Beyond the customer portal, Jira Service Management provides multichannel support to make it easy for your customers to ask for help. Whether through chat, email, or an embeddable widget, you can meet people where they work every day. And by adding the AI-powered virtual service agent and integrated knowledge base to their service desk, developers can automate support interactions and provide exceptional service at scale.

3. Create shared visibility into customer requests

Collaborators play a crucial role in enhancing the efficiency and effectiveness of development teams working alongside IT operations. A collaborator is a licensed Jira user who does not have a Jira Service Management license, but they can provide invaluable support by facilitating communication and collaboration between internal teams. By allowing developers to view issues, comments, and attachments and add internal comments in Jira Service Management, they can share insights on customer requests and help streamline the troubleshooting process, leading to improved service delivery and customer satisfaction.

“I knew tickets would need to switch back and forth from the DevOps team to Engineering. [The new solution] also needed to be easy to set up and flexible to customize. The developers are already using Jira, so it didn’t make sense to use another tool for service requests that needed integrations.”
Ken Siskind - Engineering Program Manager - Toast

4. Deploy changes faster while minimizing risk

Lighten your development team’s workload with automated change risk assessments and advanced approval workflows. With Jira Service Management, teams can increase the visibility of deployments by automatically surfacing recent changes to operations teams, enhancing efficiency and collaboration while reducing risk to the business. Dev teams can use deployment tracking to automatically create change requests when initiating deployments to selected services, and with deployment gating, teams can allow or prevent deployments at specific points in the change management process by connecting a CI/CD tool such as Bitbucket, Jenkins, or GitLab.

“Jira Service Management gives us more automated change management workflows that are well connected to development work. It’s one of the more elegant workflows that I’ve seen.”
Josh Costella - Senior Atlassian Solutions Specialist - Nextiva

5. Accelerate incident response and collaboration

Empower dev and ops during an incident by centralizing alerts, notifying the right people, and enabling them to swarm and take rapid action. Jira Service Management offers customizable on-call schedules, alert routing rules, and escalation policies so teams can handle alerts differently based on their source and urgency. Major incident escalation in Jira Service Management enables dev and ops teams to swarm via incident conference calls and ChatOps integrations with Slack and Microsoft Teams. And with the incident investigation view, incident responders have a single source of truth where they can review recent code deployments from integrated CI/CD tools to further aid in identifying potential root causes of deployment-related incidents.

Plus with new AIOps features in Jira Service Management, teams can prioritize critical alerts through AI alert grouping, involve relevant dev and ops members using AI-generated incident summaries and timelines, and streamline post-incident review generation to facilitate learning and prevent future incidents.

6. Unlock visibility across teams with asset and configuration data

Jira Service Management Assets helps development, IT operations, and business teams manage their assets and related configurations in one central location. It uses a federated approach by integrating multiple data sources into a comprehensive and adaptable repository that evolves alongside your business needs, ensuring your asset information remains accurate and up-to-date. This versatile solution helps prevent system disruptions, maintains security and compliance, and optimizes costs. Assets empowers organizations to streamline their operations, make data-driven decisions, and stay ahead in today’s dynamic business landscape.

Trusted by over 55,000 organizations globally, Jira Service Management has become the core engine driving DevOps implementation and Enterprise Service Management (ESM) transformation.
As an Atlassian Global Platinum Solution Partner, Dragonsoft not only provides official licensing and professional delivery for the entire Atlassian product suite—including Jira Service Management, Jira Software, and Confluence—but also boasts an experienced team of senior consultants. We specialize in tailoring agile development and integrated ITSM/DevOps solutions that align with local development practices for enterprises in Greater China, helping your team break down information silos and accelerate product development.

Unlock Your High-Efficiency Collaborative Workflow Today

If you want to experience the latest AI features of Jira Service Management, or plan to optimize the collaboration workflows across your R&D, operations, and business teams, contact the Dragonsoft expert team today. We provide a comprehensive, one-stop service ranging from product demos and trials to implementation, deployment, training, and custom development.

Is AI actually helping your dev team, or just generating more Jira tickets?

Dragonsoft DevSecOps — Thu, 18 Jun 2026 06:45:32 +0000

Abstract:The latest Atlassian AI Collaboration Report reveals a sobering fact: 96% of enterprises have yet to see a transformative return on their AI investments. The primary reason is that AI is often confined to improving "individual productivity" rather than solving "team collaboration." Leading enterprises that have achieved a real breakthrough are building connected knowledge bases and systems to turn AI into a "strategic collaborative teammate."
Compiled by Dragonsoft, an Atlassian Platinum Solution Partner, this article guides you through how to use the Atlassian platform to break down information silos and achieve a true leap from "single-point efficiency gains" to "organization-wide intelligent collaboration."

Over the past year, AI usage has doubled, employee productivity has increased by an average of 33%, and about 1.3 hours are saved daily—these numbers sound inspiring. However, Atlassian's recently released AI Collaboration Report reveals a sobering truth:

96% of companies have not yet seen significant improvements in organizational efficiency, innovation, or work quality.
Yes, AI is helping individuals complete tasks faster, but it hasn't made team collaboration any better.

Key Insight: The True Bottleneck of AI is Not Technology, But "Collaboration"

Atlassian surveyed 180 Fortune 1000 executives and 12,000 knowledge workers, discovering that:

· Most AI tools focus on individual efficiency, not team synergy.

· Information silos persist, goals are disconnected, and AI lacks access to critical contextual information.

· An overemphasis on "AI + individual productivity" may actually exacerbate work misalignment and employee burnout.

"I haven't seen any major transformational change in how teams operate. Their operating models are largely the same, just with a few more flashy fringe features."
— Head of Global Digital Marketing Platforms at a Fortune 500 Company

What Did the 4% of Companies That Achieved Transformational Change Do Right?
The report highlights that successful companies share three common practices:

1.Build a company-wide interconnected knowledge base: Enable AI to access high-quality, contextual organizational knowledge rather than fragmented personal information.

2.Establish infrastructure to support AI-driven collaboration: Make AI the "connective tissue" of the team through integrated systems, clear policies, and goal alignment.

3.Treat AI as a team member, not just a tool: Clearly define AI's role in every project, encourage hands-on experimentation, and promote high-ROI AI use cases.

Redefining AI's Return on Investment (ROI)
Atlassian advises companies to stop measuring AI value solely by "time saved" or "the number of automated tasks," and instead re-evaluate it across the following three dimensions:

Dimension:1.Organizational Efficiency 2.Work Quality 3.Innovation Capacity
Question：1.Is AI helping the team solve problems with less effort? 2.Is AI consistently improving the quality of output? 3.Is AI empowering the team to do things they couldn't do before?
Example Metrics：1.Ticket resolution cycle, employee alignment 2.Reduction in error rates, higher customer NPS 3.Experimentation cycles, number of new product launches

The Dragonsoft Advantage

As an Atlassian Platinum Solution Partner, Dragonsoft deeply understands that the true value of AI lies not in "replacing human labor," but in enhancing team collaboration. Combined with Atlassian platforms (such as Jira, Confluence, Rovo, etc.), we help enterprises:

· Break down knowledge silos and build an AI-ready collaboration system.

· Set and track team goals to perfectly align AI with business objectives.

· Design AI roles and workflows to drive cross-departmental collaborative innovation.

We have helped multiple enterprises evolve from "AI tool experimenters" to "AI collaboration drivers," achieving a dual leap in both organizational efficiency and innovation capacity.

Want to Get the Full Report?

This 48-page Atlassian AI Collaboration Report includes:

· Analysis of the current state of human-AI collaboration
· Differences in AI usage across various job functions
· Cross-country/regional comparison data
· Practical case studies and actionable checklists
· Executive interviews and AI investment recommendations

Ready to move your team from "simply using AI" to "strategic AI collaboration"?
Download the full Atlassian AI Collaboration Report whitepaper now to unlock the best practices of top global enterprises in unleashing AI's potential!

As an Atlassian Platinum Solution Partner and the first officially rated Five-Star Solution Provider in Greater China, Dragonsoft offers one-stop enterprise-grade services:

· Expert-Level Implementation Consulting: Combining Agile and DevSecOps concepts to tailor an AI collaboration architecture based on core tools like Jira and Confluence.
· Seamless Cloud Migration: As the first Cloud Specialized Partner in Greater China, we securely and efficiently safeguard your data's transition to the Atlassian Cloud and AI platforms.
· Full-Lifecycle Escort: Covering trial evaluations, system deployments, data migrations, custom development, training, and localized technical support.

Grails 8 is Here! 🚀 Moving to Java 21 & Spring Boot 4

Dragonsoft DevSecOps — Tue, 16 Jun 2026 10:11:31 +0000

Abstract：As the first major release since Apache Grails graduated to a Top-Level Project (TLP) under the Apache Software Foundation (ASF), Grails 8 marks the framework's full transition into a modernized technology stack powered by Java 21/25 and Spring Boot 4. However, while enterprises reap the benefits of these powerful new features, they also face the real-world engineering challenge of slower application reloading and declining development efficiency in large-scale codebases.
As an Authorized JRebel Partner, Dragonsoft proudly brings you this deep dive by James Fredley, Vice President and Chairman of Apache Grails. This article delivers cutting-edge feature interpretations, a smooth upgrade guide, and industry-grade hot-deployment efficiency optimization solutions to help Java teams clear away productivity bottlenecks on their upgrade journey.

Grails 8 represents the next major step in the evolution of the Grails framework. This release focuses on long-term stability, ecosystem alignment, and modernizing the foundation that Grails applications rely on in production.

In my role as VP and chair for Apache Grails, I’ve been guiding the team developing Grails 8. Read on for an inside look at the recent transformation of Grails into an Apache Software Foundation project, what is arriving in Grails 8, why these changes were made, and what Java development teams should be thinking about as they prepare to adopt Grails 8.

I’ll also cover the release timeline, major platform changes, deprecations, and practical guidance for upgrading existing Grails applications to Grails 8.

1.A New Chapter for Grails at the Apache Software Foundation

In September 2025, after an 18-month migration effort, Apache Grails graduated from incubation to become a Top-Level Project (TLP) at The Apache Software Foundation (ASF). For a framework that has been in continuous development since 2005, this was the most significant governance change in its history, and it reset the foundation on which every future Grails release — including Grails 8— will be built.

Governing, Developing, and Releasing Grails Under the Apache Software Foundation

The move to the ASF changed how Grails is governed, developed, and released. Ownership shifted from a single-organization model (Grails was previously stewarded in turn by G2One, SpringSource, Object Computing, and the Grails Foundation/Unity Foundation) to a volunteer-driven, vendor-neutral Project Management Committee operating under "the Apache Way" of consensus and transparency.

Decisions now happen on public mailing lists, code reviews are open, and releases follow ASF policy for licensing, provenance, and reproducibility. For enterprise teams, that translates into a clearer paper trail, predictable governance, and no single point of corporate failure.

The technical work behind the transition was substantial.

Changes included:
· GitHub Repository Consolidation: The Grails team consolidated more than 24 separate GitHub repositories into a single grails-core mono-repo that now produces over 325 published JAR files across 109 Gradle projects.

· Accelerated Build Times: Build times for a Grails release dropped from three weeks to roughly 30 minutes.

· Unified Maven Coordinates: Maven coordinates were unified under org.apache.grails, every published artifact was reviewed for license compliance, and a Software Bill of Materials (SBOM) is now generated for every JAR. The build system itself was made reproducible end-to-end so that any third party can independently verify a release — a capability that benefits downstream Grails applications as much as it does the framework.

The Revitalized Grails Community
Just as importantly, the ASF transition has visibly revitalized the community. Grails 7 was the first stable release shipped under the ASF, and it pulled in contributions from a much broader cast of committers than recent prior releases — including significant contributions back to Apache Groovy itself. New committers, new mailing lists, a refreshed Slack workspace, and a more active issue tracker have all followed.

This shift most directly affects long-term framework adoption: a framework with one maintainer is fragile, but one with dozens of active contributors at an established foundation is not. It’s important to look at the Grails 8 release in the context of that renewed momentum.

Renewed Momentum for Grails
Grails 8 is the first major version planned and executed entirely under ASF stewardship, and it reflects the project's confidence in its new operating model. The roadmap is no longer constrained by what one organization can fund; it’s set by where the broader JVM ecosystem is heading and where the volunteer team has the capacity to lead.

2. A Look Back at Grails 7

To understand where Grails 8 is headed, it helps to see what Grails 7 already delivered. Released on October 18, 2025, Grails 7.0.0 was the first stable release under ASF leadership. It serves as the technical groundwork for everything Grails 8 builds on top of.

Java Modernization With Grails 7

Grails 7 modernized the entire stack. It moved to Apache Groovy 4.0.x, Spring Boot 3.5.x, Spring Framework 6.2.x, and Jakarta EE 10 (the long-awaited javax.* -> jakarta.* migration), and it required Java 17 as a minimum. Maven coordinates were rebased onto org.apache.grails, the grails-i18n plugin was relocated to its own coordinates and made transitive by default, and the entire build was made byte-for-byte reproducible with SBOMs for every JAR. The Grails Forge application generator (start.grails.org) and a lightweight Grails Wrapper (grailsw,~25KB) shipped as first-class CLIs alongside the legacy shell. Functional testing got a refresh with Geb 8 and containerized browser support, and cloud.wondrify.asset-pipeline 5.x replaced the older Asset Pipeline coordinates.

Grails 7 also did the unglamorous but necessary work of pruning. Multi-project reload support was added for modular applications, and a long list of deprecated APIs from the Grails 5 and 6 eras were either removed or scheduled for removal in 8. In other words, Grails 7 spent its release cycle aligning the framework with the modern JVM, getting the project to ASF policy compliance, and clearing the runway. Grails 8 is what the team builds with that runway clear.

3. Grails 8: Release Timeline and Strategy

Grails 8 has been developed with a clear goal: align the framework with the modern JVM ecosystem while providing a stable, forward-looking foundation for enterprise Grails applications. The release timeline reflects that priority, balancing necessary platform shifts with a strong commitment to predictable upgrades.

Release Window for Grails 8
Grails 8 development began in late November 2025, immediately following the Spring Boot 4.0.0 GA. The first public milestone, Grails 8.0.0-M1, was published on May 6, 2026, with subsequent milestones, release candidates, and the 8.0.0 General Availability release tracking the maturity of the underlying platform stack. Until 8.0.0 GA, teams should treat 8.0.x milestones as preview builds suitable for evaluation and migration planning rather than production deployment.

Platform Alignment Drives the Grails 8 Release Cadence
Grails 8 is intentionally tied to Spring Boot 4.0 and Spring Framework 7.0. This is why M1 did not arrive sooner: the framework will not ship a major release on a pre-GA Spring stack. Once 8.0.0 GA is published, the project plans to maintain a cadence of monthly 8.0.x patch releases that follow Spring Boot's own monthly cadence, with out-of-band releases for security and urgent fixes.

Overlapping Lifecycles for Grails 7 and Grails 8
The 7.0.x line continues to receive full updates and maintenance until the Spring Boot 3.5.x end-of-life on June 30, 2026. That gives teams a clear runway: they can stay on Grails 7 while Spring Boot 3.5 is supported, plan their Grails 8 migration during that window, and avoid the trap of running on an unsupported underlying platform. Grails 6.2.3 (released January 3, 2025) was the final 6.2.x release and the last pre-ASF release; teams still on Grails 6 should plan a migration to 7.0.x first, then to 8.0.x, rather than attempting a single-step jump.

4. Design Goals Behind Grails 8

Every major Grails release is driven by a small number of core goals. For Grails 8, those goals are centered on longevity, clarity, and interoperability.

· Longevity: Grails 8 aligns the framework with platforms that have multi-year support windows: Java 21 LTS, Spring Boot 4.0.x, Jakarta EE 10, and Hibernate 7. By tracking the long-term branches of its core dependencies (and by removing classes and APIs that pinned the framework to older versions of those dependencies) Grails 8 is positioned to receive security and feature updates without disruptive rewrites. The mono-repo, reproducible builds, and SBOMs introduced under the ASF transition further reduce the maintenance burden so the project can sustain that cadence.

· Clarity: Grails 8 deletes a substantial amount of legacy code — including the original JSONBuilder, the Mixin AST transform, deprecated EnumMarshaller classes, the legacy named-query infrastructure (NamedCriteriaProxy, NamedQueriesBuilder), the AetherGrapeEngine, deprecated plugin filters, and several long-deprecated MongoEntity and tag library methods. The result is a smaller, more focused public surface area where the recommended way to do something is also the only way. This change makes the Grails framework easier to learn and easier to support.

· Interoperability: Spring Boot 4 modularized its auto-configuration into domain-specific modules (spring-boot-webmvc, spring-boot-servlet, spring-boot-mongodb), Spring Framework 7 dropped its own org.springframework.orm.hibernate5 package and adopted JSpecify nullability annotations, and Jackson 3 replaced Jackson 2 as the default JSON mapper. Grails 8 absorbs all of those changes upstream so that teams who consume Spring or Jakarta APIs directly inside their Grails application get the modern, supported versions without fighting Grails for them.

Modern JVM and Jakarta Alignment With Grails 8
Grails 8 explicitly aligns with the current generation of JVM and Jakarta standards.

The Hibernate 7 upgrade is being landed via PR #15568, a substantial body of work that sits behind the 8.0.x-hibernate7 branch and replaces the previous attempt in PR #15530. It is expected to merge before 8.0.0 GA, which is why M1 should be treated as a preview of the platform shift rather than its final form.

This alignment is necessary because Spring Framework 7 and Spring Boot 4 are designed around Java 17+, Jakarta Servlet 6.1, and the new modular auto-configuration layout. Staying on the older stack would have forced Grails to backport security fixes indefinitely; instead, the framework moves with its foundation.

Reducing Legacy Drag With Grails 8
A meaningful portion of the Grails 8 work is deletion. The following were removed by PR #15565:

· The legacy JSON/XML EnumMarshaller
· The JSONBuilder (superseded by StreamingJsonBuilder)
· The old Mixin/MixinTargetAware/MixinTransformation machinery
· The deprecated ConstraintsEvaluator
· The CompatibilityPluginFilter and the entire PluginFilter hierarchy
· The BinaryGrailsPluginDescriptor
· The CorePluginFinder
· AetherGrapeEngine/AetherGrapeEngineFactory
· The original gson-views JSON generator classes
· The GORM AutoTimestamp annotation and the NamedCriteriaProxy/NamedQueriesBuilder named-queries infrastructure (the test class for which alone was over 1,000 lines)
· The grails-events-compat shim
· Deprecated methods on GrailsApplication, GrailsPluginManager, MongoEntity, FormTagLib, and ApplicationTagLib

None of these were popular APIs by 2026, but each one carried test infrastructure, documentation, and a non-zero compatibility tax. Removing them shrinks the surface area Grails has to defend against future Spring, Groovy, and Hibernate changes, and it makes the remaining APIs easier to learn, document, and support.

Production-First Focus for Grails 8
Grails 8 is being designed against the realities of running Grails in production:

· Observability defaults are sensible out of the box. Spring Boot 4's liveness and readiness probes are exposed by default on the Health endpoint, which means Kubernetes deployments get correct probe behavior without per-app boilerplate.

· Reproducible, attestable builds. Every published JAR ships an SBOM, and the build is reproducible end-to-end so security teams can verify provenance.

· Logging defaults match modern infrastructure. Logback now defaults to UTF-8 for log files, aligning with Log4j2 and with most container log scrapers.

· Predictable plugin compatibility signals. The Grails Gradle Plugin will fail fast at configuration time when it detects incompatible setups (for example, using grails-micronaut without enforcedPlatform on the BOM), rather than letting builds fail in obscure ways at runtime.

5. What's New in Grails 8

Grails 8 introduces a set of changes that impact how applications are built, configured, and run. Some of these will feel incremental, while others reflect deeper platform shifts.

Core Framework and Dependency Updates
The headline changes in Grails 8.0.0-M1 include:
· Spring Boot 4.0.5 and Spring Framework 7.0.6 (PR #15541).

· Spring Boot autoconfigure modularization. The monolithic spring-boot-autoconfigure JAR is gone; auto-configuration classes live in domain-specific modules such as spring-boot-webmvc, spring-boot-servlet, and spring-boot-mongodb. Grails 8 absorbs the new layout via a split BOM (PR #15608).

· Jackson 3 (tools.jackson.) is the default JSON mapper. Jackson annotations remain at com.fasterxml.jackson.annotation. and are explicitly permitted alongside Jackson 3, so DTOs and domain classes do not need to change. Spring Boot's helper classes were renamed(Jackson2ObjectMapperBuilderCustomizer to JsonMapperBuilderCustomizer, @JsonComponent to @JacksonComponent, etc.).

· Hibernate 7 is in-flight via PR #15568 on the 8.0.x-hibernate7 branch. Grails 8.0.0-M1 itself still ships Hibernate 5.6.15.Final.

· Spring Framework 7 dropped org.springframework.orm.hibernate5 entirely. Grails 8 vendors that package into a new grails-data-hibernate5-spring-orm module under org.grails.orm.hibernate.support.hibernate5, so Grails-managed Hibernate integration continues to work seamlessly. Applications that import those Spring classes directly need to update the package name.

· Spring Security updates (PR #15609) and a refreshed grails-spring-security plugin track on a parallel release.

· Gradle 9.4.1 toolchain and a Micronaut 4 / Micronaut Platform 5 refresh across the Grails Forge generator and the grails-micronaut integration (PR #15365).

· JLine 3.30.6 and Jansi 2.4.2 for the Grails Shell CLI (PR #15367).

· Geb 8.0.1 for browser-based functional testing, JUnit 6.0.3, Spock 2.3-groovy-4.0.

· Asset Pipeline 5.1.0-M4 under the cloud.wondrify coordinates introduced in Grails 7.

Java Version Baseline for Grails 8
Grails 8 requires Java 21 to both build and run applications, up from Java 17 in Grails 7. Java 21 is a Long-Term Support release with broad ecosystem support. The Grails team chose 21 over a more aggressive baseline (such as Java 25, which is also LTS) for two practical reasons.

1.LTS alignment with the existing tooling ecosystem: Java 21 has multi-year vendor support across OpenJDK distributions (Temurin, Corretto, Liberica, Microsoft Build of OpenJDK, Oracle, Semeru), which matches the support window most enterprise teams budget for. Java 25 is newer and equally LTS, but tooling ecosystems (build agents, container images, IDE integrations, third-party plugin compatibility matrices) typically take six to twelve months to fully catch up to a new LTS.

2.Predictability for plugins: Grails has a sizable third-party plugin ecosystem. A Java 21 baseline lets those plugins target a stable bytecode level and a stable set of standard-library APIs without chasing preview features or finalized JEPs from later releases.

There is one important exception: applications that use the grails-micronaut integration must run on JDK 25 or later. This is not a Grails decision but a Micronaut one:Micronaut Core's io.micronaut.core.propagation.ScopedValues references java.lang.ScopedValue.CallableOp, which only exists in JDK 25 (the inner type was renamed from Callable to CallableOp when JEP 506 finalized ScopedValue). Running Micronaut on JDK 21 through JDK24 fails at runtime with NoClassDefFoundError:java/lang/ScopedValue$CallableOp. The Grails Forge generator enforces this requirement at generation time, and the Grails Gradle Plugin will surface a clear error if the JDK is too old. Applications that do not use any Micronaut integration are unaffected and run on JDK 21.

Configuration and Convention Updates
A handful of Spring Boot 4 changes propagate into Grails configuration:

· MongoDB property namespace: spring.data.mongodb.* is now spring.mongodb.* for Spring Boot's own auto-configuration. The Grails GORM for MongoDB plugin uses its own mongodb.* namespace, which is unaffected.

· Jackson property reorganization: spring.jackson.read.* and spring.jackson.write.* moved under spring.jackson.json.read.* / spring.jackson.json.write.*. The spring-boot-properties-migrator dependency will warn at boot time for most of these.

· Enum serialization default: As announced in the Grails 7.0.2 deprecation notice, SimpleEnumMarshaller is now the default for JSON and XML enum serialization. Enums serialize as string values (e.g., "SUBMIT") instead of the verbose legacy format with type metadata. Applications that previously opted in via grails.converters.json.enum.format: simple can remove that configuration.

· Spring Boot starter renames: spring-boot-starter-web is now spring-boot-starter-webmvc, spring-boot-starter-aop is now spring-boot-starter-aspectj, and the OAuth2 starters were renamed under the security- prefix (spring-boot-starter-security-oauth2-client, etc.). For lower-friction migrations, Spring Boot 4 ships a transitional spring-boot-starter-classic that pulls in the full module set, but new code should target the modular starters.

· WAR deployment: External-container WAR deployments now use spring-boot-starter-tomcat-runtime instead of the previous providedRuntime 'org.springframework.boot:spring-boot-starter-tomcat' idiom. Embedded Tomcat (the default for ./gradlew bootRun and bootable WARs) continues to use spring-boot-starter-tomcat unchanged.

Build, Tooling, and Developer Experience
· Gradle managed version overrides:PR #15467 replaces the Spring Dependency Management plugin with a Gradle platform plus a lightweight BOM property override mechanism. Applications can now override BOM-managed versions through standard Gradle constructs without pulling in the Spring DM plugin.

· Method-based TagLib syntax: PR #15465 introduces a method-based syntax for Grails tag libraries with full backward compatibility for the legacy closure-based form, plus benchmarks and updated documentation.

· Apache Maven Resolver in the shell CLI: The grails-shell-cli embeds Apache Maven 3.9.9 and Maven Resolver 1.9.22 for resolving plugin and dependency metadata in the legacy interactive shell. End-user Grails projects continue to build with Gradle - this only affects the shell CLI's own internal resolution.

· Grails Forge: The application generator at start.grails.org is the recommended way to scaffold a new Grails 8 application; it applies the correct BOM, enforcedPlatform semantics, and JDK enforcement rules automatically.

· Pre-tag release readiness: The new verify-branch.sh script (PR #15621) gives committers a one-command preflight check that the build is reproducible, signed, and publishable before a release tag is cut.

· Reproducible, byte-identical artifacts:PR #15625 makes per-module SBOMs and Groovydoc output byte-reproducible so that re-running a release produces identical bytes.

Performance and Runtime Behavior in Grails 8
For most applications, Grails 8 should look like a steady, incremental change in runtime behavior because Spring Boot 4 itself is not primarily a performance-focused release. A few specifics worth noting for capacity planning:

· Startup time is comparable to Grails 7 for a baseline Grails MVC application. Spring Boot 4 ships incremental startup improvements but no order-of-magnitude shift.

· Memory and footprint track Spring Boot 4's defaults. Embedded Tomcat remains the default; Undertow is temporarily unsupported in Grails 8 because it has not yet shipped Servlet 6.1 compatibility (the Grails Forge generator no longer offers Undertow as a selectable option).

6.Deprecations and Breaking Changes in Grails 8

As with any major release, Grails 8 removes functionality that has been deprecated across previous versions. These removals are intentional and aimed at keeping the framework maintainable over the long term. The official upgrade reference is the Grails 8 Upgrade Guide, which catalogs every change in detail.

Removed Long-Deprecated Features

The bulk of the deletions landed in PR #15565. The most consequential removals:

· Grails.web.JSONBuilder: Replaced by groovy.json.StreamingJsonBuilder. Code that constructs JSON manually with the old builder must move to the streaming builder.

· Legacy enum marshallers: The verbose EnumMarshaller for both JSON and XML is gone; SimpleEnumMarshaller is now always registered. Direct rendering of a single enum value via render(MyEnum.VALUE as JSON) now throws ConverterException (see PR #15212).

· Mixin annotation and AST transform: This includes MixinTargetAware and MixinTransformation. Use Groovy traits or extension modules instead.

· GORM legacy named queries: NamedCriteriaProxy, NamedQueriesBuilder, and the GORM AutoTimestamp annotation are removed. Use GORM where queries, finders, or @CompileStatic-friendly query DSLs instead.

· Plugin filtering hierarchy: CompatibilityPluginFilter, PluginFilter, BasePluginFilter, IncludingPluginFilter, ExcludingPluginFilter, IdentityPluginFilter, PluginFilterRetriever, and BinaryGrailsPluginDescriptor are all removed. Plugin discovery is now consolidated on the modern plugin manager.

· AetherGrapeEngine / AetherGrapeEngineFactory: the embedded Grape resolver in grails-shell-cli is removed. Maven dependency resolution in the shell now goes through Apache Maven Resolver directly.

· grails-events-compat: he Reactor 2 compatibility shim is gone. Applications that still imported reactor.bus.* shim classes must move to the modern grails-events API.

· Deprecated tag library methods: FormTagLib and ApplicationTagLib shed roughly a dozen long-deprecated methods. The full list is in the upgrade guide.

Behavior Changes to Be Aware Of in Grails 8
Even where APIs remain in place, several runtime defaults shift:
· @SpringBootTest no longer auto-configures MockMvc, WebClient, or TestRestTemplate. Tests that relied on the implicit injection must add @AutoConfigureMockMvc / @AutoConfigureWebClient / @AutoConfigureTestRestTemplate explicitly.

· @MockBean and @SpyBean are removed in favor of @MockitoBean and @MockitoSpyBean from org.springframework.test.context.bean.override.mockito. The new annotations work on test-class fields only and cannot be declared in @Configuration classes.

· TestRestTemplate moved to org.springframework.boot.resttestclient.

· HttpStatus.MOVED_TEMPORARILY is removed. Use HttpStatus.FOUND instead - both are HTTP 302 with no behavioral difference.

·Spring theme support is removed from Spring Framework 7. ThemeResolver, ThemeSource, Theme, SimpleTheme, and SessionThemeResolver no longer exist. Applications that switched stylesheets via Spring themes must implement the equivalent using configuration properties or session attributes.

· Spring Retry is no longer managed by Spring Boot 4. Applications that use @Retryable, @EnableRetry, or @Recover directly need to declare the dependency in build.gradle.

· Logback log files default to UTF-8. Log scraping pipelines that assumed the platform default charset must switch to UTF-8.
Liveness and readiness probes are enabled by default on the Health endpoint; disable via management.endpoint.health.probes.enabled: false if needed.

7.Grails 8 Upgrade and Migration Considerations

Upgrading to Grails 8 is straightforward for teams that have kept up with deprecations, but it should still be approached deliberately. The upgrade is fundamentally a Spring Boot 3 to Spring Boot 4 migration with Grails-specific guardrails layered on top; the bulk of the breaking changes come from upstream platform shifts, not from Grails itself.

A Practical Migration Sequence for Upgrading to Grails 8
Follow these steps to simplify the migration from Grails 7 to Grails 8:

1.Upgrade to the latest Grails 7.x release first. Grails 7 finished the javax.* -> jakarta.* migration and moved Maven coordinates under org.apache.grails. Doing this on the latest 7.x release before jumping to 8 means each problem surfaces in isolation rather than all at once.

2.Address all deprecation warnings on Grails 7 before moving to Grails 8. Anything deprecated in 7 is removed in 8. The Spring Boot spring-boot-properties-migrator dependency is the single most useful tool here - add it as runtimeOnly, boot the app, fix every warning it logs, then remove the dependency.

3.Audit direct Spring imports. Search the codebase for org.springframework.orm.hibernate5., com.fasterxml.jackson.databind.,org.springframework.boot.web.embedded.*,HttpStatus.MOVED_TEMPORARILY, and Theme-related classes. Each appears in the Grails 8 upgrade guide with the new replacement.

4.Validate plugins and custom framework extensions. Verify every Grails plugin in build.gradle has a Grails 8-compatible version. For grails-micronaut users, ensure the BOM is applied as enforcedPlatform (the Grails Gradle Plugin will fail the build at configuration time if it is not).

5.Update tests. Add @AutoConfigureMockMvc / @AutoConfigureTestRestTemplate where relevant, swap @MockBean for @MockitoBean, and update the TestRestTemplate import.

6.Plan your JDK story. JDK 21 is the baseline. If you use Micronaut anywhere, plan for JDK 25 in CI and production. Mixed-deployment teams should standardize before migration.

7.Test with production-like workloads. Spring Boot 4's defaults (UTF-8 logging, probes-on-by-default, devtools-livereload-off-by-default) are individually small but collectively visible in staging. Run a full pre-prod cycle.

8.Pay attention to startup time and redeploy behavior. Spring Boot 4 changes a number of dev-loop defaults (covered in the next section), and reload speed on medium-to-large applications becomes a measurable productivity factor during the migration itself.

Reloading Options for Grails 8 Development
Reload speed is the part of the developer feedback loop that gets noticeably worse as a Grails application grows, and Grails 8 is the right moment to make a deliberate choice rather than rely on the default.
The Apache Grails development reloading documentation lists the supported options for Grails 8. The three that matter for most teams in practice are:

1.Spring Boot Developer Tools is the default in newly generated Grails applications and the right starting point. It uses a dual-classloader approach to automatically restart the application context on code changes and supports live reload for static resources. The official Grails docs are direct about its scaling behavior: "This works well until your application becomes very large, at which point restarts may take longer or fail." On medium-to-large Grails applications, a DevTools restart routinely takes –seconds to minutes because every classpath change rebuilds the application context, drops in-memory state, evicts JIT optimizations, and re-runs @PostConstruct and bootstrap logic.

2.IntelliJ IDEA Enhanced HotSwap in Debug Mode reloads modified classes during a debug session without restarting the application context. It avoids the full DevTools restart but is constrained by JVM hot swap's structural-change limits unless you also run on the JetBrains Runtime with -XX:+AllowEnhancedClassRedefinition. In practice, the perceived reload time on a medium-to-large application is tens of seconds, similar to DevTools because most non-trivial changes (adding a method, changing a Spring bean, modifying a GORM mapping) are exactly the structural changes the IDE cannot apply without a fuller reload.

3.JRebel is a commercial JVM agent that performs true hot swapping via bytecode instrumentation, reloading classes, configurations, and resources without restarting the JVM and without losing application state. The reload is essentially instantaneous — typically well under a second, even on large applications - because nothing is being torn down and rebuilt. JRebel is the option Grails specifically recommends for advanced reloading needs, with first-class Grails / Spring Boot integration and a dedicated IntelliJ IDEA plugin.

_Grails also lists Hotswap Agent and plain JVM debug-mode hot swap. Hotswap Agent is currently classified as experimental for Grails with documented limitations, and JVM debug-mode hot swap is limited to non-structural changes. Neither is a realistic primary reload story for an enterprise Grails 8 application, but both are viable for narrow use cases.
_
Spring Boot 4 itself flips one default that affects all of these: spring.devtools.livereload.enabled is now false by default. The Grails Forge generator opts back in via application-development.yml, but existing Grails 7 applications that rely on devtools live reload must add this configuration manually after the upgrade.

Why Choose JRebel for Medium-to-Large Grails 8 Applications?
The practical message for Grails 8 teams is simple. On a small application, DevTools is fine. As the application grows (and almost any application worth migrating to Grails 8 has grown) the per-change reload cost climbs from a few seconds to tens of seconds to, on the largest enterprise applications, minutes.

Multiply that by the number of changes a developer makes in a day and the difference between a tens-of-seconds reload and a sub-second JRebel reload is the difference between a productive day and a context-switching day.
JRebel matters most precisely where Grails 8 migrations have the biggest impact:

· Applications with significant in-memory state:caches, scheduled jobs, Spring Security sessions, GORM connection pools, queued messages, websocket connections. DevTools drops all of it on every reload; JRebel preserves it.

· Modular and multi-project Grails applications, where a one-line change in a shared module triggers a cascading rebuild across every consumer.

· Applications that use grails-micronaut, where the classpath is larger, the JDK requirement is higher (JDK 25+), and bootstrap is correspondingly heavier.

· Migration work itself, where you are iterating on Spring Boot 4 deprecation warnings, plugin compatibility fixes, and GSP/Groovy/Java changes in rapid succession. Every saved second of reload time compounds across the migration cycle.

For Grails 8 teams modernizing real production applications, the reload-speed gap between the free options and JRebel is large enough that it materially affects how long the migration takes — and how confident the team is when they ship it.

8.Final Thoughts on Grails 8

Grails 8 is about ensuring that Grails remains a first-class framework for building and running JVM applications in modern environments. The changes in this release reflect years of experience running Grails in production, the project's first full development cycle under the Apache Software Foundation, and a clear focus on the future of the ecosystem: Java 21, Spring Boot 4, Spring Framework 7, Hibernate 7, and Jakarta EE 10.

For teams already on Grails 7.x, the upgrade is incremental rather than disruptive, provided deprecation warnings have been kept clean. For teams still on Grails 6.x, the recommended upgrade path is to migrate to the latest Grails 7 release first, then to Grails . This work should be done before Spring Boot 3.5.x reaches end-of-life on June 30, 2026.

Teams that plan their upgrades thoughtfully will find Grails 8 to be a stable, capable platform for the next generation of Grails applications, and the first one explicitly designed to be stewarded by an open community for the long haul.

Conclusion

The release of Grails 8 marks a major milestone in elevating the performance and stability of the modern JVM ecosystem. However, it is undeniable that the expanded dependencies, higher JDK baseline, and modularized auto-configurations also mean that the startup and loading overhead for medium-to-large-scale applications will become increasingly heavy.

As an Authorized JRebel Partner, Dragonsoft has long been dedicated to providing enterprise-grade Java teams with leading development efficiency tools and localized technical support.

Unlock Your Ultimate Development Experience:

Want to free your developers from the low-efficiency loop of "changing one line of code, waiting to brew a cup of coffee" and stay ahead of the curve in the Grails 8 era?

Contact Dragonsoft, your Authorized JRebel Partner, today to apply for a JRebel Free Trial and experience seamless, under-one-second hot reloads!

Still waiting 10 minutes for your Java app to restart? (How NTT Data saved8,000 hours)

Dragonsoft DevSecOps — Tue, 19 May 2026 10:00:20 +0000

Dealing with heavy enterprise Java, massive Spring contexts, or SAP Commerce? The "change one line, wait 10 mins" loop is brutal. Here’s a classic breakdown of how JRebel hot-reloading bypassed 120k redeploys and saved 8,000 hours.
Whether you are maintaining a stable Java 8/11 foundation or stacking complex logic in modern frameworks, waiting for the JVM to reload is a universal DevEx killer. Let's dive into how NTT Data fixed their inner loop.

Breaking the "Redeploy" Bottleneck

For these enterprise e-commerce projects, lengthy code redeploy times remain a deep-seated bottleneck for R&D efficiency. The inefficient cycle of “change one line, wait ten minutes for a restar” quietly drains a team's delivery capability, regardless of the technological era. How can this challenge be overcome?

"JRebel improved our development efficiency by allowing us to rebuild the Java classes without restarting the server, saving us a lot of time and focus on the tasks we're dealing with instead of waiting on the server."
— Mansur Arisoy, Head of CX Tech Office, NTT Data Business Solutions

About NTT Data Business Solutions

NTT Data Business Solutions is headquartered in Istanbul, Turkey and employs more than 1,500 people. The company includes a consultancy department which works with customers from B2B and B2C industries who have e-commerce websites. NTT Data consults specifically for clients using SAP Commerce, along with Java and Spring.

SAP Commerce, formerly known as SAP Hybris, is an e-commerce platform used by large enterprise organizations to deliver rich omnichannel experiences to customers, from content management to personalization and order processing.

Many Commerce developers face long redeploy times—a challenge NTT Data was also facing. However, with JRebel, NTT Data developers were able to reduce their redeploy times and boost productivity.

Monolithic Applications and SAP Commerce Led to Decreased Productivity

SAP Commerce is notorious for long redeploy times—with 50% of users reporting redeploy times of eight minutes and higher. For NTT Data, delivering solutions quickly is critical for success. Clients want to see requirements go live as soon as possible and any bugs encountered in production need to be resolved immediately.

NTT Data uses Spring, Ant, Java 8, and Java 11 on their team of 40 developers. For foundational systems driving core global e-commerce transactions, stability is paramount. Like many large enterprises managing massive legacy codebases, relying on stable Long-Term Support (LTS) Java versions is a highly pragmatic choice. However, this extensive historical business logic brings with it the heavy burden of exhaustive JVM class loading and Spring context initialization.Burdened by this technology stack combined with the massive SAP Commerce architecture, developers were forced to wait between four to ten minutes for each redeploy after modifying code.

With a typical frequency of one to two redeploys per hour, this created a massive amount of forced idle time. It completely shattered the developers' focus and state of flow, making it impossible for the team to push work forward efficiently.

JRebel Eliminated Over 120,000 Redeploys for NTT Data

Using JRebel, NTT Data can focus on development rather than waiting on the redeployment of the project. For small changes, such as a typo, developers can now redeploy and see the new code instantly, motivating developers to continue working with SAP Commerce. Now, NTT Data developers can complete their work within scope and deliver solutions to clients sooner.

JRebel Helps NTT Data Business Solutions...

Save Time During Development
JRebel has saved NTT Data almost 8,000 hours of dev time.
Increase Productivity
NTT Data has skipped over 120,000 redeploys using JRebel.
Deliver Solutions Faster
NTT Data delivers client projects faster with JRebel.

Key Results at a Glance

Hours Saved: 7,989
Redeploys Skipped: 120,157
Faster Delivery: Sped up client project delivery by streamlining the development pipeline.

Optimize Your "Inner Loop" with JRebel | Start Your Free Trial Today
Whether your team is maintaining a rock-solid Java 8/11 commercial foundation or stacking complex business logic in modern Spring frameworks, if you are suffering from bloated applications, slow startups, and agonizing reload times, optimizing the developer's "Inner Loop" (Inner Loop Time) is always the ultimate ROI booster.
JRebel bypasses the complex classloader mechanisms, allowing for instant code changes and a seamless coding experience.

SonarQube Launches Claude Code Plugin: Bringing Deterministic Code Quality to AI-Assisted Development

Dragonsoft DevSecOps — Tue, 19 May 2026 09:01:16 +0000

Summary：As the adoption of AI coding tools accelerates, the tension between development velocity and code quality has intensified. As the officially authorized partner of SonarQube in China, DragonSoft presents an in-depth analysis of the newly released SonarQube plugin for Claude Code. This integration is set to revolutionize code governance in the AI era by leveraging "inner-loop verification" to ensure code meets enterprise-grade security and quality standards the moment it is generated.

TLDR Overview

The Claude Code plugin for SonarQube, available today in the Anthropic marketplace, integrates SonarQube's security and code quality analysis directly into the Claude Code terminal environment for real-time verification.
The plugin utilizes agentic analysis and MCP servers to scan for code smells and vulnerabilities, and blocks over 450 secret patterns before content enters the LLM context.
Developers use slash commands to check quality gate status, assess dependency risks, and review code coverage without switching to a browser.
This integration supports the Agent Centric Development Cycle (AC/DC), reducing reported AI-related outages by 44% through deterministic, inner-loop code verification.
With Anthropic's announcement earlier today of Opus 4.7, this plugin arrives at the perfect time to enable developers to use SonarQube's code verification capabilities alongside the new model.

What is the SonarQube plugin for Claude Code?

SonarQube's Claude Code plugin packages skills, agents, hooks, and our MCP server to provide Claude with everything it needs in order to access SonarQube's capabilities: the SonarQube CLI, SonarQube MCP Server, hooks for SonarQube Agentic Analysis, and secrets scanning. Once installed, Claude Code gains access to SonarQube's code quality and security analysis without ever leaving the terminal. This means full language and rule coverage—code smells, duplication, complexity, and SAST across 40+ languages—governed by your existing quality profiles and gates. The Claude Code plugin is available today in the Anthropic marketplace, ready for use alongside today's drop of Anthropic's Opus 4.7 model.

How the plugin works

Slash commands let you query your SonarQube instance in real time, and allow you to check quality gate status, list open issues, review code coverage and duplication, assess dependency risks. Moreover, every file Claude reads and every prompt you enter is automatically scanned for over 450 secret patterns before the content enters the LLM's context window.

And for organizations with SonarQube Agentic Analysis enabled (in beta now for codebases in C#, Java, JavaScript, Python, and TypeScript), PostToolUse hooks run analysis after each file edit, catching issues as they're introduced. The result is that the "Verify" step of AC/DC is embedded directly after the "Generate" step. The feedback loop that used to require a CI pipeline and a context switch now happens in seconds within the inner loop of the agent, right where the software developer is working.

Why you should care

The way code gets written has changed more in the last six months than it did in the previous decade. But velocity without code verification is just technical debt on a faster timeline: Carnegie Mellon researchers studied a widely-used AI coding tool and found that it produced a persistent 30% increase in static code analysis warnings and a 41% rise in code complexity. Every engineering team now faces the same paradox: you need agentic speed to stay competitive, but you need rigorous code verification to stay safe. The Claude Code plugin is how Sonar solves this.

It's built around what we call the Agent Centric Development Cycle (AC/DC): Guide, Generate, Verify, and Solve. AC/DC is a framework for governing how AI agents write, check, and fix code in a continuous loop. The core insight is that because AI is non-deterministic, code verification has to be deterministic—and it has to happen inside the agent loop, not after the fact in CI.

Today's release of Claude Opus 4.7 sharpens the point. Anthropic's newest generally available model is purpose-built for harder, longer-running coding tasks, and it tries to verify its own outputs before completing its work. But that self-checking instinct is still non-deterministic: the model decides what to check and how. SonarQube provides verification that is deterministic and comprehensive, with full rule coverage using your defined quality gate, every time. The two approaches are complementary: Opus 4.7 raises the ceiling on what an agent can build and catch in a single session, and SonarQube ensures nothing ships that shouldn't.

The SonarQube plugin for Claude Code allows you to extend a platform your organization already trusts into the environment where code is increasingly being written, and developers who verify their code with SonarQube are 44% less likely to report experiencing outages due to AI code.

Get started now

The plugin is available today on the Anthropic Plugin Marketplace. In Claude Code, run /plugin to open the plugin browser. Find sonarqube (under claude-plugins-official) in the Discover tab and install it. Then start a new session or reload so the plugin loads.

Run /sonarqube:integrate to walk through setup—CLI installation, authentication, and wiring up the MCP Server and hooks. Within minutes, every Claude Code session benefits from automated verification by SonarQube.

SonarQube is already a trusted AI governance tool for coding. The Claude Code plugin brings these strengths directly into the developer's agentic workflow. Try it on your next project: write code with Claude, and let SonarQube make sure it's code you can trust.

Don't just generate code—build it precisely.

AI coding has become standard practice, but "compliance upon generation" is the true competitive moat for enterprises. Faced with AI-induced "hallucinations" and the surge of technical debt, passive code reviews are a thing of the past. As an officially authorized partner of SonarQube, we do more than just provide tools; we customize end-to-end solutions for enterprise-grade AI code governance, ranging from MCP server configuration to full-lifecycle management.

Full-Stack ITSM: Why ITIL-Aligned Workflows are the Backbone of High-Performance Ops

Dragonsoft DevSecOps — Tue, 19 May 2026 08:37:19 +0000

As digital infrastructures become increasingly sophisticated, IT departments have transitioned from support roles to the forefront of business governance. As an official partner of HaloITSM, DragonSoft has observed that premier enterprises require more than just a ticketing tool; they need a "Digital Brain" capable of mastering the ITIL 4 framework and supporting mission-critical decision-making. This article explores how HaloITSM leverages visualized CMDB and agile change management to help organizations build world-class ITSM systems.

Core Governance: ITIL-Standard Issue Resolution

HaloITSM possesses exceptional architectural capabilities, enabling the unified management of complex internal service requests while strictly adhering to ITIL Help Desk standards.

Aligning IT with Business: DragonSoft assists enterprises in aligning IT processes with business goals through a fast, intuitive, and highly configurable system.
Ensuring Service Continuity: For complex incidents involving multiple steps and departments, HaloITSM provides full-cycle tracking. The core objective is to return end-users to normal status as quickly as possible, safeguarding organizational productivity.
Industry Bench-marking: By organizing your request types along the ITIL framework, you can show your customers and partners that the standard you work towards is high, and above the industry norm.

Intelligence & Touch points: Knowledge Base & Self-Service Portal

Knowledge as an Asset: Transform expert solutions into structured knowledge articles. With deep keyword indexing and rich formatting, DragonSoft helps you build a corporate "Think Tank" to enhance operational efficiency via canned responses.
Premium Custom Self-Service Portal: Offer a fully customizable, "white-label" portal that acts as an extension of your brand. End-users can autonomously raise requests, track progress, or find solutions, achieving a digital upgrade of service touch points.

Precision Control: SLA Management

Upholding Service Commitments: Utilize HaloITSM’s powerful SLA management tools to create custom response and resolution deadlines for different business priorities.
Automated Escalation Engine: Combined with DragonSoft’s implementation of automated escalation rules and real-time communication, ensure seamless internal coordination and eliminate the risk of SLA violations.

Deep Governance: Full-Stack Management from Issues to Configuration

-Problem Management: Automate the management and escalation of recurring issues. Dig deep into root causes to help the enterprise transition from "reactive patching" to "proactive governance."

Change Control: Leverage HaloITSM’s outstanding change management to track, plan, and execute organizational changes of any scale, ensuring compliance and process standardization.
Release Management: Control and document the entire lifecycle from minor bug fixes to major software enhancements in a single interface, ensuring all records are traceable and synced with end-users.
Service Catalog: Maintain a comprehensive, ITIL-compliant record of all system actions, providing progress transparency for teams and detailed service reports for stakeholders.
CMDB & Configuration Management: Track core IT assets and visualize dependencies between Configuration Items (CIs), and help you identify systemic risks via the CMDB before major incidents occur.

Why Choose DragonSoft & HaloITSM?

Out-of-the-Box ITIL Framework: HaloITSM is designed to simplify the adoption of ITIL frameworks. Partnering with DragonSoft means your solution is delivered by experts. We bridge the gap between high-end international software and your specific business goals through professional consultancy and seamless implementation.
Trusted by Global Leaders: Over 100,000 users across 75+ countries trust HaloITSM. As Mark Render, Head of Digital Systems at ACH Group, states: "I cannot recommend this product highly enough – so much so that I have now implemented this in two different organizations."

"An excellent ITSM platform is not just about managing processes; it is the philosophy that carries enterprise IT governance." With its ultimate flexibility and professional ITIL depth, HaloITSM is redefining maintenance standards for high-end global enterprises.

Contact the DragonSoft team today for a 30-minute deep-dive demo and start building your world-class IT service management system.