Deploying to production used to be an event. Teams would plan deployment windows weeks in advance, schedule maintenance pages, gather in war rooms on Saturday nights, execute runbooks step by step, and hold their breath until the smoke tests passed. If something went wrong, rollback could take hours. If it went very wrong, the weekend was lost. This model is dying, and for good reason. Continuous delivery replaces deployment anxiety with deployment confidence by making releases routine, automated, and reversible. At Pepla, we have moved from monthly releases to deploying multiple times per week -- sometimes multiple times per day -- and the quality has improved, not declined.
CD vs CI vs Continuous Deployment
These three terms are frequently confused, and the distinctions matter.
Continuous Integration (CI) is the practice of merging developer code changes into a shared branch frequently -- at least daily. Each merge triggers an automated build and test pipeline. CI catches integration problems early by ensuring that code from multiple developers works together. It is the foundation that the other practices build upon.
Continuous Delivery (CD) extends CI by ensuring that the codebase is always in a deployable state. Every change that passes the automated pipeline could be released to production at any time. The key word is "could" -- a human still makes the decision to deploy. CD means the team is always ready to release, not that they always do.
Continuous Deployment goes one step further: every change that passes the automated pipeline is deployed to production automatically, with no human approval step. This is the most aggressive approach and requires extremely high confidence in the test suite and monitoring. Few organisations operate at this level for all changes, but many use it for specific low-risk change types.
At Pepla, most of our projects operate at the CD level. Every merge to the main branch triggers the full pipeline, and the resulting artefact is deployable. Deployment to production requires a deliberate action -- a button press or an approval in the pipeline -- but it can happen at any time because the codebase is always ready.
Feature Flags
Feature flags (also called feature toggles) are one of the most powerful techniques in the CD toolkit. They decouple deployment from release. With feature flags, you can deploy code to production without exposing it to users. The code is there, but it is behind a flag that controls who sees it.
This enables several valuable patterns. Gradual rollout: enable a feature for 5% of users, monitor for issues, then increase to 25%, 50%, and 100%. Beta testing: enable a feature only for users who have opted into early access. A/B testing: show different versions of a feature to different user segments and measure which performs better. Kill switch: disable a feature instantly if it causes problems, without deploying a code change.
Feature flags decouple deployment from release. Ship code to production daily, then control visibility without another deploy cycle.
Feature flags also simplify the development workflow. Instead of maintaining long-lived feature branches that diverge from the main branch and require painful merges, developers merge to main continuously with their incomplete features behind flags. The main branch always contains the latest code, and features become visible when the flag is turned on -- not when the code is merged.
The discipline with feature flags is managing their lifecycle. Temporary flags (used for gradual rollout) should be removed after the feature is fully launched. Permanent flags (used for configuration or environment-specific behaviour) should be documented and audited. At Pepla, we track feature flags in a registry and review them during retrospectives to prevent flag debt from accumulating.
Feature flags decouple deployment from release. Ship code to production daily, then control who sees it without another deploy.
Blue-Green Deployments
A blue-green deployment maintains two identical production environments: "blue" and "green." At any given time, one environment serves live traffic while the other is idle. To deploy, you update the idle environment with the new version, run smoke tests against it, and then switch the load balancer to route traffic to the updated environment. The old environment remains available for instant rollback -- if the new version has problems, you switch back in seconds.
The beauty of blue-green is that users experience zero downtime during deployment. There is no maintenance window, no "please try again later" message. The switch is atomic -- one moment users are hitting the old version, the next they are hitting the new version. And because the old environment is still running, rollback is instantaneous.
The cost is infrastructure: you need two complete production environments. For applications running on managed cloud services, this cost is manageable -- you spin up the green environment, deploy, test, switch, and tear down the blue environment. For applications with complex infrastructure (dedicated hardware, large databases, stateful services), the overhead is more significant.
At Pepla, we use blue-green deployments for client-facing applications where downtime is unacceptable. The infrastructure cost is trivial compared to the cost of scheduled maintenance windows and the risk of failed deployments requiring manual rollback.
Canary Releases
Canary releases take a more gradual approach than blue-green. Instead of switching all traffic at once, you route a small percentage of traffic to the new version -- say 5% -- while 95% continues hitting the current version. You monitor the canary closely for errors, latency increases, and business metric anomalies. If everything looks good, you gradually increase the canary's traffic share until it serves 100% of requests.
The advantage of canary releases over blue-green is that problems affect a small number of users rather than everyone. If the new version has a bug that only manifests under specific conditions (a particular browser, a particular data pattern, a particular user role), the canary catches it with minimal blast radius. With blue-green, the same bug would affect every user simultaneously.
Canary releases require sophisticated traffic routing (service meshes like Istio or Linkerd provide this capability) and robust monitoring (you need to compare metrics between canary and baseline in real time). They also require the ability to run two versions of the application simultaneously, which adds complexity around database compatibility and API versioning.
Database Migrations in CD
Database schema changes are the hardest part of continuous delivery. Application code can be deployed and rolled back in seconds. Database changes are different -- they modify persistent state, and rolling back a schema change that has been applied to production data is risky at best and catastrophic at worst.
The fundamental principle is backward compatibility. Every database migration must be compatible with both the current and the previous version of the application. This constraint exists because during deployment, both versions run simultaneously (even if only briefly), and because rollback means the old application code needs to work with the new database schema.
Practically, this means breaking destructive changes into multiple deployments. To rename a column, you do not rename it directly. In deployment one, you add the new column and write to both old and new. In deployment two, you migrate reads to the new column. In deployment three, you remove the old column. Each step is independently safe to roll back.
This discipline is non-negotiable in CD. Taking shortcuts with database migrations is how teams end up in 2 AM war rooms trying to restore database backups. At Pepla, every database migration is reviewed for backward compatibility before it enters the pipeline, and we use migration tools (Flyway, Liquibase, or Entity Framework migrations) that version and track every schema change.
If deploying feels dangerous, the solution is not to deploy less often -- it is to invest in automation that makes deployment safe and routine.
If deploying to production feels dangerous, the solution is not to deploy less often. It is to invest in the practices that make deployment safe -- automated testing, feature flags, blue-green deployments, and backward-compatible migrations. Deploy more often, in smaller increments, with better automation.
Monitoring Post-Deploy
Deployment does not end when the pipeline reports success. It ends when the team has confirmed that the new version is performing correctly in production. Post-deployment monitoring is the final stage of the delivery pipeline, even though it happens after the technical deployment is complete.
Effective post-deployment monitoring compares key metrics against a baseline. Error rates should not increase. Response times should not increase. Business metrics (conversion rates, transaction volumes, user activity) should be stable or improving. Any deviation triggers investigation.
Automated anomaly detection makes this practical at scale. Rather than having a human stare at dashboards after every deployment, monitoring systems detect statistically significant deviations from baseline and alert automatically. This enables the team to deploy with confidence and respond quickly if something goes wrong.
At Pepla, we define a "bake time" after each deployment -- a period (typically 30 to 60 minutes for routine deployments) during which the team monitors closely and is prepared to roll back. After the bake time passes without anomalies, the deployment is considered successful and the previous version's infrastructure can be cleaned up.
Rollback Strategies
The ability to roll back quickly is what makes frequent deployment psychologically safe. If the team knows they can undo a deployment in 30 seconds, the perceived risk of deploying drops dramatically.
Infrastructure-level rollback (blue-green switch, canary traffic routing) is the fastest -- it changes which version receives traffic without deploying anything. Application-level rollback deploys the previous version through the same pipeline used for forward deployments. Feature flag rollback disables the problematic feature while leaving the rest of the deployment in place.
Database rollback is the most complex. If the deployment included a schema migration, rolling back the application requires that the database schema is still compatible with the previous version. This is why backward-compatible migrations are essential -- they make application rollback possible without database rollback.
At Pepla, every deployment pipeline includes a documented rollback procedure that has been tested. We practice rollback regularly -- not just when things go wrong, but as a routine exercise to ensure the procedure works. A rollback procedure that has never been tested is not a rollback procedure. It is a hope.
The Culture of Shipping
Continuous delivery is as much a cultural shift as a technical one. It requires a team that values small, frequent changes over large, infrequent releases. It requires trust -- in the test suite, in the monitoring, in the rollback procedures, and in each other. It requires a blameless approach to failures, where incidents are learning opportunities rather than occasions for punishment.
Organisations that successfully adopt CD share several cultural traits. They celebrate shipping, not planning. They measure lead time (how quickly an idea becomes production code), not utilisation (how busy everyone is). They treat deployment failures as system problems, not people problems. They invest in automation not because it is interesting, but because it is the foundation of reliable delivery.
The payoff is transformative. Teams that deploy multiple times per week spend less time on release coordination, experience fewer production incidents (because changes are smaller and easier to diagnose), respond to customer feedback faster, and -- perhaps most importantly -- feel ownership over the software they ship. When deployment is routine, the feedback loop between writing code and seeing its impact in production shrinks from weeks to hours. That tight feedback loop is where learning happens, and learning is what makes software teams great.
A rollback procedure that has never been tested is not a rollback procedure -- it is a hope. Practice rollback regularly, not just when things go wrong.
At Pepla, we have seen this transformation across multiple client engagements. Teams that were afraid to deploy quarterly now deploy weekly with confidence. The technical investment in CI/CD pipelines, automated testing, and deployment automation pays for itself within months through reduced incident costs, faster delivery, and higher team morale.
