Paper deep dive

LLM-Augmented Release Intelligence: Automated Change Summarization and Impact Analysis in Cloud-Native CI/CD Pipelines

Happy Bhati

Year: 2026Venue: arXiv preprintArea: cs.SEType: PreprintEmbeddings: 30

Intelligence

Status: succeeded | Model: google/gemini-3.1-flash-lite-preview | Prompt: intel-v1 | Confidence: 96%

Last extracted: 3/22/2026, 5:11:44 AM

Summary

The paper presents an AI-augmented release intelligence framework for cloud-native CI/CD pipelines. It integrates automated commit collection with semantic filtering, structured LLM-based summarization for promotion reports, and static task-pipeline dependency analysis to quantify the blast radius of changes. The framework is implemented within a Kubernetes-native environment using Tekton pipelines and GitHub Actions.

Entities (6)

GitHub Actions · cicd-tool · 100%Kubernetes · container-orchestration · 100%SmartNote · software-tool · 100%Tekton · cicd-framework · 100%VerLog · software-tool · 100%Google Gemini · large-language-model · 95%

Relation Signals (3)

Framework → analyzes → Tekton

confidence 95% · The TaskPipelineAnalyzer is a static analysis component that parses Tekton pipeline definitions.

Framework → integrateswith → GitHub Actions

confidence 95% · The framework is integrated directly into the CI/CD promotion workflow and operates as a post-promotion step triggered by GitHub Actions.

Framework → uses → Google Gemini

confidence 95% · The summarizer uses the Google Gemini API through the google-generativeai Python library.

Cypher Suggestions (0)

No Cypher suggestions yet.

Abstract

Abstract:Cloud-native software delivery platforms orchestrate releases through complex, multi-stage pipelines composed of dozens of independently versioned tasks. When code is promoted between environments -- development to staging, staging to production -- engineering teams need timely, accurate communication about what changed and what downstream components are affected. Manual preparation of such release communication is slow, inconsistent, and particularly error-prone in repositories where a single promotion may bundle contributions from many authors across numerous pipeline tasks. We present a framework for AI-augmented release intelligence that combines three capabilities: (1) automated commit collection with semantic filtering to surface substantive changes while suppressing routine maintenance, (2) structured large language model summarization that produces categorized, stakeholder-oriented promotion reports, and (3) static task-pipeline dependency analysis that maps modified tasks to every pipeline they participate in, quantifying the blast radius of each change. The framework is integrated directly into the CI/CD promotion workflow and operates as a post-promotion step triggered by GitHub Actions. We describe the architecture and implementation within a production Kubernetes-native release platform that manages over sixty Tekton tasks across more than twenty release pipelines. Through concrete walkthrough examples and qualitative comparison with recent tools such as SmartNote and VerLog, we discuss the distinctive requirements of internal promotion communication versus user-facing release notes and identify open challenges for LLM-driven release engineering.

PDF

Open source PDF →Open local PDF →

Trouble viewing inline? Open PDF directly →

Full Text

29,597 characters extracted from source content.

Expand or collapse full text

LLM-Augmented Release Intelligence: Automated Change Summarization and Impact Analysis in Cloud-Native CI/CD Pipelines Happy Bhati Northeastern University bhati.h@northeastern.edu March 2026 Abstract Cloud-native software delivery platforms orchestrate releases through com- plex, multi-stage pipelines composed of dozens of independently versioned tasks. When code is promoted between environments—development to staging, stag- ing to production—engineering teams need timely, accurate communication about what changed and what downstream components are affected. Manual preparation of such release communication is slow, inconsistent, and particu- larly error-prone in repositories where a single promotion may bundle contribu- tions from many authors across numerous pipeline tasks. We present a frame- work for AI-augmented release intelligence that combines three capabilities: (1) automated commit collection with semantic filtering to surface substantive changes while suppressing routine maintenance, (2) structured large language model summarization that produces categorized, stakeholder-oriented promo- tion reports, and (3) static task-pipeline dependency analysis that maps mod- ified tasks to every pipeline they participate in, quantifying the blast radius of each change. The framework is integrated directly into the CI/CD pro- motion workflow and operates as a post-promotion step triggered by GitHub Actions. We describe the architecture and implementation within a production Kubernetes-native release platform that manages over sixty Tekton tasks across more than twenty release pipelines. Through concrete walkthrough examples and qualitative comparison with recent tools such as SmartNote and VerLog, we discuss the distinctive requirements of internal promotion communication versus user-facing release notes and identify open challenges for LLM-driven release engineering. Keywords: release engineering, large language models, CI/CD, change summariza- tion, impact analysis, Tekton, Kubernetes, cloud-native 1 Introduction Modern software organizations increasingly adopt cloud-native delivery platforms that decompose release workflows into composable pipeline stages [4, 2]. In such environments, the path from development to production is not a single event but a sequence of gated promotions, each bundling commits from multiple contributors into a coherent release candidate. A Kubernetes-native platform may maintain sixty 1 arXiv:2603.14619v1 [cs.SE] 15 Mar 2026 arXiv preprint or more reusable pipeline tasks spanning signing, publishing, advisory management, and compliance verification, assembled into twenty or more distinct release pipelines that serve different artifact types—container images, RPM packages, disk images, operator bundles, and more. The complexity of these systems creates a persistent communication challenge. When a release engineer promotes a branch from development to staging, stakeholders across quality engineering, product management, and operations need to understand three things: what changed, why it changed, and what else might be affected. An- swering the first two questions requires reading and synthesizing commit messages, pull request descriptions, and diff statistics—a task that grows tedious as promo- tion batches exceed a handful of commits. Answering the third question demands knowledge of the dependency graph between tasks and pipelines, which is encoded implicitly in YAML definitions scattered across the repository. Prior work on automated release note generation has made significant strides. Smart- Note [1] uses LLMs to produce personalized, user-facing release notes from commits and pull requests. VerLog [3] applies few-shot in-context learning to generate release notes for Android applications. ReleaseEval [7] provides a large-scale benchmark for evaluating language models on this task. However, these approaches target external release notes intended for end users. The problem of internal promotion communica- tion—reporting what moved between deployment environments and which pipeline components are impacted—remains largely unaddressed in the literature. In this paper, we describe a framework for AI-augmented release intelligence that is deployed within a production cloud-native release platform. Our contributions are: 1. A commit collection and semantic filtering pipeline that extracts substantive changes from a promotion batch, suppressing routine maintenance commits (de- pendency bumps, documentation updates, style changes) through pattern-based classification. 2. A structured LLM summarization approach that employs carefully designed prompts to produce consistent, categorized promotion reports with executive sum- maries, feature highlights, and bug-fix sections. 3. A static task-pipeline dependency analyzer that parses Tekton pipeline def- initions to determine every pipeline affected by a given task change, providing an immediate blast-radius assessment. 4. An end-to-end integration with GitHub Actions that triggers report generation as a post-promotion step, delivering results via email with full provenance links. The remainder of this paper is organized as follows. Section 2 provides background on cloud-native release engineering and Tekton pipelines. Section 3 surveys related work. Section 4 details the system design. Section 5 describes implementation decisions. Section 6 presents a case study with concrete examples. Section 7 discusses comparisons, limitations, and threats to validity. Section 8 concludes. 2 arXiv preprint 2 Background 2.1 Cloud-Native Release Engineering Cloud-native platforms orchestrate software delivery through Kubernetes-native con- trollers that watch custom resources and trigger pipeline executions in response to state changes. A typical release flow begins when a Snapshot—an immutable record of built artifacts—is created. A release controller evaluates the snapshot against a ReleasePlan (defining the developer’s intent) and a ReleasePlanAdmission (defin- ing the target namespace’s acceptance criteria), then instantiates a pipeline run in a managed workspace [6]. Enterprise contract verification ensures no policy violations exist before content reaches production. 2.2 Tekton Pipelines and Tasks Tekton [11] is an open-source Kubernetes-native framework for building CI/CD sys- tems. Pipelines are composed of tasks, each of which runs as a Kubernetes pod. Tasks are referenced by pipelines through a resolver mechanism; in the git resolver pattern, a pipeline specifies a repository URL, branch revision, and file path to load the task definition at runtime. This decoupling allows tasks to be versioned independently of the pipelines that consume them. The release platform we study organizes tasks into three categories: managed tasks (production release operations such as signing, registry publishing, and advisory creation), collector tasks (data aggregation from multiple sources), and internal tasks (workflow orchestration within the platform itself). Each task is defined in a YAML file that specifies parameters, step containers, and result declarations. 2.3 Multi-Stage Promotion Model The platform follows a three-branch promotion model: development→ staging → production. Promotions are implemented as branch-level fast-forward pushes controlled by a shell script that enforces two safety invariants: • Staging–production parity: Content cannot be promoted to staging if the staging branch already differs from production, unless explicitly overridden. This prevents accumulation of untested changes. • Minimum soak time: Content must reside in staging for at least six days before promotion to production, ensuring adequate integration testing time. Additionally, the promotion script detects hotfix commits—changes applied directly to the target branch that may not yet exist in the source branch—and blocks promo- tion if the hotfix changes would be lost, unless the operator explicitly overrides. 3 Related Work 3.1 Release Note Generation Moreno et al. [8] pioneered automated release note generation using information re- trieval techniques to extract salient changes from source code. DeepRelease [5] intro- 3 arXiv preprint duced neural models for language-independent release note generation from git logs. More recently, the advent of large language models has transformed this space. SmartNote [1] aggregates code, commit, and pull request information and uses an LLM to produce structured release notes. It introduces commit scoring to prioritize significant changes and supports project-specific customization. VerLog [3] targets Android applications with few-shot in-context learning and multi-granularity infor- mation (fine-grained code modifications alongside high-level artifacts), reporting 18– 21% improvements in precision, recall, and F1 over prior baselines. ReleaseEval [7] provides a benchmark of nearly 95,000 release notes across 3,369 repositories and evaluates models on three task settings with increasing input granularity. These tools address user-facing release notes. Our work targets a complementary problem: internal promotion reports for engineering teams, which require different content (task-pipeline impact analysis, contributor attribution, diff statistics) and different delivery mechanisms (email integrated into CI/CD workflows). 3.2 AI in CI/CD Automation LogSage [12] applies LLMs to CI/CD failure detection and remediation with retrieval-augmented generation, achieving over 98% precision on root cause anal- ysis in a benchmark of 367 GitHub CI/CD failures and processing over one million executions in industrial deployment at ByteDance. AgentDevel [13] reframes self- evolving LLM agents as release engineering artifacts, introducing regression-aware pipelines with flip-centered gating. Our work differs from both: we do not diagnose failures (LogSage) or evolve agents (AgentDevel), but rather generate structured communication artifacts that summa- rize the content and impact of successful promotions. 3.3 Software Change Summarization LLM-based multi-agent approaches have been applied to software document sum- marization. Metagente [9] uses a teacher-student architecture to generate concise summaries of software documentation, demonstrating that multi-agent coordination improves summary quality over single-model approaches. Our summarization com- ponent draws on similar principles—structured prompting with role assignment— but operates on commit metadata and diff statistics rather than prose documenta- tion. 4 System Design 4.1 Architecture Overview The release intelligence framework consists of four components that execute sequen- tially as a post-promotion step within a GitHub Actions workflow. Figure 1 illus- trates the data flow. 4 arXiv preprint Git History Pipeline YAML Files Commit Collector LLM Summarizer Task-Pipeline Analyzer Report Generator Structured Summary Impact Matrix HTML Email Figure 1: Architecture of the release intelligence framework. The commit collec- tor extracts changes from git history; the LLM summarizer produces categorized summaries; the task-pipeline analyzer computes the impact matrix from YAML def- initions; the report generator composes everything into an HTML email. 4.2 Commit Collection and Semantic Filtering The CommitCollector component operates on the git history between the source and target branches of a promotion. For each commit in the range, it extracts: • The full commit hash for provenance tracking • The commit summary (first line) and full message body • Author name and email for attribution • The list of changed file paths • A diff-stat summary (insertions, deletions, files changed) Before passing commits to the summarizer, a semantic filter removes routine com- mits that add no substantive information to a promotion report. The filter classifies commits by matching their summary against a set of conventional commit prefixes: chore:, docs:, test:, ci:, style:, refactor:. It also suppresses commits contain- ing keywords such as “bump,” “dependency update,” “merge,” “revert,” and “work in progress.” This heuristic approach deliberately favors recall (surfacing all meaning- ful changes) over precision (potentially including some borderline commits), as false negatives—missing a significant change—carry higher risk than false positives in a promotion context. 4.3 LLM-Based Change Summarization The filtered commit list is passed to an AISummarizer component that generates a structured, human-readable summary. The summarizer constructs a two-part prompt. 5 arXiv preprint System prompt. The system prompt assigns the LLM the role of a “professional DevOps engineer creating a promotion report” and specifies mandatory output struc- ture: 1. An executive summary (2–3 paragraphs) describing the most significant changes and their business impact. 2. A “New Features & Enhancements” section with bullet points linking each commit to its GitHub URL. 3. A “Bug Fixes & Improvements” section with the same structure. The prompt enforces consistency requirements: every feat() and fix() commit must appear in the output, and the model must produce the same categorization across repeated invocations of the same input. User prompt. The user prompt provides each commit’s metadata in a structured template: summary, author, date, URL, file count, full message, and diff statistics. To manage context window constraints, the prompt includes at most 50 commits. The model is configured with temperature 0.7 and a maximum output length of 2,500 tokens, balancing fluency with determinism. 4.4 Task-Pipeline Dependency Analysis The TaskPipelineAnalyzer is a static analysis component that answers the ques- tion: “Which pipelines are affected by the tasks changed in this promotion?” The analyzer operates in two phases: Phase 1: Extract changed tasks. The analyzer scans the file paths modified by each commit against a regular expression pattern matching the repository’s task directory structure (tasks/<category>/<task-name>/<task-name>.yaml). It pro- duces a deduplicated list of changed tasks, grouped by task name and category, with back-references to the commits that modified each task. Phase 2: Compute pipeline impact. The analyzer walks the pipeline directory, parsing each YAML file as a Tekton Pipeline resource. For every task reference in the pipeline’s spec.tasks and spec.finally blocks, it resolves the referenced task through one of three mechanisms: • Git resolver with path: If the task reference uses the git resolver and specifies a pathInRepo parameter, the analyzer matches this path against the changed task’s file path. • Git resolver with name: If only a task name is specified, the analyzer performs name-based matching. • Direct reference: For string-based task references, the analyzer matches the reference string against task names. The output is a mapping from each changed task to the set of pipelines that reference it, providing an immediate quantification of each change’s blast radius. 6 arXiv preprint 4.5 Report Generation and Delivery The EmailGenerator composes the AI summary, task-pipeline impact matrix, and commit statistics into a professional HTML email. The report includes: • A header indicating the promotion type and date • Aggregate statistics: commit count, unique contributors, total files changed • The LLM-generated summary rendered from Markdown to HTML • A task impact table listing each modified task, its category, the affected pipelines (with links), pipeline count, and the commits that triggered the modification • A footer with repository provenance Delivery is handled by an EmailSender component that supports both authenticated SMTP (for cloud-hosted mail services) and unauthenticated relay (for corporate mail infrastructure). 5 Implementation 5.1 Workflow Integration The framework is implemented as a Python script invoked from a GitHub Actions workflow. The workflow is triggered manually via workflow_dispatch with config- urable inputs: • Promotion type: development-to-staging or staging-to-production • Send email report: Boolean toggle • Additional options: Dry run, Jira ticket updates, infrastructure PR creation, force overrides A critical implementation detail is the commit range capture step. Because the promotion itself is a force push that aligns the target branch with the source, the commit range between branches disappears after promotion. The workflow therefore captures the commit range before the promotion step executes and passes it to the report generator via environment variables. 5.2 LLM Integration The summarizer uses the Google Gemini API through the google-generativeai Python library [10]. We selected the Gemini Flash model variant for its favorable latency-to-quality ratio in summarization tasks. Secrets (API keys, SMTP creden- tials) are managed through file-based secret mounting rather than environment vari- able injection, following the principle of minimizing secret exposure in process listings and log output. 5.3 YAML Pipeline Parsing The task-pipeline analyzer uses PyYAML’s safe_load_all to handle multi- document YAML files, which are common in Tekton pipeline definitions. The ana- 7 arXiv preprint Table 1: Release catalog characteristics. CharacteristicCount Managed tasks (production)60+ Internal tasks10+ Collector tasks5+ Managed pipelines20+ Internal pipelines10+ Reusable step actions5+ Integration test suites20+ Custom resource types managed6 lyzer filters documents by the kind: Pipeline field and traverses both spec.tasks and spec.finally blocks to capture all task references, including those in finally clauses that execute regardless of pipeline success or failure. 5.4 Safety and Observability The report generation step is configured with continue-on-error: true in the workflow definition, ensuring that a failure in report generation does not block the promotion itself. The workflow includes a status-reporting step that distinguishes between successful promotion with successful report, successful promotion with failed report, and failed promotion. All operations are logged with structured messages through Python’s logging module. 6 Case Study We describe the framework’s operation within a production Kubernetes-native re- lease platform. All characteristics reported in this section are derived from the actual codebase and operational configuration. 6.1 System Characteristics Table 1 summarizes the scale of the platform’s release catalog. The platform manages six custom resource types: Release, ReleasePlan, ReleasePlanAdmission, ReleaseServiceConfig, Snapshot, and InternalRequest. Pipelines serve diverse artifact types including container images, FBC (File-Based Catalog) bundles, RPM packages, disk images, and kernel modules, each with dis- tinct signing, publishing, and compliance verification requirements. 6.2 Illustrative Promotion Walkthrough Consider a development-to-staging promotion that includes the following substantive commits (after semantic filtering removes routine maintenance): 1. feat(PROJ-1234): add cosign signing support for FBC releases Modifies tasks/managed/sign-image-cosign/ (1 task file, 2 test files) 8 arXiv preprint 2. fix(PROJ-1235): correct repository publication timeout Modifies tasks/managed/publish-repository/ (1 task file) 3. feat(PROJ-1236): support multi-arch kernel module signing Modifies tasks/managed/sign-kmods/ (1 task file, 3 test files) LLM summary output. The summarizer produces an executive summary iden- tifying this promotion as introducing expanded signing capabilities and a reliability fix, followed by categorized sections: • New Features & Enhancements: Cosign signing for FBC releases (with link to commit); multi-architecture kernel module signing (with link). • Bug Fixes & Improvements: Repository publication timeout correction (with link). Task-pipeline impact analysis output. The analyzer identifies the following impact: Table 2: Task-pipeline impact for the example promotion. Changed Task Affected PipelinesCount sign-image-cosign fbc-release,5 push-to-registry, push-to-external-registry, advisories, rpm-advisories publish-repository push-to-registry,3 push-to-external-registry, fbc-release sign-kmodspush-disk-images-to-cdn 1 This analysis reveals that the cosign signing change has the widest blast radius (five pipelines), making it the highest-priority item for staging validation. The kernel module signing change, by contrast, affects only one pipeline and presents lower risk. 6.3 Commit Filtering Effectiveness In a typical promotion batch, a substantial fraction of commits are routine mainte- nance. Table 3 shows the distribution observed in representative promotions. The filter typically reduces the input to the summarizer by 40–60%, focusing the LLM’s attention on changes with genuine business impact. 6.4 Qualitative Comparison with Related Tools Table 4 compares our framework with SmartNote and VerLog across dimensions relevant to release communication. 9 arXiv preprint Table 3: Commit type distribution in representative promotions. “Substantive” com- mits pass the semantic filter. Commit TypeTypical Share Included feat()20–30%Yes fix()15–25%Yes chore: (dependency bumps)20–30%No docs:, test:, ci:10–20%No Merge / revert commits5–10%No Other (ambiguous prefix)5–15%Yes The primary distinction is the combination of LLM summarization with static de- pendency analysis within a CI/CD workflow context. SmartNote and VerLog pro- duce richer linguistic output—they are optimized for clarity and completeness of user-facing prose—while our system prioritizes actionable engineering intelligence: identifying which pipelines need testing, which contributors to consult, and what the change scope looks like in aggregate. 7 Discussion 7.1 Benefits of Integrated Intelligence Embedding the report generator inside the promotion workflow provides two ad- vantages over standalone tools. First, it operates on the exact commit range being promoted, captured before the branch push alters the git state. Second, it leverages repository-local context—the YAML pipeline definitions, the task directory struc- ture, the commit conventions—that a generic tool would need to be configured to understand. 7.2 LLM Consistency and Prompt Engineering A recurring challenge in LLM-based summarization is output consistency. Given the same set of commits, the model may produce different categorizations or omit borderline changes across runs. Our prompt addresses this with explicit consistency requirements (“ALWAYS include ALL feat() and fix() commits”) and structural con- straints (mandatory sections with exact headings). Temperature 0.7 represents a de- liberate trade-off: lower values produce more deterministic but less natural output, while higher values risk inconsistency. A direction for future work is to introduce semantic deduplication and a verification pass that checks the output against the input commit list. 7.3 Limitations No quantitative accuracy evaluation. We have not conducted a controlled study measuring the factual accuracy or completeness of the LLM-generated sum- maries against human-written baselines. Such an evaluation would require annotated ground truth for a representative set of promotions, which does not currently exist. 10 arXiv preprint Table 4: Qualitative comparison with related approaches. DimensionOursSmartNoteVerLog Target audience Internal engineer- ing teams End users / devel- opers End users Content focusPromotion changes + pipeline impact Release features and fixes Version changelog Impact analysis Statictask- pipeline depen- dency graph NoneNone DeliveryEmail via CI/CD workflow Standalone toolStandalone tool EnvironmentKubernetes / Tek- ton pipelines GitHub reposito- ries Android apps Commit filtering Convention-based semantic filter Commit scoringMulti-granularity Prompt design Role-assigned structured with mandatory sec- tions Project- personalized Few-shot adaptive ReleaseEval [7] provides a benchmark for user-facing release notes; a similar bench- mark for internal promotion reports remains an open contribution. Heuristic filtering. The semantic filter relies on conventional commit prefix matching, which assumes the repository follows conventional commit conventions. Repositories that do not adopt this convention would require filter customization. The filter also makes a binary include/exclude decision; a more nuanced approach might assign relevance scores to borderline commits. Static dependency analysis only. The task-pipeline analyzer identifies syntactic references in YAML definitions but does not perform runtime analysis. A task change that alters its output results may affect downstream tasks in ways the static analyzer cannot detect. Combining static analysis with runtime trace data could provide a more complete impact picture. Single LLM provider. The current implementation is coupled to the Google Gemini API. While the prompt design is provider-agnostic, the summarizer does not support provider failover or cost optimization through model routing. 7.4 Threats to Validity Construct validity. Our case study reports system characteristics and illustra- tive examples rather than controlled experimental measurements. The examples are 11 arXiv preprint representative of actual promotion patterns but were selected to demonstrate the framework’s capabilities. External validity. The framework is designed for and evaluated within a single platform’s release catalog. Generalization to other Tekton-based platforms should be straightforward, as the task-pipeline structure is a Tekton convention. General- ization to non-Tekton CI/CD systems (e.g., Argo Workflows, Jenkins) would require reimplementing the dependency analyzer for the target system’s pipeline definition format. Internal validity. The LLM component introduces non-determinism. We miti- gate this through prompt engineering and temperature control but cannot guarantee identical output across runs. 8 Conclusion We presented a framework for AI-augmented release intelligence that addresses the gap between user-facing release note generation and internal engineering communi- cation needs in cloud-native delivery platforms. By combining LLM-powered change summarization with static task-pipeline dependency analysis and embedding both within the CI/CD promotion workflow, the framework provides release engineers with timely, structured, and actionable promotion reports. The work opens several directions for future research. Developing a benchmark for internal promotion report quality would enable quantitative evaluation of sum- marization approaches in this domain. Extending the dependency analyzer with runtime trace integration could capture transitive impacts invisible to static analy- sis. Exploring multi-model ensembles or verification chains could improve summary consistency without sacrificing naturalness. Finally, broadening the framework to support additional CI/CD platforms beyond Tekton would increase its applicability across the cloud-native ecosystem. References [1] Farbod Daneshyan, Runzhi He, Jianyu Wu, and Minghui Zhou. SmartNote: An LLM-powered, personalised release note generator that just works. arXiv preprint arXiv:2505.17977, 2025. Accepted at FSE 2025. [2] Nicole Forsgren, Jez Humble, and Gene Kim. Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Orga- nizations. IT Revolution, 2018. [3] Jiawei Guo, Haoran Yang, and Haipeng Cai. VerLog: Enhancing release note generation for Android apps using large language models. Proceedings of the ACM SIGSOFT International Symposium on Software Testing and Analysis (ISSTA), 2025. 12 arXiv preprint [4] Jez Humble and David Farley. Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation. Addison-Wesley Professional, 2010. [5] Zhiqiang Jiang, Hui Liu, Zhenyu Niu, Lu Zhang, and Gang Huang. DeepRe- lease: Language-independent release notes generation from Git logs. Empirical Software Engineering, 27(6), 2022. [6] Konflux CI Community. Konflux: An opinionated Kubernetes-native security- first software factory. https://konflux-ci.dev, 2024. Accessed: 2026-03-15. [7] Qianru Meng, Zhaochun Ren, and Joost Visser. ReleaseEval: A benchmark for evaluating language models in automated release note generation. arXiv preprint arXiv:2511.02713, 2025. [8] Laura Moreno, Gabriele Bavota, Massimiliano Di Penta, Rocco Oliveto, An- drian Marcus, and Gerardo Canfora. Automatic generation of release notes. Proceedings of the 22nd ACM SIGSOFT International Symposium on Founda- tions of Software Engineering, pages 484–495, 2014. [9] Duc S. H. Nguyen, Bach G. Truong, Phuong T. Nguyen, Juri Di Rocco, and Davide Di Ruscio. Automated summarization of software documents: An LLM- based multi-agent approach. Automated Software Engineering, 2025. [10] Gemini Team, Rohan Anil, Sebastian Borgeaud, et al. Gemini: A family of highly capable multimodal models, 2024. Google DeepMind Technical Report. [11] The Tekton Authors. Tekton: Cloud-native CI/CD pipelines. https://tekton. dev, 2019. Accessed: 2026-03-15. [12] Weiyuan Xu, Juntao Luo, Tao Huang, Kaixin Sui, Jie Geng, Qijun Ma, Isami Akasaka, Xiaoxue Shi, Jing Tang, and Peng Cai. LogSage: An LLM-based framework for CI/CD failure detection and remediation with industrial valida- tion. arXiv preprint arXiv:2506.03691, 2025. [13] Di Zhang. AgentDevel: Reframing self-evolving LLM agents as release engi- neering. arXiv preprint arXiv:2601.04620, 2026. 13

Instant research discovery