Atlassian¶
Atlassian Engineering blog (atlassian.com/blog/how-we-build). Tier-3
source on the sysdesign-wiki. Much of the blog is product-marketing /
feature-announcement content for Jira / Confluence / Bitbucket /
Rovo — which is filtered out on ingest (see wiki/log.md). When the
blog does go architectural, four axes are in scope:
- Confluence's web-tier performance — React-18 streaming SSR, hydration semantics, edge-proxy buffer-kill; 2026-04-16 streaming-SSR post is the canonical wiki instance.
- Rovo Chat's agent orchestration architecture (Long Horizon) — single-LLM iterative reasoning loop replacing a hierarchical multi-agent orchestrator; flattened tool surface with progressive disclosure via meta-tools; context compaction service; prompt layer ordering for prefix-cache maximisation; child instances for parallel research; adaptive reasoning effort. The 2026-06-18 "Long Horizon" post is the canonical wiki instance.
- Atlassian's ML platform (ML Studio) — unified enterprise-scale ML development platform with composable versioned modules, workflow orchestrator (hot clusters, deterministic caching, nested workflows), and embedded multi-layer compliance (column-level data classification with automatic tag propagation); serves ~120k monthly workflow runs across 100+ ML teams and is the backbone for Rovo Search/Chat, Teamwork Graph, and Confluence AI. The 2026-06-10 ML-platform-architecture post is the canonical wiki instance.
- Atlassian's agentic-AI platform / Rovo Dev ecosystem — Fireworks (the Firecracker-microVM-on-Kubernetes secure execution substrate for AI agents), the Rovo Dev agent itself, Bitbucket Pipelines as automated quality gate for agent PRs, and the agentic-development workflow Atlassian runs internally (dev-shard iteration, AI-written e2e tests, adversarial-review sub-agents, orchestration meta-skills). The 2026-04-24 Rovo-Dev-Driven-Development post is the canonical wiki instance.
- Developer-productivity / CI-reliability at Atlassian-repo scale — Bitbucket Merge Queues defending against semantic merge conflicts at Jira-repo scale (800+ devs, 300+ merges/day, 70+ repos, 30,000+ PRs landed through merge queues). 2026-04-29 merge-queue architecture + outcomes post is the canonical wiki instance.
- Jira Cloud multi-tenant configuration scaling — Jira Optimisation Tools paired with Site Optimiser and the Pre-computation Framework address configuration bloat at Atlassian-tenant-scale (100k+ users per tenant). The 2026-05-14 "Optimisation Tools for Jira" post is the canonical wiki instance, contributing the polymorphic usage tables decision (rejecting per-entity-type tables to avoid "millions of tables across production"), the Initialise → Scan-steps → Finalise batch-framework contract with idempotent + thread-safe + order-agnostic scan-step workers, the utilisation-prioritised refresh strategy (recompute only spaces near ≈70% of cap), the tiered Memcache + DB storage split, and the audit-log-as-rollback v1 contract.
- Jira-as-substrate for AI-agent KTLO automation — the Atlassian Jira engineering team uses Jira's structured custom fields, workflow state machine, and workflow-transition automations as the substrate for delegating KTLO engineering chores to AI agents (likely Rovo Dev). The 2026-06-01 "How We Cut up to 80% of Engineering Chores Using AI Agents in Jira" post is the canonical wiki instance, contributing the work-item-as-agent-prompt framing, the status- transition-triggers-agent-with-custom-system-prompt mechanic, the daily-heuristic- cron-emits-agent-ready-work-items detection layer, the three-tier repo-specific → flag-for-creation → generic skill fallback chain, the per-test-category classify-then-dispatch mechanism, and the [first-pass-investigator
- human-merge-gate](<../concepts/agent-as-first-pass-investigator.md>) operational model. Reported outcomes: ~80% reduction in flaky-test eng hours (~1 engineering week saved per month); 500+ merged PRs in 70 days from stale-flag cleanup on the Jira repo. Composes load-bearingly with the Bitbucket-merge-queue substrate (systems/bitbucket-merge-queues) for the cleanup-throughput economics.
Key systems¶
- systems/atlassian-long-horizon — Atlassian's reasoning-native agent orchestrator powering Rovo Chat. Single LLM, single context, up to 150-iteration reasoning loop. Replaced the hierarchical Hybrid Orchestrator. Flattened tool surface + progressive disclosure + context compaction + child instances + prompt layer ordering for prefix caching + adaptive reasoning.
- systems/rovo-chat — Atlassian's user-facing AI assistant product; cross-product research and actions across Jira, Confluence, Bitbucket, JSM, Compass, and third-party connectors. Powered by Long Horizon.
- systems/atlassian-ml-studio — Atlassian's unified enterprise-scale ML development platform; three architectural pillars (composable versioned modules, workflow orchestrator with hot clusters + deterministic caching, embedded multi-layer compliance); serves ~120k monthly workflow runs across 100+ ML teams; backbone for Rovo Search/Chat, Teamwork Graph, Confluence AI.
- systems/atlassian-jira-optimisation-tools — admin experiences + async backend workflows that compute per-space configuration-usage reports and apply bulk remediation actions (dissociate unused fields, split field configuration schemes, clean up unused work types). Powers Jira's response to the post-100k-user configuration-bloat problem.
- systems/atlassian-jira-site-optimiser — admin dashboard surface that surfaces "configuration issues and improvement opportunities across spaces"; the human-facing entry point to the Optimisation Tools.
- systems/atlassian-precomputation-framework — async batch-reporting platform on Atlassian's internal workflow orchestration engine; Initialise → Scan-steps → Finalise three-phase contract; idempotent + thread-safe
- order-agnostic scan-step worker discipline; tiered Memcache + relational-DB storage with polymorphic usage tables. Canonical first-party wiki instance of patterns/asynchronous-precomputed-report-batch-framework.
- systems/jira — host system / multi-tenant SaaS; recently extended for Jira Cloud limits + guardrails + optimisation-tools coverage; also the substrate for AI-agent KTLO automation via custom-fields + workflow-transition agent integration.
- systems/atlassian-teamwork-graph — Atlassian's cross-product knowledge graph (Jira + Confluence + Bitbucket
- …); named in the 2026-06-01 KTLO-AI-agents post as one of the three context substrates the agent reads (alongside the work item itself and the workflow-automation system prompt). Stub page; deeper architectural decomposition deferred to a future ingest.
- systems/atlassian-fireworks — Firecracker-microVM orchestrator on Kubernetes; the "secure execution engine behind Atlassian's AI agent infrastructure." 100ms warm starts, live migration, eBPF network policy, shared volumes, snapshot filesystem restore, sidecar sandboxes; internal scheduler + autoscaler + Raft persistence + Envoy ingress. "Built in four weeks, entirely by LLMs."
- systems/rovo-dev — Atlassian's AI development agent; deep
Bitbucket + Bitbucket Pipelines integration; supports
addressable skills (including multi-step orchestration
meta-skills), prompt shortcuts like
!review-prfor adversarial sub-agent review, and PR-bot participation on the PR itself. - systems/bitbucket-pipelines — Atlassian's CI/CD product;
serves both as the automated quality gate Rovo Dev reads
pipeline output from and as the execution substrate for
the merge-queue pipeline (via the
merge-queues:section inbitbucket-pipelines.yml). - systems/bitbucket-merge-queues — Atlassian's pre-merge validation queue for Bitbucket Cloud. 70+ repos in production across Jira, Rovo, Trello; 30,000+ PRs landed via merge queues since Beta; canonical first-party validate-against- future-state-of-main instance on the wiki.
- systems/bitbucket — host of the repo, PRs, merge-queue admin surface, and Rovo Dev's operating surface.
- systems/confluence-streaming-ssr — Confluence's React-18
streaming SSR pipeline;
renderToPipeableStream+ Suspense + NodeJS-transform state injection; ~40% FCP win.
Key patterns / concepts¶
Rovo Chat Long Horizon architecture (2026-06-18 axis)¶
- concepts/progressive-tool-disclosure — exposing tool schemas on demand via meta-tools rather than loading all upfront; avoids per-product schema tax while keeping tools available.
- concepts/context-compaction — trimming/summarising older tool outputs before each LLM call to keep long reasoning loops within token limits.
- concepts/adaptive-reasoning-effort — calibrating reasoning depth to query complexity; simple lookups get fast answers, multi-step research gets deep planning.
- concepts/prompt-prefix-caching — ordering prompt layers from stable-to-volatile to maximise LLM provider prefix-cache reuse.
- concepts/agent-observability-trace-tree — hierarchical trace trees for debugging long-running LLM agent loops.
- patterns/single-loop-agent-orchestration — one LLM, one context, one iterative loop replacing multi-agent hierarchy.
- patterns/flattened-tool-architecture — collapsing per-product sub-agents into typed namespaced actions called directly.
- patterns/progressive-tool-disclosure-meta-tools — two meta-tools per namespace (get_schema + invoke_tool) for on-demand schema loading.
- patterns/prompt-layer-ordering-for-cache-hits — assembling prompts from most-stable to most-volatile for cache maximisation.
- patterns/context-compaction-service — dedicated service trimming/summarising older context before each LLM call.
Jira-as-substrate for AI-agent KTLO automation (2026-06-01 axis)¶
- concepts/ktlo-engineering-chores — first-class wiki home for the "keeping the lights on" work-category framing. Atlassian names the canonical KTLO category list (flag cleanup, flaky tests, vulnerabilities, a11y fixes, long-tail bugs) and the pattern-recognition prerequisite argument for delegation: "That pattern recognition is what makes delegation to agents possible."
- concepts/work-item-as-agent-prompt — Jira work item treated as a structured agent prompt; structured custom fields carry per-task brief; workflow state machine is the orchestration layer; transition automation carries the per-procedure system prompt; cross-product Teamwork Graph supplements with shared cross-task context.
- concepts/agent-as-first-pass-investigator — operational model: agent does investigation + diagnosis + draft PR; human reviews + merges; "hours of manual investigation can now become minutes of review." Triage-vs-fix split with bounded false-positive comment-only exit.
- patterns/jira-status-transition-triggers-agent-workflow — Jira-Cloud-native mechanic: status change triggers agent run with custom system prompt encoded into the transition automation. Single-source-of-truth lifecycle preserved on the work item.
- patterns/heuristic-cron-emits-agent-work-items — daily cron scans codebase + cross-references compliance / experiment / release-track state, emits one Jira work item per stale flag with full pre-resolved structured fields (flag name + type + repo + paths + line numbers + desired final state). Detection layer for the agentic remediation pipeline.
- patterns/agent-skill-with-fallback-chain — three-tier fallback for per-codebase variability: repo-specific cleanup skill → flag the repo as needing one + provide owner instructions → generic cleanup skill. The middle tier converts "no skill exists" into operational signal.
- patterns/test-category-classifier-then-specialist-skill — for flaky-test triage / fix: classify the test as unit / integration / visual regression, dispatch to the matching specialist skill. CPU-throttled-loop reproduction discipline. Sibling skill-dispatch axis to the per-codebase fallback chain.
- Reported outcomes: ~80% reduction in flaky-test eng hours (~1 engineering week saved per month); 500+ merged PRs in 70 days from stale-flag cleanup on the Jira repo alone.
Jira Cloud multi-tenant configuration scaling (2026-05-14 axis)¶
- concepts/configuration-bloat — first-class wiki home for the multi-tenant SaaS failure mode where per-tenant configuration entities (fields / work types / schemes / workflows / screens) accumulate over time, slow read paths, and push tenants past hard caps.
- concepts/polymorphic-usage-tables-multi-tenant —
application-schema-layer decision to use a small fixed
set of generic tables keyed by
(tenant, entity_type, entity_id, …)rather than one dedicated table per entity type. Rejected alternative would create "millions of tables across production" in Jira's multi-tenant architecture. Application-layer cousin of catalog bloat. - concepts/utilization-prioritised-refresh-strategy — recompute pre-computed reports only for tenants near limits (≈70% utilisation); accept acknowledged staleness elsewhere; surface staleness state + on-demand refresh.
- concepts/idempotent-thread-safe-scan-step — the load-bearing scan-step worker contract for orchestrator-led batch processing; the trio together enables the framework to "parallelise and retry without coordination."
- patterns/asynchronous-precomputed-report-batch-framework — three-phase Initialise → Scan-steps → Finalise framework; canonical first-party wiki instance via Atlassian's Pre-computation Framework.
- patterns/polymorphic-usage-tables-for-multi-tenant-scale — the multi-tenant DB-design pattern for the persistent storage tier.
- patterns/prioritised-refresh-by-utilisation-threshold — the refresh-policy lever that controls compute budget; paired with last-refresh-timestamp + on-demand-refresh UX commitments.
- patterns/tiered-state-management-memcache-plus-db — Memcached for short-lived intra-job state; relational DB for persistent reports.
- patterns/audit-log-as-rollback-substrate — v1 recoverability contract for destructive bulk operations: targeted opinionated actions + comprehensive audit logging + manual rollback (with future assisted / guided-rollback layers).
Agentic development (2026-04-24 Fireworks axis)¶
- concepts/hardware-isolated-microvm-on-kubernetes — the substrate shape Fireworks productises internally; structurally adjacent to systems/fly-kubernetes.
- concepts/black-box-validation — "I test outputs, not read code." The process claim that makes "four weeks, entirely by LLMs" plausible.
- concepts/ai-writes-own-tests — agent authors both production code and the e2e test suite; the test suite is the primary correctness proof.
- concepts/agent-orchestration-skill — skills as multi-step procedural runbooks, not single-tool bindings. Fireworks team has a meta-workflow skill for end-to-end development plus a narrower dev-shard-lifecycle skill.
- concepts/adversarial-review-persona — sub-agent with an adversarial prompt that red-teams PRs before human review.
- concepts/agentic-development-loop — the closed LLM → execution-environment → feedback loop Rovo Dev implements.
- concepts/blast-radius — five-lever safety net (CI, sharding, RBAC+JIT, progressive rollout, AI-written e2e tests).
- patterns/ai-writes-own-e2e-tests — agent authors the e2e suite, deploys to a dev shard, loops on failures until green.
- patterns/dev-shard-iteration-loop — every feature deploys to a per-developer isolated dev shard on a real K8s cluster.
- patterns/adversarial-review-subagent —
!review-prspins up an independent adversarial reviewer; canonical implementation. - patterns/agent-orchestration-meta-skill — codebase-specific multi-step procedural skill.
- patterns/pre-human-agent-review — three-tier (adversarial sub-agent → CI gate → human architect) review stack.
- patterns/three-workspace-parallel-agent-workflow — three checkouts, three branches, three agents, one human dispatcher.
- patterns/ci-as-agent-quality-gate — agent reads Bitbucket Pipelines output and addresses failures before requesting review.
- patterns/rbac-jit-as-agent-safety-net — access-control lever in the five-lever safety net.
Web-tier performance (2026-04-16 Confluence axis)¶
- concepts/streaming-ssr — emit HTML progressively at Suspense boundaries
- concepts/react-hydration — reuse server markup on the client without re-rendering; ordering constraints with streaming
- concepts/head-of-line-buffering — nginx
proxy_bufferingand compression middleware as streaming-hostile defaults - patterns/suspense-boundary — progressive-rendering unit
- patterns/asset-preload-prediction — feedback-loop bundle preload to unblock hydration
- patterns/ab-test-rollout — per-percentile A/B rollout with guardrail metrics
Developer-productivity / CI-reliability (2026-04-29 Bitbucket Merge Queues axis)¶
- concepts/merge-queue — queue accepted PRs, validate against the target branch's future state, merge or eject. Atlassian is the canonical first-party wiki instance across 70+ repos.
- concepts/semantic-merge-conflict — the load-bearing failure mode merge queues defend against. Jira-repo disclosure: 7–10% of CI failures pre-queue, near zero post-queue.
- concepts/build-reliability — developer-satisfaction on build reliability lifted 70% → 82% on Jira after merge-queue rollout.
- concepts/ci-reliability — target-branch CI-reliability as the load-bearing metric the merge-queue pattern optimises.
- concepts/trunk-based-development — the branching model
merge queues defend (Jira: single
main, 800+ devs, 300+ merges/day). - concepts/developer-velocity — the composite outcome metric Atlassian uses to motivate the merge-queue investment.
- patterns/validate-against-future-state-of-main — the
canonical architectural pattern. Temporary
merge-queue-*branch + dedicated merge-queue pipeline + merge-or-eject. - patterns/eject-failing-pr-keep-queue-running — the failure-recovery discipline that keeps the queue throughput stable. Failed build ejects the PR, not the queue.
- patterns/parent-child-pipelines-for-ci-parallelism — Jira's merge-queue pipeline fans out to three parallel parent-child pipelines, one per product distribution.
Recent articles¶
- 2026-06-18 — sources/2026-06-18-atlassian-long-horizon-reasoning-engine (Long Horizon: How Atlassian Built a Reasoning Engine for Complex AI Tasks — first-party architectural overview of Rovo Chat's Long Horizon reasoning engine. Replaces the hierarchical Hybrid Orchestrator (per-product sub-agents) with a single-LLM, single-context, 150-iteration reasoning loop. Key architectural decisions: (1) flattened tool surface — every product's tools as typed namespaced actions called directly; (2) progressive disclosure via two meta-tools per namespace (get_schema + invoke); (3) context compaction service trimming older outputs with on-demand retrieval; (4) prompt layer ordering (stable-to-volatile) for prefix-cache maximisation; (5) child instances for parallel wide-task decomposition. Production results: +8.5% offline accuracy, +23% task completion (Confluence), −37% perceived latency. Canonical wiki instance of systems/atlassian-long-horizon, systems/rovo-chat, concepts/progressive-tool-disclosure, concepts/context-compaction, concepts/adaptive-reasoning-effort, concepts/prompt-prefix-caching, concepts/agent-observability-trace-tree, patterns/single-loop-agent-orchestration, patterns/flattened-tool-architecture, patterns/progressive-tool-disclosure-meta-tools, patterns/prompt-layer-ordering-for-cache-hits, patterns/context-compaction-service. Caveats: no cost/token-usage numbers; compaction heuristics unspecified; adaptive reasoning mechanism undisclosed; no tool-selection accuracy empirical evidence for flattened surface.)
- 2026-06-10 — sources/2026-06-10-atlassian-architecting-scalable-ml-platforms (Architecting Scalable ML Platforms: The Integrated Infrastructure and Acceleration Behind Rovo — first-party architectural overview of ML Studio, Atlassian's unified enterprise-scale ML development platform. Three architectural pillars: (1) composable reusable ML modules as versioned artifacts (2,000+ modules, 200k+ monthly iterations, <30s local builds); (2) workflow orchestrator with hot clusters, deterministic caching (~80% of workflows, 1,000+ hours/month saved), nested/joined workflows, CRON scheduling (~120k monthly runs, 100+ ML teams); (3) embedded multi-layer compliance (user identity → domain-level → column-level classification with automatic tag propagation, 900k+ governed datasets). Integration layer connects experiment tracking, central feature store, model registry, ML Lens monitoring, and serving platform. Serves models to 5M+ monthly active Rovo users. Canonical first-party wiki instance of systems/atlassian-ml-studio, concepts/ml-platform-architecture, concepts/workflow-orchestration, concepts/composable-ml-modules, concepts/column-level-access-control, concepts/automatic-task-caching, concepts/hot-cluster-reuse, concepts/ml-governance-at-scale, patterns/module-as-versioned-artifact, patterns/hot-cluster-for-iterative-ml, patterns/deterministic-task-caching, patterns/column-level-classification-propagation, patterns/nested-composable-workflows, patterns/local-dev-loop-with-remote-parity. Caveats: no failure-handling / retry semantics; no cluster autoscaling or cost-management details; no GPU topology specifics; caching correctness guarantees unspecified.)
- 2026-06-01 — sources/2026-06-01-atlassian-how-we-cut-up-to-80-of-engineering-chores-using-ai-agents-in (How We Cut up to 80% of Engineering "Chores" Using AI Agents in Jira — first-party Jira-engineering-team post on using AI agents to automate KTLO ("keeping the lights on") maintenance work. Canonicalises the KTLO engineering-chores category list (flag cleanup, flaky tests, vulnerabilities, a11y fixes, long-tail bugs) and the pattern-recognition-as-prerequisite argument for delegation: "Our team has spent years fixing these exact categories of issues. That pattern recognition is what makes delegation to agents possible." First wiki articulation of concepts/work-item-as-agent-prompt — Jira work item as structured agent prompt (custom fields = task brief; workflow state machine = orchestration; transition automation = custom system prompt; Teamwork Graph = cross-product context). Two production examples on the Jira repo: (1) flaky-test triage and fix with a test-category classifier dispatching to unit / integration / visual-regression specialist skills (patterns/test-category-classifier-then-specialist-skill) and CPU-throttled-loop reproduction; (2) stale feature flag cleanup via daily heuristic cron emitting fully-pre-resolved Jira work items (patterns/heuristic-cron-emits-agent-work-items) routed through Jira-status-transition-triggered agent runs (patterns/jira-status-transition-triggers-agent-workflow) using a three-tier repo-specific → flag-for-creation → generic skill fallback chain (patterns/agent-skill-with-fallback-chain). Operational model is agent does first pass, human does merge gate: agent does investigation + diagnosis + draft PR; "hours of manual investigation can now become minutes of review." Reported outcomes: ~80% reduction in flaky-test eng hours; ~1 engineering week saved per month; 500+ merged PRs in 70 days from stale-flag cleanup on Jira alone (~7 PRs/day on a single KTLO category). Composes load-bearingly with Bitbucket Merge Queues — the throughput claim only works because the merge queue prevents semantic-merge-conflicts that would otherwise compound from agent-driven PR volume. New systems (1): systems/atlassian-teamwork-graph (stub). New concepts (3): concepts/ktlo-engineering-chores, concepts/work-item-as-agent-prompt, concepts/agent-as-first-pass-investigator. New patterns (4): patterns/jira-status-transition-triggers-agent-workflow, patterns/heuristic-cron-emits-agent-work-items, patterns/agent-skill-with-fallback-chain, patterns/test-category-classifier-then-specialist-skill. Existing pages extended: concepts/flaky-test (KTLO-automation framing added), concepts/feature-flag (stale-flag-cleanup-as-KTLO axis added), concepts/agent-orchestration-skill (per-codebase-variability axis + skill-fallback chain), concepts/agentic-development-loop (KTLO axis as third source instance), patterns/agentic-pr-triage (Jira-substrate sibling), systems/jira (third altitude: workflow-substrate-for-agents), systems/rovo-dev (KTLO-automation use case). Source post does not explicitly name Rovo Dev as the agent; the integration surface is Atlassian's documented Add an agent to workflow transitions feature, which aligns with Rovo Dev. Caveats: no model / cost / token disclosure; no false-positive escape rate; no before/after PR-quality comparison; no agent-stuck recovery story; Teamwork-Graph access protocol / schema undisclosed.)
- 2026-05-14 — sources/2026-05-14-atlassian-optimisation-tools-for-jira-reducing-configuration-bloat (Optimisation Tools for Jira: Reducing Configuration Bloat and Enhancing Performance — first-party architectural retrospective on Jira Cloud's response to multi-tenant configuration-bloat at 100k+-user scale. Names Jira's per-space limits (700 fields / 150 work types / 20,000 field options / 50 issue security levels / 50 grants), the two-phase reporting+remediation tool model, and three load-bearing architectural decisions: (a) the Pre-computation Framework with Initialise → Scan-steps → Finalise three-phase contract on top of Atlassian's internal workflow orchestrator, with scan-step workers required to be idempotent + thread-safe + order-agnostic so the orchestrator parallelises and retries without coordination; (b) polymorphic usage tables — application-schema-layer decision to use a small set of generic tables instead of one table per entity type, to avoid creating "millions of tables across production" in Jira's multi-tenant architecture, paired with Memcached for short-lived intra-job state under the tiered Memcache+DB storage split; (c) utilisation-prioritised refresh at ≈70% threshold rather than fixed-schedule recomputation, with last-refresh-timestamp + on-demand-refresh as the staleness UX commitments. Plus audit-log-as-rollback v1 contract: targeted opinionated bulk actions + audit log + manual rollback, with assisted-rollback already shipping and guided in-product rollback planned. Outcome numbers: tens of millions of unused fields and work types removed; some customers streamlining hundreds of thousands of fields and work types in a single day; vast majority of tenants kept within limits including largest enterprise customers. Canonical first-party wiki instance of patterns/asynchronous-precomputed-report-batch-framework, patterns/polymorphic-usage-tables-for-multi-tenant-scale, patterns/prioritised-refresh-by-utilisation-threshold, patterns/tiered-state-management-memcache-plus-db, and patterns/audit-log-as-rollback-substrate; first-class wiki home for concepts/configuration-bloat, concepts/polymorphic-usage-tables-multi-tenant, concepts/utilization-prioritised-refresh-strategy, and concepts/idempotent-thread-safe-scan-step.)
- 2026-04-29 — sources/2026-04-29-atlassian-inside-atlassians-merge-queues
(Inside Atlassian's Merge Queues: how we ship faster with fewer
incidents — first-party architecture + production-outcomes post
for Bitbucket Merge Queues.
70+ repos in production (Jira, Rovo, Trello, others);
30,000+ PRs landed through merge queues since Beta last quarter.
Jira-repo scale disclosure: 800+ devs, 300+ merges/day;
semantic-merge-conflict-caused CI failures 7–10% → near zero;
incidents 3–5/week → rare edge cases; build time 40 min → 35
min; developer-satisfaction on build reliability 70% → 82%.
Mechanism: temporary
bitbucket-merge-queue-*branch + dedicated merge-queue pipeline defined viamerge-queues:block inbitbucket-pipelines.yml+ merge-commit strategy + build-concurrency = 14 + three parallel parent-child pipelines; failed builds eject the PR, not the queue. Canonical wiki instance of patterns/validate-against-future-state-of-main and patterns/eject-failing-pr-keep-queue-running; first-class name for concepts/semantic-merge-conflict and concepts/merge-queue on the wiki. Supersedes the 2026-04-16 open-beta launch post skip — this is the first-party architectural follow-up with real scale numbers.) - 2026-04-24 — sources/2026-04-24-atlassian-rovo-dev-driven-development
(Rovo Dev Driven Development — how Atlassian's Fireworks team
built a Firecracker-µVM-on-Kubernetes secure execution engine
in four weeks using AI agents end-to-end; 100ms warm starts,
live migration, eBPF policy, Raft-backed scheduler, Envoy
ingress; three-workspace parallel-agent workflow, AI-written
e2e tests, adversarial
!review-prsub-agent, orchestration meta-skill, dev-shard iteration on shared AWS scms K8s cluster; five-lever safety net: CI + sharding + RBAC/JIT + canary + AI-written e2e tests; "main deploy to dev without PRGB" as the load-bearing team-level process commitment.) - 2026-04-16 — sources/2026-04-16-atlassian-streaming-ssr-confluence (React 18 streaming SSR in Confluence: ~40% FCP win; NodeJS transform pipeline sequences state-before-markup per chunk; fixes intermediate-proxy buffering, buffer-mode regex cost, and React-18 context/hydration re-render bug)
Skipped (logged)¶
- 2026-06-01 — The AI-native SDLC is paying off: 19% more PRs and 2-3 hours saved per developer per week (Tier-3 Rovo Dev productivity-measurement marketing post; quasi-experimental statistics on 3,400 repos + 6,200-developer survey; no distributed-systems internals, no scaling trade-offs, no infrastructure architecture, no production incidents — body is ~50% measurement framework + statistics tables, ~30% outcome tables, ~20% explicit Rovo Dev rollout-recommendation product pitch)
- 2026-06-01 — From alert noise to action: how 24 Hour Fitness transformed IT Ops with JSM (Tier-3 customer-case-study product PR for Atlassian Service Collection)
- 2026-05-14 — Inside Reddit's IT playbook: Building for scale and AI-readiness (Atlassian customer-success / webinar-recap; corporate IT modernization narrative + product pitch, zero architectural content)
- 2026-05-13 — 3 ways AI alert grouping is transforming on-call engineering (Jira Service Management AIOps product PR; listicle format)
- 2026-04-16 — Enhancing Developer Workflow with Rovo Dev and Notifications (product PR)
- 2026-04-16 — Merge Queues for Bitbucket Cloud, now in open beta (product PR — superseded by the 2026-04-29 first-party architectural follow-up which is ingested as sources/2026-04-29-atlassian-inside-atlassians-merge-queues)
- 2026-04-16 — Rovo Dev in Frontend Platform Engineering (AI-agent codemod tooling)
Related¶
- systems/atlassian-jira-optimisation-tools
- systems/atlassian-jira-site-optimiser
- systems/atlassian-precomputation-framework
- systems/jira
- systems/atlassian-fireworks
- systems/rovo-dev
- systems/bitbucket-pipelines
- systems/bitbucket-merge-queues
- systems/bitbucket
- systems/confluence-streaming-ssr
- systems/firecracker
- systems/kubernetes
- systems/envoy
- concepts/configuration-bloat
- concepts/polymorphic-usage-tables-multi-tenant
- concepts/utilization-prioritised-refresh-strategy
- concepts/idempotent-thread-safe-scan-step
- concepts/catalog-bloat-multi-tenant
- concepts/hardware-isolated-microvm-on-kubernetes
- concepts/black-box-validation
- concepts/ai-writes-own-tests
- concepts/agent-orchestration-skill
- concepts/adversarial-review-persona
- concepts/agentic-development-loop
- concepts/streaming-ssr
- concepts/react-hydration
- concepts/blast-radius
- concepts/merge-queue
- concepts/semantic-merge-conflict
- concepts/build-reliability
- concepts/ci-reliability
- concepts/trunk-based-development
- concepts/developer-velocity
- patterns/asynchronous-precomputed-report-batch-framework
- patterns/polymorphic-usage-tables-for-multi-tenant-scale
- patterns/prioritised-refresh-by-utilisation-threshold
- patterns/tiered-state-management-memcache-plus-db
- patterns/audit-log-as-rollback-substrate
- patterns/ai-writes-own-e2e-tests
- patterns/dev-shard-iteration-loop
- patterns/adversarial-review-subagent
- patterns/agent-orchestration-meta-skill
- patterns/pre-human-agent-review
- patterns/three-workspace-parallel-agent-workflow
- patterns/ci-as-agent-quality-gate
- patterns/rbac-jit-as-agent-safety-net
- patterns/validate-against-future-state-of-main
- patterns/eject-failing-pr-keep-queue-running
- patterns/parent-child-pipelines-for-ci-parallelism
- systems/atlassian-teamwork-graph
- concepts/ktlo-engineering-chores
- concepts/work-item-as-agent-prompt
- concepts/agent-as-first-pass-investigator
- patterns/jira-status-transition-triggers-agent-workflow
- patterns/heuristic-cron-emits-agent-work-items
- patterns/agent-skill-with-fallback-chain
- patterns/test-category-classifier-then-specialist-skill
- systems/atlassian-ml-studio
- systems/atlassian-long-horizon
- systems/rovo-chat
- concepts/ml-platform-architecture
- concepts/workflow-orchestration
- concepts/composable-ml-modules
- concepts/column-level-access-control
- concepts/automatic-task-caching
- concepts/hot-cluster-reuse
- concepts/ml-governance-at-scale
- patterns/module-as-versioned-artifact
- patterns/hot-cluster-for-iterative-ml
- patterns/deterministic-task-caching
- patterns/column-level-classification-propagation
- patterns/nested-composable-workflows
- patterns/local-dev-loop-with-remote-parity
- concepts/progressive-tool-disclosure
- concepts/context-compaction
- concepts/adaptive-reasoning-effort
- concepts/prompt-prefix-caching
- concepts/agent-observability-trace-tree
- patterns/single-loop-agent-orchestration
- patterns/flattened-tool-architecture
- patterns/progressive-tool-disclosure-meta-tools
- patterns/prompt-layer-ordering-for-cache-hits
- patterns/context-compaction-service