At the Conac team, deployment is not a rare event; it’s a daily routine. Instead of bundling weeks of changes into a risky big-bang release, engineers ship small, incremental updates every day. This practice, known as daily deploy, is one of the foundations of modern continuous delivery.
The philosophy is simple:
Smaller changes → safer deploys
Faster feedback → quicker improvements
Automation → boring releases
Smaller, Safer Changes
When you deploy daily, each release only contains a small set of changes. If something breaks, it’s easier to trace back to the cause and roll it back. Compare this to a monthly release: debugging dozens of merged features is painful.
Faster Feedback Loop
Daily deploys shorten the gap between writing code and seeing it in production. Engineers get immediate validation that their code works as intended, and users benefit from new features or bug fixes without long waits.
Reduced Risk
Frequent, routine deploys reduce the “fear factor.” Instead of stressful release days, deployment becomes part of the everyday workflow. Failures still happen, but they’re smaller and easier to recover from.
Continuous Integration (CI)
Every commit is tested automatically.
Large test suites ensure quality before changes reach production.
Automated Deployment Pipelines
Engineers merge into the main branch.
Pipelines build, test, and prepare artifacts for deployment.
Canary Releases & Gradual Rollouts
Updates are first rolled out to a small % of users.
Monitoring detects errors or performance regressions.
If all looks good, the rollout expands.
Monitoring & Instant Rollback
Real-time dashboards track health metrics.
If something fails, an automated rollback (or human-triggered one) quickly restores stability.
In our team, we practice daily deployment with a strong focus on safety and code quality. Here’s how we make it work in practice:
Safe Pull Requests
Every pull request goes through careful review and automated checks before merging. We treat safety as the first priority.
Feature Flags
New changes are wrapped in feature flags. This ensures that incomplete or experimental features don’t affect clients until they are ready.
Unit Tests First
We write unit tests to validate feature behavior with feature flags both on and off. This guarantees that toggling the flag won’t break existing functionality.
Focused Automation Tests
Instead of building an overly large suite of automation tests, we keep them limited to verifying the main end-to-end flows. The rest of the coverage comes from unit tests.
Engineers Own Quality
By shifting test-writing responsibility from QA to engineers, we encourage developers to care deeply about the quality of their own code. This shift has improved both reliability and team ownership.
Unlike large-scale systems, our product is still relatively small. Based on historical data, we’ve seen that our code quality and testing practices are strong enough to support daily deploys without needing complex mechanisms like canary releases or detailed rollback plans.
For us, the trade-off is clear:
We avoid the operational overhead of maintaining canary pipelines and rollback scripts.
We focus our energy on writing solid tests, using feature flags, and keeping pull requests safe.
That said, this is not a permanent decision. As our product grows and the impact of changes increases, we may adopt canary releases and rollback strategies in the future to strengthen our deployment process further.
Daily deploy sounds simple in theory, but in practice, we’ve had to adapt our workflow to make it smooth and sustainable. Here are a couple of challenges we faced and how we solved them:
At first, deployments were handled by a specific group of members, which sometimes led to confusion or missed responsibilities. To fix this, we introduced a rotation system where one engineer is the designated PIC for daily deploys.
Advantages of rotation PIC:
Spreads deployment knowledge across the whole team.
Prevents dependency on a single person.
Builds shared responsibility and confidence in the process.
Encourages developers to care more about code quality, since they know they will also be responsible for deploying it.
Since our workflow occasionally evolved (e.g., new steps added, commands updated), some deployments risked missing a step. To address this, we documented a step-by-step deployment workflow that evolves alongside the system.
Advantages of a defined workflow:
Ensures consistency, even if the workflow changes.
Reduces human error by making every step explicit.
Makes onboarding new engineers much easier.
While we aim to deploy every day, we’ve learned that being too strict about it can sometimes do more harm than good. If an issue arises, such as a missed test case, an unconfirmed behavior change, or a missed check during review, it’s okay to pause rather than force the release.
To reduce these situations, we’ve introduced a few safeguards:
🏷️ PR Labeling for Small Changes
For pull requests that introduce small behavior changes without a feature flag, we add a specific label to remind the team to confirm the change with the business side before deployment.
If confirmation doesn’t happen in time, we either revert the PR or skip deployment for that day.
🧩 Handling Bugs Found Before Release
When bugs are discovered—either by automation tests or during staging verification—we decide the best action based on context:
Fix the issue before deployment.
Revert the problematic PR.
Or skip the day’s deploy entirely.
These improvements not only stabilized our daily deploy process but also made it more scalable and team-friendly.
Overall, these practices help us maintain a healthy balance between speed and safety, ensuring that daily deployment remains sustainable over the long term.
Daily deploy works best for teams that already have a stable foundation — solid code review practices, reliable automated tests, and a culture of ownership and accountability.
It brings the most value when your product is under active development and you want to deliver user value continuously without long release cycles.
However, it might not be the best fit for every team or product stage.
If your testing coverage is still low, or your deployment pipeline isn’t stable yet, forcing daily deploys may create more pressure than benefit.
In such cases, it’s better to start by strengthening your CI/CD pipeline, improving review quality, and automating tests — then gradually move toward daily releases.
In our case, we chose daily deploy because our product isn’t huge, our release process is stable, and we’ve seen from historical data that our code quality is consistently good.
We also believe that this practice keeps us more user-focused, which aligns with our company values.
🚀 Faster delivery of features → users see improvements daily.
🐛 Quick bug fixes → no waiting weeks for a patch.
💡 Continuous experimentation → features can be A/B tested immediately.
😌 Stress-free engineering culture → deploys are boring, not terrifying.
🎯 User-focus mindset → by shipping small updates daily, we stay closely aligned with real user needs, validate feedback faster, and ensure our work continuously delivers value.
At Money Forward, User Focus is one of our core values — and daily deploy perfectly supports this mindset.
By delivering small, incremental changes every day, we can stay closer to our users’ real needs and continuously improve their experience.
Instead of waiting weeks or months to see how users react to new features, our engineers can observe the impact almost immediately.
This short feedback loop helps us validate ideas faster, reduce assumptions, and make more confident product decisions.
Daily deploy also changes how engineers think — when your code goes live the same day, you naturally start caring more about its impact on users rather than just whether it “works.”
This practice encourages everyone, from developers to designers, to build with empathy and put users at the center of every change we make.
Daily deploy isn’t just a technical practice—it’s a cultural shift. It has turned deployment from a high-risk, high-stakes event into a smooth, everyday routine.
By delivering updates every day, we can observe how users interact with new features and continuously improve their experience.
The mantra is simple:
Ship small. Ship often. Make deploys boring.
