eazyBI Community Day is an annual event held by eazyBI. This year, it was all about removing...
Read More
Atlassian
This article is written by Filip from Release Management Apps
Over the last decade, the European Union has significantly expanded its regulatory landscape across industries such as banking, insurance, healthcare, iGaming, and defense.
Regulations including GDPR, DORA, NIS2, the AI Act, the Cyber Resilience Act, the Digital Services Act (DSA), and the Digital Markets Act (DMA) now exert a profound influence on how modern enterprises design, operate, and govern their IT systems.
At the same time, competitive pressure has never been higher. Organizations are expected to innovate continuously, reduce time-to-market, and deliver new digital capabilities faster than ever before.
This creates a fundamental tension: how can enterprises move fast while remaining secure, compliant, and resilient?
Modern Architecture Solves Speed—But Introduces New Risk
Recent technology trends—such as breaking monolithic applications into modular microservices, adopting cloud-native platforms, and using automation as the backbone of DevOps—have dramatically improved engineering velocity and scalability.
However, these advances are not always aligned with regulatory requirements by default. In highly regulated environments, complexity increases exponentially:
- A single customer-facing change may require coordinated updates across dozens or even hundreds of systems.
- Systems are owned by teams spread across departments, countries, and time zones.
- Multiple features are often bundled into coordinated releases.
Before anything reaches production, the entire solution must be validated end-to-end. This includes not only functional testing, but also critical non-functional requirements (NFRs) such as security, compliance, performance, availability, and resilience.
Without the right release discipline, modern architecture can unintentionally increase compliance risk.
The Hidden Cost: Loss of Team Autonomy
When regulatory controls are introduced poorly, they often land directly on engineering teams in the form of:
- Manual approval gates
- Extra documentation requirements
- Fragmented processes across tools and departments
This can undermine team autonomy and slow delivery.
History has shown that this approach is counterproductive. Engineering teams perform best when they are empowered, trusted, and able to innovate within clear boundaries. Excessive friction not only reduces velocity—it increases operational risk as teams work around broken processes.
A Critical Insight: Regulations Don’t Target Engineering—They Target Releases
A closer look at modern EU regulations reveals an important insight:
Most regulatory requirements do not dictate how teams write code.
They focus on how changes are reviewed, approved, released, and audited.
Across GDPR, DORA, NIS2, and related frameworks, the core controls consistently revolve around:
- Structured review processes (the “four-eyes” principle)
- Formal change management
- Assurance that only authorized and approved artifacts reach production
- Guarantees that artifacts are not modified between approval and deployment
- End-to-end audit trails covering changes, checks, and approvals
In other words, the regulatory burden sits primarily in the release management layer, not in daily development work.
Why Release Management Becomes the Bottleneck
Many organizations attempt to meet regulatory demands by adding controls directly into team workflows. This often results in fragmented processes and duplicated effort.
A more effective approach is to introduce a centralized release management capability that sits above delivery teams—coordinating releases without restricting how teams build software.
This “release hub” becomes the single place where:
- Dependencies across systems and teams are managed
- Approvals from architecture, security, risk, and compliance are orchestrated
- Evidence for audits is collected automatically
- Releases are tracked, communicated, and executed consistently
Case Study: A Global Retail Bank Adapting to new technology and regulatory landscapes
A global retail banking group recently embarked on a transformation toward a cloud-native, microservices-based architecture while preparing for DORA compliance.
The benefits of microservices and cloud hosting platforms were immediate: teams gained speed, autonomy, and scalability. But new pain points emerged just as quickly.
Every customer-facing update triggered changes across hundreds of backend services. Successful releases now depended on precise timing, cross-team coordination, and multiple approval layers involving Engineering, Enterprise Architecture, Information Security, Risk, and Compliance.
Despite mature CI/CD pipelines, delays were rarely caused by tooling. Instead, they stemmed from missing coordination and unclear ownership.
The organization struggled to answer basic but critical questions:
- What is actually ready to ship?
- Which changes have been approved—and by whom?
- In what order should components be deployed?
- What evidence exists for audit and regulatory review?
Without a central system, release decisions were scattered across Slack threads, emails, and dozens of Jira projects. Release days felt like fire drills. In a highly regulated industry, that wasn’t just inefficient—it was dangerous.
The Solution: A Centralized Release Hub
To address these challenges, the bank implemented a dedicated release management approach built around a centralized release hub in Jira.
This hub provided:
- A single source of truth for release readiness
- Visibility into cross-system dependencies
- Orchestrated approval workflows across all control functions
- Automated collection of compliance evidence
- Integration with deployment pipelines and release note distribution
Importantly, delivery teams retained their autonomy. They continued to build and test software using modern DevOps practices, while regulatory controls were enforced consistently at the release layer.
Autonomy sustained, responsibility enforced
Each team retained autonomy but adopted a standardized practice: using Jira Fix Versions to bundle upcoming changes and identify upstream and downstream dependencies early. This created a clear, cross-team delivery contract.
A standard delivery process
A standardized workflow was introduced for all Fix Versions. Every team’s Fix Versions appeared on a unified board, grouped by key initiatives acting as swimlanes. Many-to-many relationships between initiatives and Fix Versions enabled better visibility, and explicit dependencies helped orchestrate the correct delivery sequence.
Suddenly, the entire release landscape became manageable.
Integration of approval flows
Existing approval processes—powered by Jira Service Management (JSM)—were integrated directly into the release hub. As Fix Versions moved into Approval Required, the hub validated all preconditions and automatically created corresponding JSM tickets.
These tickets included all necessary information:
– scope of the release,
– dependencies,
– testing evidence,
– pull request validation,
– enterprise architecture review status,
– links back to the release hub for full context.
This provided complete visibility into what was awaiting approval—and for how long.
Integration of CI/CD and automated release notes
Bitbucket Pipelines were connected to the hub, triggering automatically once approvals were completed and Fix Versions transitioned to Ready for Deployment. This eliminated the need to manually create DevOps tickets.
After deployment, the system prompted the creation of release notes using predefined templates. Generated notes were stored in a centralized Confluence space with versioning, and linked directly from the Fix Version.
The Takeaway
The release hub became far more than an overlay on top of CI/CD—it evolved into the central nervous system of the bank’s software delivery process. It enabled capabilities that weren’t possible before:
- Automatic collection of testing and compliance artifacts
- Enforced review gates with role-based permissions
- Transparent tracking of integration points across services
- Automated deployment triggers and release note generation
The impact was immediate:
- Release preparation time dropped significantly, thanks to fewer manual checks and clearer coordination.
- Audit readiness improved, with approvals and documentation captured directly within the workflow.
- Teams felt more empowered and less reactive, supported by a process that enabled collaboration rather than adding friction.
- Releases became predictable and routine, instead of late-night emergencies and ad-hoc sync calls.
Most importantly, releases became trusted—a predictable, traceable, and scalable operation. In industries where compliance and control are non-negotiable, that’s transformative.
Conclusion
In regulated sectors, Release Management isn’t “just” operational tooling—it’s strategic infrastructure. When done right, it fades into the background, enabling safe, compliant, and scalable delivery without slowing innovation.
