release-management

3 posts

toss

While Others Test Toss, We Build the Way to Test. (opens in new tab)

Every week, Toss releases a new version containing roughly 300–400 code changes, making quality assurance essential to protecting users from broken critical features. The QA Platform team combines smoke tests, regression testing, release monitoring, automation, and AI-assisted tools to make releases reliable and efficient. Its central lesson is that teams often want QA work handled responsibly—not merely more tools to operate themselves—so the team is shifting toward directly owning more of the testing process. ## Weekly Release Quality - QA begins when a Release Candidate is available. - **Toss Doctor** runs smoke tests covering core flows such as login through account deletion. - A pull-request analyzer identifies changed areas, potential impact, bug risk, and testing priorities. - **Toss Checker** performs regression testing to ensure new changes have not damaged stable functionality. - After release, the team monitors crash metrics and decides whether an immediate hotfix is necessary or whether a safer fix can wait for the next release. - Custom dashboards track crashes and hotfixes, including causes and prevention measures. - The team also supports product groups starting QA, improves internal tools, and helps establish organization-wide QA processes. ## Defining Toss’s Quality Standard The team’s goal is to go beyond basic testing and establish consistent quality standards across Toss. - **Reliable releases every time:** Quality must remain dependable week after week, not just during individual successful launches. - **High-quality testing:** The focus is on finding defects that could become real incidents, rather than simply increasing test volume. - **Efficient quality assurance:** Manual repetition alone cannot keep pace with the company’s release speed, so automation and sustainable workflows are necessary. - AI is intended to handle suitable decisions and repetitive work, allowing people to focus on areas requiring human judgment. ## Building the Tossion Platform Commercial tools did not provide enough flexibility for Toss’s release pace and evolving AI experiments, so the team built its own platform, **Tossion**. - Tossion replaced TestRail and brought test-case creation, execution, and result tracking into one system. - Multiple bots were consolidated into **Toss Butler**, optimized for the team’s workflow. - **PRCheck** analyzes pull requests and highlights where testers should focus. - **tcgen** uses PRDs, design documents, and surrounding context to generate initial test cases for review. - An automation testing platform displays manual and automated test results together. - **Crash Trend** tracks crash patterns using metrics tailored to Toss. - A hotfix dashboard categorizes causes and records measures intended to prevent recurrence. - These tools are connected by one objective: handling the growing volume of weekly changes more effectively. ## Learning What Teams Really Need The team initially assumed that making test-case creation easier would encourage more people to test. However, tcgen received less adoption than expected. - Users did not necessarily want better tools for doing QA themselves. - What they really wanted was for someone to perform testing quickly and accurately while taking responsibility for its quality. - Providing a tool could feel less like removing work and more like assigning a new task. - As a result, the team shifted toward directly handling more testing and pursuing tenfold efficiency without transferring responsibility to product teams. ## Staying Flexible as AI Evolves AI has solved many problems but has also made long-term planning difficult. - Initial hypotheses may be only partly correct, as the tcgen experience demonstrated. - Tools and methods can become outdated rapidly as AI capabilities change. - The team discarded an API testing tool, **API Labs**, after only eight hours when it proved misaligned with its goals. - Tossion, Toss Doctor, Toss Checker, and internal skills are designed with replacement in mind rather than as permanent, finished systems. - AI can accelerate tool creation, but people must still define what quality means, establish priorities, and decide what standards must be preserved. The QA Platform team’s ongoing approach is to build adaptable systems, learn from actual usage, and remain willing to replace anything that no longer serves its purpose. Its upcoming work will explore Tossion, the release-gate tools, regression automation, and intelligent AI bots in greater detail.

aws

AWS DevOps Agent adds release management capabilities to assess code changes before production (preview) | Amazon Web Services (opens in new tab)

AWS DevOps Agent’s new preview release-management features extend its role from post-deployment incident response to pre-production review and testing. It evaluates code changes against production requirements, organizational standards, dependency risks, and access-control practices, then performs targeted tests in isolated or production-like environments. The goal is to help teams safely handle the growing volume of AI-generated code without sacrificing review quality or delivery speed. ## Release Readiness Reviews - Reviews changes for: - Production and dependency risks - Cross-repository impacts - AWS access-control changes and Well-Architected best practices - Compliance with organization-specific standards - Teams can provide standards in plain English, such as: - Encryption and network-access rules - Logging and observability requirements - Sensitive-data classification practices - Without custom instructions, the agent applies general best practices. - It runs lightweight user-journey tests in an AWS-managed isolated environment to confirm that the software builds, runs, and passes basic functional checks. - Findings are available in: - The AWS DevOps Agent console - GitHub or GitLab pull-request comments - IDE workflows through the Kiro power or Claude Code plugin ## Autonomous Release Testing - Generates test plans based on the specific code change rather than relying only on static test suites. - Tests web and API applications in customer-provisioned, production-like environments before merging. - Covers: - Functional correctness - Behavioral regressions - Integration scenarios - Produces structured artifacts for every run, including metrics, logs, traces, and execution summaries. ## Configuring and Running Reviews - At least one GitHub or GitLab repository must be connected to an AWS DevOps Agent Space. - The agent indexes connected code and builds a knowledge graph of cloud and cross-repository dependencies. - Reviews can be triggered by: - Submitting a pull request - Starting an on-demand chat request, such as “Perform a production risk analysis on my repository branch” - The target can be specified using a branch name, pull-request number, or commit SHA. - Reviews can also be initiated from supported development environments. ## Reviewing Results - The **Changes** section lists review executions and supports filtering by category or status. - The **Timeline** records the agent’s tools, consulted dependencies, observations, and timestamped reasoning steps. - The **Report** includes: - Recommended action: **BLOCK**, **Proceed with Caution**, or **Safe to Release** - Number of critical issues - Commit revision and changed-file count - Evidence supporting the recommendation - Severity-ranked findings - Actionable remediation steps - A file-by-file summary of modifications - Developers can ask follow-up questions about affected downstream consumers, impacted files and line numbers, and recommended fixes. AWS DevOps Agent’s preview release-management capabilities provide an automated layer of change analysis and targeted testing before production. Teams should configure organization-specific instructions, connect their repositories, and use the generated reports and test artifacts as an additional safety gate for AI-assisted development.

spotify

How We Release the Spotify App: A Look Under the Hood (Part 2) | Spotify Engineering (opens in new tab)

Spotify’s Release Manager Dashboard replaced a Jira-heavy workflow with a unified command center for mobile and desktop releases. It reduces context switching and cognitive load by aggregating release status, bugs, testing, build health, and usage metrics into one interface. A backend that caches and pre-aggregates data from roughly ten systems makes the dashboard fast and affordable. ## From Jira to a Release Command Center - Previously, Release Managers depended on Jira tickets, multiple browser tabs, and Slack conversations. - This made it easy to miss details and required constant context switching. - The dashboard was designed to: - Prioritize the Release Manager’s workflow. - Remain understandable to anyone familiar with Spotify’s release process. - Reduce cognitive load. - Support fast, accurate decisions. ## Release Data Spotify treats each platform-and-version combination as a **track**. Android, iOS, and Desktop share some libraries but are released independently. - Track-specific information includes: - Current release state. - Release-blocking bugs. - Team regression-testing sign-offs. - Final release candidate build status. - Build verification test results. - App Store upload status. - Crash, ANR, and CPU-exception rates per song. - Daily active users. - The dashboard also highlights: - Blocking bugs without an assigned version. - Bugs without a priority. - Reports from internal users and alpha/beta testers. - Release management includes finding appropriate owners for unassigned issues, even when temporary team ownership is needed. ## React, TypeScript, and Backstage - The dashboard is a Backstage plugin built with React and TypeScript. - Spotify’s Backstage ecosystem already provides: - Software Catalog functionality for distributing builds to app stores. - App-build and crash plugins with deeper detail. - Shared UI components and data across developer tools. - The interface provides a quick health overview, with drill-down capabilities for investigating blockers. - Status colors communicate urgency: - **Green:** Ready for the next stage. - **Yellow:** Something still needs attention. - **Red:** An error requires corrective action. ## Backend Aggregation and Performance - A dedicated backend acts as an API gateway for approximately ten existing systems. - It consolidates their data into one consistent API for the dashboard. - The initial implementation queried large amounts of data on every reload, making it slow and expensive. - Caching and five-minute pre-aggregation reduced load time to about eight seconds while significantly lowering operating costs. ## Dashboard Sections ### Production - Shows the currently deployed Android, iOS, and Desktop versions. - Since these releases have completed the release process, only production metrics are displayed. - Metrics include: - Crash data. - Rolling daily active users over the previous 24 hours. - This helps Release Managers detect problems shortly after rollout. ### Current - Displays the branched version that has not yet reached production. - Tracks release blockers such as: - Open blocking bugs. - Incomplete regression testing. - Crash rates above release thresholds. - Builds that do not contain the latest release-branch commits. - Yellow indicators represent pending work, while red indicators call for direct investigation or action. - The ITGC section confirms that full production rollout is permitted only after: - ITGC tests pass. - Reporting is correct. - Data loss remains below the defined threshold. - A Release Status Ping link generates a Slack update with the release’s current state. ### Upcoming - Mirrors the Current release view for the next planned version. - Sections that are not yet relevant are shown in a grayed-out state. The dashboard illustrates how a specialized aggregation layer and focused UI can turn a fragmented release process into a clear operational workflow. For organizations managing complex, multi-platform releases, combining cached cross-system data with color-coded status and drill-down details can improve both speed and release safety.