1. Current Product Behavior Limits Active/Active Operations
IBM DevOps Deploy supports High Availability through clustered application servers sharing a common database and file system. However, in practice, the product’s internal maintenance and cleanup mechanisms are designed to execute from a single active context. This effectively enforces active‑passive behavior for database maintenance, even when application servers operate in a clustered HA configuration.
This limitation makes it infeasible to run DevOps Deploy in a true Active/Active mode for database operations, particularly for background jobs such as audit log cleanup and deployment history cleanup.
2. Database Cleanup Operations Are Not Coordinated Across HA Nodes
Operational evidence from production and non‑production environments indicates that database cleanup tasks (including audit log and deployment history deletes) are initiated independently by multiple active application instances when deployed across data centers.
Because these cleanup jobs lack:
they can execute concurrently against replicated databases, resulting in conflicting delete operations. This has led to database replication failures and forced operational intervention.
3. Replication Conflicts Observed in Multi‑Datacenter Deployments
In environments where IBM DevOps Deploy application servers operate across multiple data centers with replicated databases for high availability and disaster recovery, cleanup‑related delete activity originating from more than one active application instance has caused replication instability.
As a mitigation, environments were required to:
This confirms that the current product behavior is not compatible with Active/Active database deployments, even when such architectures are otherwise supported at the infrastructure level.
4. Limitation Is Product‑Driven, Not Configuration‑Driven
Architecture reviews and technical evaluations confirmed that the inability to operate in Active/Active mode for database cleanup is not due to:
load balancer configuration,
database technology choice, or
customer implementation error.
Instead, the limitation stems from the DevOps Deploy application’s internal handling of cleanup and scheduled background jobs, which are not designed for concurrent execution across multiple active instances.
5. Operational Impact on Enterprise HA Environments
Due to the lack of Active/Active‑safe cleanup support, enterprises operating DevOps Deploy at scale face the following challenges:
Forced reduction of high availability during maintenance windows
Increased risk of database growth when cleanup is deferred
Manual coordination to avoid concurrent job execution
Reduced fault tolerance despite HA infrastructure investments
For Tier‑1 and 24×7 environments, this significantly diminishes the value of clustered HA deployments.
6. Need for Enhancement
Collectively, these observations demonstrate that while IBM DevOps Deploy supports clustered HA at the application level, database maintenance operations are not designed for true Active/Active execution.
Introducing Active/Active‑safe database cleanup—through coordinated job execution, leader election, or explicit single‑executor control—would allow customers to:
maintain continuous availability,
safely operate multi‑node HA deployments, and
align with modern enterprise Active/Active architecture standards.
Summary
Real‑world operational evidence shows that IBM DevOps Deploy’s current cleanup and maintenance model enforces active‑passive behavior in High Availability environments. This limitation has caused database replication issues and forced customers to reduce availability as a workaround.
Enhancing the product to support Active/Active‑safe database cleanup would address a known limitation, improve enterprise scalability, and strengthen DevOps Deploy’s HA capabilities.
We met with your team last Friday at 2pm EST and will be working on a solution and providing an update in approximately 2 weeks. Meeting is being scheduled to discuss the findings of our efforts.
Thank you for submitting this idea. We have created a discussion topic for this idea and will be presenting it to our dev team for their review in a back2design session that occurs on Tuesdays and Thursdays. We will be in touch with any follow-up questions we may have.