Question
Travis CLI Push vs. Third-Party CD Pull for Zero-Downtime Deployments
Dev Vale
0 reputation · 30 May 2022, 13:53 UTC
121.2K views1
Loading…
0 reputation · 30 May 2022, 13:53 UTC
When orchestrating a zero-downtime migration for a Java/Hibernate application, the deployment phase must ensure that database schema updates and application binaries are synchronized without interrupting active traffic. Since Travis CI serves as the build and test orchestrator rather than the hosting environment, the hand-off to the production infrastructure is a critical design point.
One approach involves using the Travis CLI to push build artifacts directly to a target server. An alternative is integrating a third-party Continuous Delivery (CD) tool that pulls the verified build from Travis CI only after specific health checks are passed.
The primary constraint is preventing database locking or application instability if multiple build pipelines trigger concurrent deployment attempts during high-frequency commit cycles.
31775 reputation · 30 May 2022, 22:36 UTC
The Travis CLI push method does not provide built‑in concurrency control; overlapping pushes can cause simultaneous service restarts. A pull‑based CD tool that waits for the Travis build, runs health checks, then pulls the artifact serializes deployments and avoids overlap.
If two Travis jobs finish within a few seconds and both invoke the CLI push, the server may receive two SCP bursts almost simultaneously, triggering two restart scripts or migration runners. This can lead to connection‑pool exhaustion or lock contention in the database. A pull‑based CD agent, by contrast, usually processes one build at a time because it either polls at a fixed interval or serializes webhook handling, so only one deployment proceeds after the previous health check succeeds.
Do you already have a distributed lock service or a CD agent in place? If yes, the push method can be made safe with minimal changes; if not, adding a pull‑based CD is the simpler way to guarantee serialized deployments.
Use comments to ask for clarification. Post a solution as an answer.
31,775 reputation · 30 May 2022, 16:54 UTC
Even when you limit Travis CI to one concurrent build, deployment races can still occur if a build is started manually, via the API, or by a cron trigger that bypasses the normal queue. To guarantee that only one deployment proceeds, acquire a lightweight distributed lock before the SCP/SSH push and release it after the application restart. A simple implementation is to create a lock file on a shared NFS mount (e.g., /mnt/deploy-lock/travis.lock) using set -o noclobber; : > $LOCKFILE and remove it in a trap block. Verify the lock by checking the file’s presence and timestamp in the Travis log (ls -l $LOCKFILE). This approach works independently of whether you use a push or pull‑based CD flow.
java
travis