DEV Community: Dragonsoft DevSecOps

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.

Say Goodbye to "Fixing in Production": Comparing Java Profiling Tools for Real-time Insights.

Dragonsoft DevSecOps — Fri, 24 Apr 2026 07:42:18 +0000

Summary：In Java development, performance issues — if left undetected early — often lead to serious consequences in production: poor user experience, increased deployment costs, or even application downtime. Catching and resolving performance problems early in the development cycle is critical to maintaining efficient delivery.Dragonsoft, as an authorized distributor of Perforce, conducted an in-depth comparison of three mainstream Java performance analysis tools: XRebel, JProfiler, and YourKit. This article evaluates them across use cases, user interface, real-time feedback, IDE integration, and instrumentation overhead — with pricing and trial info included to help Java teams find the right fit.

Identifying memory leaks, threading issues, and inefficient database queries early saves development teams thousands of hours and substantial budget resources. While it’s undeniable that Java performance analysis tools play an important role in the Java code pipeline, which tool is best can depend heavily on use case and individual preference.

Three popular tools dominate the conversation around Java performance analysis: YourKit, JProfiler, and XRebel. Each tool provides specific features tailored to different stages of the software development lifecycle. DevOps engineers, performance engineers, QA engineers, systems engineers, developers, etc. must understand the specific strengths and limitations of these applications to integrate them seamlessly into their Java development practice.

In this blog post, we’ll break down the differences between YourKit, JProfiler, and XRebel side by side. Read on to find out which tool fits best into your development pipeline and helps your team build better Java applications.

YourKit: Advanced Profiling and Memory Analysis

YourKit Java Profiler delivers deep insights into memory analysis and advanced profiling. Java teams turn to this desktop application to diagnose complex memory leaks and performance bottlenecks in large Java applications.

Memory Profiling and Garbage Collection Analysis in YourKit
YourKit excels at memory profiling. It provides detailed heap dumps and deep garbage collection analysis. Teams rely on YourKit to pinpoint exact memory leak locations and understand object allocations. This deep dive into memory ensures applications run without consuming unnecessary resources.

*Thread Analysis in YourKit *
The tool offers comprehensive thread analysis. Java teams use YourKit to identify deadlocks, track contention, and monitor locking issues quickly. This visibility keeps multi-threaded Java applications working properly.

Database Monitoring and Microservice Tracing in YourKit
YourKit includes tracking for SQL queries and JDBC profiling. It also provides web request telemetry for tracing microservices. With YourKit, Java teams gain a clear view of how database calls impact overall application speed.

Feedback and Instrumentation Overhead in YourKit
YourKit offers near real-time feedback through data sampling. The instrumentation overhead to use YourKit is moderate, though users can configure the settings to improve performance during active profiling sessions.

*IDE Integration in YourKit *
Java teams can integrate YourKit directly with IntelliJ IDEA and Eclipse. This integration streamlines the profiling process without forcing developers to leave their coding environment.

JProfiler: In-Depth Development and Runtime Profiling

JProfiler bridges the gap between high-level Java performance analytics and granular JVM data. It provides unmatched insights for resolving tough performance problems during in-depth development and runtime profiling.

Memory Profiling and Garbage Collection Analysis in JProfiler
JProfiler features a robust heap walker and allocation call trees. It includes thorough garbage collection analysis, making the complex process of identifying memory leaks straightforward.

*Thread Analysis in JProfiler *
JProfiler tracks live threads and detects deadlocks. Java teams use these features to track local requests across different threads, ensuring smooth execution paths.

Database Monitoring and Microservice Tracing in JProfiler
JProfiler excels at HTTP and REST tracing, tracking responses across complex microservice boundaries. The tool highlights slow database calls so Java teams can address them quickly.

Feedback and Instrumentation Overhead in JProfiler
The JProfiler user interface displays live profiling data as it happens, although the overall approach leans toward batch-oriented analysis. The instrumentation overhead runs higher than other tools, especially when Java teams run the application in full profiling mode.

IDE Integration in JProfiler
JProfiler integrates with IntelliJ IDEA, Eclipse, NetBeans, and VS Code. This broad IDE support allows Java teams to start profiling with a single click.

XRebel: Real-Time Performance Feedback During Development

XRebel sets itself apart in the Java performance analysis landscape by focusing on addressing performance issues before production. By fixing problems early in the development lifecycle, Java teams can fix performance issues up to 60% faster.

Memory Profiling and Garbage Collection Analysis in XRebel
XRebel focuses on object allocations. This targeted focus helps accelerate performance analysis in development.

Thread Analysis in XRebel
XRebel provides a basic live threads view. This straightforward presentation gives Java teams immediate visibility without overwhelming them with unnecessary data points.

*Database Monitoring and Microservice Tracing in XRebel *
XRebel shines in distributed tracing by highlighting slow database queries across SQL and NoSQL databases. The tool traces requests end-to-end within their application UI, helping Java teams identify performance bottlenecks before code reaches production.

Real-time Feedback and Instrumentation Overhead in XRebel
XRebel features a lightweight, real-time, in-browser user interface that creates very low overhead, optimizing the experience specifically for development environments. Developers validate code changes instantly to fix Java performance issues faster and with less disruption.

IDE Integration in XRebel
XRebel supports the three most popular IDEs: IntelliJ IDEA, Eclipse, and VS Code. More than 42% of Java developers are using more than one IDE, with VS Code quickly rising in popularity for its flexibility and debugging capabilities. This integration allows teams to fit the tool seamlessly into their preferred development environments.

Head-to-Head Comparison: YourKit vs. JProfiler vs. XRebel

While YourKit, JProfiler, and XRebel are all purpose-built Java performance analysis tools, each has different capabilities and excel in different use cases. Read on to see how each tool stacks up.

Comparing Use Case, UI, and IDE Integration: How Each Tool Works
For starters, let’s take a closer look at the use case, UI, feedback models, IDE integration, and more for XRebel, JProfiler, and YourKit. While JProfiler and YourKit both have a full desktop UI, only XRebel offers a lightweight, real-time, in-browser UI. JProfiler and YourKit also don’t offer fully real-time performance analysis, although their capabilities differ here.

Each of the three Java performance tools discussed here support IntelliJ (by far the most popular Java IDE), but only XRebel supports VS Code, which is quickly gaining popularity for Java.

XRebel is also the only Java performance tool of the three that is specifically designed for development environments, whereas JProfiler can be used carefully in staging and production, and YourKit fully supports production profiling. XRebel also wins out for development use cases with low instrumentation overhead.

Profiling and Monitoring Capabilities: How Each Tool Solves Java Performance Problems
Now, take a closer look at which Java performance issues XRebel, JProfiler, and YourKit can help Java teams identify and track, and how each tool performs those functions.

XRebel works at the application level and provides only basic memory profiling capabilities, but it stands apart with live thread views, request profiling, and URL tracing.

XRebel wins with its ability to provide real-time, request-centric analysis. It continuously traces each request end-to-end: across web, service, and database layers. This automatically surfaces issues like slow queries or excessive calls as they happen, without requiring developers to start or interpret profiling sessions.

In contrast, JProfiler and YourKit provide method-level, session-based tracing that excels at deep diagnostics but requires more manual effort to connect insights across layers. XRebel simplifies this by presenting clear, actionable insights in context, helping developers understand why a request is slow during development rather than diagnosing issues after the fact.

When to Use XRebel Over JProfiler or YourKit
XRebel is simply the better choice if your Java team:

Is analyzing performance in development environments
Wants to work directly in their IDE instead of a separate desktop app
Needs real-time feedback to address Java performance issues

In these situations, YourKit and JProfiler simply don’t match the capabilities of XRebel.

When to Use JProfiler or YourKit Over XRebel
In some situations, XRebel is not the best option: e.g., production environments or situations where memory usage or garbage collection are a primary concern. Because XRebel focuses on the application level, it’s better suited for development Java performance analysis. YourKit, or in some cases, JProfiler, are the better fit for profiling Java code in production environments.

*Trial Information and Pricing: Putting Java Performance Tools to the Test *
The best Java performance analysis tool is the one your Java team will use — and the best way to determine that is with a trial during your next sprint. While YourKit, JProfiler and XRebel all offer commercial licenses and 10-15 day free trials, their pricing structures differ.

Final Thoughts on Java Performance Analysis

Finding performance bottlenecks early in the development cycle can save teams countless, debugging sessions trying to fix problems that have already hit production. That matters — because performance issues in production environments can wreak havoc and cause real consequences, including poor customer experiences, higher deployment costs, or even application downtime.

But the problems don’t just occur in production environments. Even Java performance issues caught in testing can still lead to unnecessary delays for code delivery.

That’s why addressing performance early in the development lifecycle can lead to much better (and less stressful) outcomes for your teams. With that in mind, the right tool for development stage Java performance optimization is clear.

Take a Proactive Approach to Java Performance With XRebel
By integrating XRebel into your Java development workflow, Java teams can catch performance issues before they begin to impact the business’s bottom line. This proactive strategy keeps your Java codebase clean, fast, and highly secure. DevOps engineers, performance engineers, QA engineers, systems engineers, developers, etc. stay focused on building innovative features rather than waiting for lengthy redeploys or dealing with complex production outages.

Want to see how XRebel can help your business overcome development bottlenecks to fix Java performance issues faster? Start your 14-day free trial today.

Rovo Agents Internals: How Scenarios, Triggers, and Skills Power Atlassian Automation

Dragonsoft DevSecOps — Fri, 24 Apr 2026 07:00:45 +0000

Summary:At the critical juncture where AI is evolving from "assisted Q&A" to "intelligent collaborator," Atlassian has officially launched Rovo Agents to provide IT and R&D teams with orchestrated, governable, and actionable automated workflows. In this article, Dragonsoft provides an in-depth interpretation of Atlassian's latest release, The Complete Guide to Rovo Agents, systematically breaking down the core architecture of Rovo Agents, design best practices, and pathways for DevOps scenario implementation — helping technical teams build highly reliable AI agents and achieve a substantial leap in R&D efficiency.

Atlassian's Guide to Rovo Agents:
Learn how to build, deploy, and scale your next AI teammates
A practical playbook with blueprints, best practices, and real‑world use cases for adding Rovo Agents into your workflows.

Why Rovo Agents?

Rovo agents are AI teammates that orchestrate work across all your business tools, connecting people, knowledge, and workflows wherever they live.

By automating repetitive tasks and surfacing the right context at the right time, they help teams move faster, stay focused on high‑value work, and deliver better outcomes — no matter which tools are in your stack.

Understanding Rovo Agents: The Building Blocks of Automation

Agents are AI‑driven systems that perform specific tasks by combining instructions, knowledge, skills, and triggers, then are augmented by AI reasoning. In Atlassian's ecosystem, Rovo agents act as orchestrators, automating workflows and delivering outcomes across products. They can be surfaced in chat, invoked in automation, or embedded directly into business processes.

At a high level, Rovo agents are like virtual teammates with a clear role, access to your organization's knowledge, and the ability to take actions on your behalf.

These agents run on top of a shared data layer called Atlassian's Teamwork Graph, which connects your organization's people, work, goals, and knowledge across Jira, Confluence, third‑party tools, and more. This lets them understand and reason over real organizational context, rather than treating each document as an isolated piece of information.

Rovo agents aren't limited only to Atlassian products; they connect to your entire ecosystem via a rich set of 50+ connectors, as well as virtually any application via the Model Context Protocol (MCP). You can automate workflows and orchestrate work across all your favorite tools. With Rovo, your AI teammates have access to the full picture, not just isolated silos.

The Core Components of a Rovo Agent

Every Rovo agent is built from a small set of building blocks:
INSTRUCTIONS | KNOWLEDGE | SKILLS | SCENARIOS AND TRIGGERS

Instructions
The "job description" and operating manual for the agent. Instructions define:
• The agent's role and goals (what it should and shouldn't do)
• The steps it should follow to complete tasks
• The tone and guardrails it should maintain (e.g., precise vs. exploratory)
• In Rovo Studio, this lives in the agent's behavior and scenario instructions.

Knowledge
The data and context that the agent can draw from. This can include:
• Third‑party tools connected to the Teamwork Graph (e.g., SharePoint, Google Drive)
• Atlassian sources like Jira projects and Confluence spaces
• Very specific business rules or templates referenced via Confluence Smart Links
• Knowledge can be broad (all of your Teamwork Graph) or tightly scoped to a domain (e.g., an IT helpdesk KB)

Skills (Actions and Plugins)
The tools the agent can use to read or change the work:
• Reading data: querying Jira issues, looking up customer records, pulling recent tickets
• Taking action: creating or updating Google Docs, Jira issues, drafting Confluence pages, posting to Slack, calling external APIs through Forge/MCP skills, sending a Microsoft Teams message, and sending Google emails
• Skills transform an agent from a passive answer bot into an active teammate that can move work forward

Scenarios and Triggers
To avoid a single, brittle prompt, agents can have multiple scenarios, each representing a specific task to be completed (e.g., "triage feedback," "draft release notes," "write a community post"). Each scenario has:
• Its own instructions, knowledge, and skills.
• A trigger that tells the agent when to use that scenario, based on user intent or event context.
• The default scenario is the fallback path when no other scenario's trigger is matched.

Combined with Rovo's admin and workspace settings, this lets teams deploy agents with clear guardrails; you decide which tools they can connect to, which scenarios are available to which users, and what level of autonomy each agent is granted.

These components are all coordinated by the underlying LLM, which acts as the "brain" of the agent, deciding how to interpret a request, which knowledge to search, which skills to invoke, and which scenario fits best.

Controls, Guardrails, and Governance
Scenarios and triggers also serve as powerful controls over when and how agents run. By tightly scoping each scenario's instructions, knowledge sources, and skills, you can:
• Limit what data the agent can access and which actions it's allowed to take
• Ensure sensitive workflows (such as HR or finance) run only under specific triggers or conditions
• Create separate "read‑only" and "action‑oriented" scenarios so you can phase in automation safely

What Happens When a User Sends a Prompt?

Whether a human types in chat or an automation rule invokes the agent, the flow is broadly the same:

I. Interpret the Request with AI and Context
The LLM reads the prompt, current conversation, and any structured inputs (e.g., issue fields from Jira). It identifies the user's intent and selects the most relevant scenario (or falls back to the default scenario).

II. Decide Which Knowledge and Skills to Use
Based on the scenario's configuration, the agent either:
i. Searches the appropriate knowledge sources (e.g., specific Confluence spaces, Jira projects, or other connected apps).
ii. Chooses which skills to utilize, such as researching related issues, retrieving customer history, or gathering recent feedback.

III. Reason, Orchestrate, and (Optionally) Take Action
The agent then:
i. Synthesizes information from multiple sources using the LLM.
ii. Applies the business rules encoded in its instructions (and any linked templates/rules pages).
iii. Optionally executes actions, such as:

Creating or updating Jira issues or JPD ideas.
Drafting or updating Confluence pages.
Sending notifications via Slack or other tools.

IV. Confirm and Summarize the Outcome
Finally, the agent:
i. Returns a clear, human‑readable summary of what it did and what it recommends next.
ii. Optionally outputs structured data (for example, JSON) so automations can branch on its decisions (e.g., only create new Jira Product Discovery ideas when a piece of feedback represents a genuinely new theme).

In practice, this means Rovo Agents can do far more than answer questions. They can:
• Eliminate repetitive or time‑consuming tasks, such as summarizing meeting notes or grouping hundreds of feedback tickets.
• Solve complex, multi‑step problems, like triaging customer feedback, comparing it to an existing roadmap, and only creating new ideas when needed.
• Improve decision‑making by pulling together context from across your Atlassian and third‑party tools, then presenting it in a way your teams can act on.

By combining instructions, knowledge, skills, and triggers on top of the Teamwork Graph, Rovo agents become the building blocks for reliable, end‑to‑end automation across Atlassian products and beyond.

When to Use Chat, Agents, or Both?

Chat
Chat is best when you need an immediate, ad‑hoc, human‑driven interaction. It's optimized for fast lookups, exploratory questions, clarifications, and one‑off decisions where a human will act on the answer.
• Ideal for quick searches, troubleshooting steps, brainstorming, or clarifying product/process rules on the fly.
• Good when the user expects conversational back‑and‑forth and manual follow‑up (no automatic side effects).
• Low setup cost: no need to configure knowledge scopes, skills, scenarios, or automations.

EXAMPLE:
Ask Rovo Chat, "How do I reset my VPN (Virtual Private Network)?" and instantly receive clear, step‑by‑step instructions or direct links to relevant assets in your knowledge base, so you don't have to search through documentation manually.

Rovo Chat understands common IT support questions and can interpret acronyms like VPN, automatically guiding you to the right troubleshooting steps or support resources.

Agents
Agents are best when work needs to be repeatable, deterministic, multi‑step, or integrated with other systems. They are designed to orchestrate tasks, call skills, and run on schedules or event triggers.
• Use when workflows are 2+ steps, require data aggregation, integration with tools, or must run automatically (scheduled or event‑driven).
• Use when you need structured outputs (e.g., JSON) so automations can branch, loop, and create artifacts deterministically.
• Use when you want a consistent tone/guardrails across multiple related tasks.

EXAMPLE:
By crafting a Rovo Agent to be a feedback triage sidekick, you'll have an AI assistant that continuously scans customer feedback channels (such as support tickets, NPS comments, and community forums), groups related comments into clear themes, checks the existing backlog in JPD (Jira Product Discovery), and automatically creates new idea work items when it finds unmet needs or gaps.

Instead of manually reading, tagging, and de‑duplicating feedback, you can get a prioritized, structured view of what customers are asking for, with direct links back to the original feedback and to the related ideas in Jira Product Discovery (JPD, Atlassian's product for capturing, prioritizing, and managing product ideas).

When to Use Both
There are many cases where Rovo Chat and Agent work together to be most powerful: start with chat for exploration and then transition the validated process to an agent when you need repeatability, automation, or integrations.
• Use chat to prototype prompts, gather examples, and validate the desired output format.
• Once validated, build an agent scenario that uses those instructions, binds knowledge sources, and attaches skills for automation.
• Example workflow: prototype "draft release notes" in chat → convert the prompt to an agent scenario with a trigger + Confluence/Jira skills → schedule it via an automation rule.

DECISION CHECKLIST - "Should I use Rovo Chat or an Agent?"

Is this a one‑time or occasional question? → CHAT
Is the task repeated often or at scale? → AGENT
Does it span multiple steps or systems (Jira, Confluence, third‑party APIs)? → AGENT
Do you need the output in a structured format (JSON) for downstream automation? → AGENT
Do you want it to run automatically on a schedule or event? → AGENT with Jira automations
Do you need exploratory back‑and‑forth or ad hoc human judgment? → CHAT (or hybrid: chat for exploration, agent for production)

If you find yourself repeating the same prompt or process, or if your workflow involves multiple steps, triggers, or integrations, building an agent is the best approach.

Key Considerations for Building Effective Agents

Before you start, clarify the problem you want to solve. Map out the workflow, identify the steps, and look for opportunities to automate or streamline. A focused problem statement and a clear picture of the current process make it much easier to design an agent that delivers reliable value rather than a vague "AI helper."
• Break down complex prompts into manageable scenarios for reliability.
• Define clear instructions, knowledge sources, and required skills for each scenario.
• Use behaviors to set the agent's tone and consistency across scenarios.
• Test and iterate

Finally, make it a point to collaborate with your team since agents can be long‑lived assets that benefit from shared ownership. They can be co‑owned and managed by groups, not just individuals, which means you can distribute responsibility for updates, monitoring, and incident response among team members.

Make sure to document how the agent works, assign clear owners, and encourage teams to contribute new scenarios, examples, and improvements so the agent continues to evolve alongside your workflows.

Best Practices for Agent Design and Prompting

Designing an effective agent starts long before you write the first instruction.

The most successful agents are treated like products: they have a clear purpose, a defined audience, and prompts that are written for reliability, not just creativity. In this section, we'll focus on how to shape your agent's "job description," how to write instructions that are unambiguous and repeatable, and how to use examples, templates, and structured outputs to get consistent results.

Think of these practices as your playbook for turning a powerful underlying model into a dependable virtual teammate that behaves the way your team expects, every time it's invoked.

Define Its Role and Objectives Clearly
Treat this like a job description: what problems is the agent responsible for, what is out of scope, and how will you measure success? A tightly scoped role makes it much easier to design prompts, choose the right data sources, and avoid unexpected behavior.

Write Instructions as If the Agent Has No Prior Context
Be explicit and step‑by‑step. Assume it's someone joining your team on their first day who has never seen your processes before. Spell out the sequence of actions, decision points, and any business rules you'd normally explain to a new hire. The more you remove ambiguity, the more predictable and reliable the agent becomes.

Provide Both Good and Bad Examples
This helps the agent have a framework that can deliver successfully more consistently. Use links to templates or business rules when possible. Just as you'd show a new teammate example tickets, documents, or past work, give the agent concrete samples of what "great" looks like, as well as what to avoid. Include links to Confluence pages, templates, or policy docs and instruct the agent to follow them. These examples serve as a pattern library that the agent can reference, thereby improving quality and consistency across responses.

Use Markdown or Tables for Structured Outputs
Structure is what turns a free‑form answer into something you can reuse and automate. Ask the agent to respond with headings, bullet lists, or fixed table columns so humans can scan quickly and downstream tools can parse results reliably. For more complex workflows, you can even specify simple schemas (for example, named sections or key‑value pairs) that the agent should always follow.

Iterate Based on Real‑World Testing and Feedback
Your first version is just a starting point, not the final product. Watch how people actually use the agent, capture failure cases, and refine the instructions, examples, or knowledge sources over time. Treat each iteration like coaching a teammate: give it clearer guidance, better samples, and updated rules as your processes evolve.

Conversation Starters and Scenario Triggers

While conversation starter examples can help users engage with agents, the focus should be on scenario triggers, which are clear, intent‑driven statements that guide the agent to the right scenario. Think of conversation starters as friendly entry points ("Ask the HR assistant about your benefits") and scenario triggers as the precise cues the agent uses to decide what to do ("Check my PTO balance for this quarter").

Well‑designed scenario triggers reduce ambiguity, improve routing accuracy, and make the agent's behavior more predictable.

Use positive and negative examples to refine triggers. Show the agent (and your team) what a "good" trigger looks like for each scenario, such as a specific, action‑oriented, and tied to a clear outcome, and contrast it with "bad" triggers that are too vague or misaligned.

EXAMPLE:
"Categorize this incoming ticket as incident, service request, or question" is a strong trigger, while "Help with ticket" is not. Over time, you can collect real user queries, label which ones should or shouldn't activate a scenario, and feed those back in as training examples to tighten the mapping.

Avoid using single‑word triggers; instead, provide context‑rich phrases that accurately reflect real user intent. A lone word like "report" or "access" can mean many different things, making it hard for the agent to select the right scenario reliably. Instead, aim for short, natural‑language phrases that encode both action and object, such as "Generate a weekly incident report for my team" or "Request access to the marketing dashboard."

These richer triggers make it easier for the agent to distinguish between similar workflows, reduce misfires, and ensure users quickly land in the experience that actually solves their problem.

Explore Practical Use Cases

Rovo agents are already powering a wide range of workflows, from engineering to HR to product management. They shine wherever work is repetitive, multi‑step, or requires pulling context from multiple tools and turning it into clear, actionable outcomes.

Featured examples include:

Issue Organizer
Automatically review issues in a backlog, group related work, move issues into the right sprints, and assign them to the correct epics or owners. This helps teams keep boards clean and focused without the need for hours of manual grooming.

Release Notes Drafter
Pull details from Jira issues, such as summaries, labels, and fix versions, and turn them into clear, user‑friendly release notes. The agent can propose a first draft that your team can quickly review, edit, and publish to Confluence or share with stakeholders.

Employee Onboarding
Generate tailored onboarding plans that combine HR policies, role‑specific documentation, and team rituals. The agent can assemble checklists, reading lists, and a week‑by‑week plan to help new hires ramp up faster and more consistently.
These are just starting points: once you understand how each use case combines instructions, knowledge, and skills, you can remix them into agents that fit your team's unique workflows.

Craft the Next Great Rovo Agent

Ready to go from zero to hero with Rovo? Start by combining a short, focused learning loop with a small, high‑value build. Learn the core concepts, follow one end‑to‑end example, then ship a simple agent and iterate based on real usage.

Quick Start Project: Build Your First Agent
Build a single, high‑impact agent in 4 steps. Each step is small enough to finish in a day or two.

1: Write a Problem Statement
Write a one‑paragraph problem statement that clearly identifies the user and the specific outcome.

2: Draft a Simple Scenario
Draft a simple scenario with 3–4 behaviors (greet, gather inputs, perform action, confirm).

3: Implement and Test
Implement the scenario in Rovo Studio and run 5 internal tests with colleagues.

4: Release and Iterate
Release to a small pilot group, collect feedback, and iterate.

Begin with a narrowly scoped use case (for example, triaging incoming tickets, summarizing meeting notes, or automating a routine approval).

Narrow scope = faster learning and measurable impact.

Best Practices to Follow
Start simple and measure early
• Keep the first agent to a single primary goal.
• Add telemetry to track usage, success rate, and provide a brief feedback message after each session.
• Use versioned changes so you can roll back quickly.
• Collect one qualitative user quote per week during the pilot to guide prioritization.

Suggested 30/60/90 Day Plan

0–30 Days:
Complete the fundamentals course, watch the video, and post in the hub. Draft your problem statement and scenario.

31–60 Days:
Build the agent in Studio, run tests, and launch a 5–10 user pilot. Collect quantitative and qualitative feedback.

61–90 Days:
Iterate based on feedback, add one additional behavior or knowledge source, and prepare a team rollout plan.

Rovo agents unlock scalable automation when you pair learning with small, real projects. Select one clear problem, follow the steps above, and begin building today to deliver measurable value to your team.

Try Rovo Today

Even though Rovo is still early in its journey, the pattern is already clear:
teams that treat agents like real teammates with clear roles, strong instructions, and tight loops between learning and building see the fastest and most durable impact.

Start small, pick one high‑value workflow, and use the practices in this guide to design an agent that your team can trust and evolve over time.

Translating AI exploration into tangible R&D efficiency relies on rigorous architectural design and scenario accumulation. As an Atlassian Global Platinum Partner, Longzhi provides end-to-end services covering Rovo Agents planning, DevOps scenario customization, cross-toolchain integration, and Agent governance. To obtain a customized AI workflow implementation plan or schedule a demo with our technical architects, contact us today.

Connect SonarQube to Cursor & Claude: Real-time Context for Better AI Code

Dragonsoft DevSecOps — Thu, 23 Apr 2026 03:25:08 +0000

While AI coding agents like Cursor and Claude Code have drastically accelerated the development process, they often operate in a vacuum—lacking the specific architectural boundaries, security standards, and "tribal knowledge" of your unique codebase. This often leads to "AI hallucinations" and costly trial-and-error cycles.
Sonar Context Augmentation is here to change the game. By leveraging the Model Context Protocol (MCP), it injects real-time, verified, and structured insights from SonarQube directly into the AI agent’s reasoning engine. As an authorized partner of Sonar, Dragonsoft is excited to deep dive into this milestone feature, which empowers your team to embrace the Agent-Centric Development Cycle (AC/DC) without sacrificing code quality or security.

On March 3rd, 2026, Sonar launched the closed beta of Sonar Context Augmentation for Enterprise customers. And March 31st, Sonar officially Sonar announced the open beta—expanding access to all SonarQube Cloud Teams and Enterprise plan customers.

Overview

Sonar Context Augmentation enhances AI-assisted code analysis by providing structured, verified context from SonarQube findings to AI agents, giving them accurate, up-to-date information about code quality and security issues.
Rather than relying on LLMs to independently analyze code—where hallucinations and outdated knowledge create risk—Context Augmentation grounds AI responses in Sonar's deterministic analysis output.
This capability enables agentic AI workflows to prioritize and reason about code issues more accurately, improving the quality of AI-generated remediation suggestions and code reviews.
By connecting Sonar's analysis engine to AI agents via MCP (Model Context Protocol), teams can build AI-powered workflows that leverage verified security intelligence without sacrificing accuracy.

AI coding agents like Cursor and Claude Code are changing how we build software, but they often work in a vacuum. They don’t automatically understand your project’s specific rules, architectural boundaries, or code security standards. As a result, they can generate code that works in isolation but fails to integrate cleanly into your broader codebase. This leads to rework, higher costs, and a "trial-and-error" process for software developers.

To address this, Sonar introduced the Agent Centric Development Cycle (AC/DC), a framework built for the age of AI, with four continuous stages: Guide → Generate → Verify → Solve. Sonar announces the beta of Sonar Context Augmentation to help agents in the Guide stage of AC/DC.

What is Sonar Context Augmentation?

Sonar Context Augmentation is a service that injects real-time, deep knowledge from SonarQube directly into your AI agent’s workflow. It uses the SonarQube MCP Server to act as a bridge between your enterprise codebase and your AI coding tools.

By providing this "repo-aware" context, Context Augmentation helps AI coding agents understand the specific environment they are working in before they ever generate a line of code.

How Sonar Context Augmentation works

Sonar Context Augmentation provides the exact, filtered information an AI agent needs to get the job right on the first try:

Dynamic context guidelines: Instead of overwhelming an agent with thousands of rules, Context Augmentation identifies the most relevant coding standards based on what you are asking and the history of the specific files being modified.
Architectural awareness: It gives the agent a structural map of your code, including class hierarchies and function flows, so it respects your intended code architecture and avoids creating technical debt.
Smarter search: Agents can find specific code sections using exact signatures and body patterns rather than simple text matches, leading to more accurate modifications.

Why context matters

When an agent has the right context, the agentic output is more accurate, faster, and carries less risk for long-term architectural drift. Experience increased build pass rates, increased test pass rates, significantly reduced code duplication, and reduced cognitive complexity. All of this matters for achieving the real productivity promise of AIgen code.

Sonar benchmarking also shows that when an agent has the right context, it doesn't just write better code—it works more efficiently. Organizations using Context Augmentation can expect to see reduction in token usage, tool calls, and overall AI operating costs, in particular when working in complex code bases.

By defining the "rules of engagement" upfront, developers spend less time fixing AI-generated code errors and more time shipping high-quality software.

Try it out during our beta

The Sonar Context Augmentation beta is available starting today. To participate, you will need:

SonarQube Cloud Team or Enterprise annual or monthly plan
SonarQube MCP Server
An AI agent like Cursor, GitHub Copilot or Claude Code
Any language project to leverage intelligent guidelines
A Java, C#, Python, JavaScript or TypeScript project to leverage
architectural awareness (intended architecture must be set configured for the project to leverage your intended architecture)

NOTE: Context Augmentation only supports projects using CI-based analysis. Projects using Automatic analysis in SonarQube Cloud will not work with Context Augmentation.

For detailed steps to set up Sonar Context Augmentation see Sonar’s documentation. We hope you will try it out during the beta and explore how agents like Cursor and Claude Code can follow your organization’s specific standards from the first prompt.

Don't Just Generate Code—Engineer It with Precision.

In the era of Generative AI, the difference between "working code" and "enterprise-grade code" lies in the context. Dragonsoft is committed to providing world-class DevSecOps solutions and expertise to help you navigate the complexities of modern software engineering.

Ready to eliminate AI hallucinations and boost your team's productivity with Sonar Context Augmentation?

Whether you need a technical deep dive, a customized MCP setup, or an enterprise-wide AI strategy, our experts at Dragonsoft are here to help.