Implementing a Mixed Continuous Deployment Strategy Using an Iterative Approach

Cloud migration is a complex task that requires coordination and careful planning. It involves significant changes to an app’s infrastructure and code, from architecture compatibility with cloud platforms to data security and scalability. The main challenge here is ensuring that all components and data are moved seamlessly without disrupting business operations.

Implementing a CI/CD pipeline is one of the vital steps to ensure successful cloud migration. When done right, DevOps best practices streamline the cloud migration process, helping avoid pitfalls down the line.

Continuous delivery, continuous integration, and continuous deployment automate building, testing, and deploying code changes. For your business, it means more frequent releases and satisfied users. And we all want to make users happy, don’t we?

To start smart, you must decide which code to automate, test the implementation with non-critical apps, and opt for the iterative approach to deployment.
This article will help you feel the difference between CI and CD, and familiarize yourself with common deployment strategies and ways to combine them.

Continuous Integration, Continuous Deployment, and Continuous Delivery

There’s a lot of confusion around the terms “continuous integration,” “continuous delivery,” and “continuous deployment.” While these concepts are related and share common goals—to release high-quality code quickly and frequently—each has its specific purpose.

During continuous integration (CI), developers regularly commit code changes into a shared repository. When this happens, an automated build system executes tests against the modified files to ensure everything works as expected. This helps eliminate conflicts between different components submitted by multiple contributors.

Continuous delivery and continuous integration work together like a charm. Once new features are reviewed, they’re automatically pushed to the testing and production environment. Small batches of code changes are released continuously.

Continuous deployment takes CD a step further by automatically releasing code changes into production where users can see them. Any code pushed into the shared repo goes through a complete CI/CD pipeline and gets released all at once without manual approval from developers.

So, what should you opt for—continuous delivery or deployment?

The answer depends on the specific goals of your product.

If you want to deploy code quickly and efficiently but still control what gets released into production, then continuous delivery is the way to go. However, if speed and agility are paramount for your organization—as they are for many tech companies—then the continuous deployment is a better choice.

In fact, among 47% of developers who use either continuous integration or deployment, only one in five applies both automation strategies. Quite a few organizations don’t leverage DevOps practices, not knowing how to implement them properly, and thus miss out on improved deployment speed and product quality.

This is the part where deployment strategies come into play.

​​​​​​Choosing a Continuous Deployment Strategy

With so many different methods of deploying applications, choosing the right strategy that matches your needs is critical for an effective CI/CD pipeline. The impact on the system and its users, costs, deployment speed, and workload are just a few things to consider.

The key to success is understanding the pros and cons of each strategy and the best time to use them. Start small with a basic deployment strategy and add complexity as needed.

Although it’s not always possible to improve an existing continuous deployment strategy without mapping out the whole path of the “ideal” pipeline in advance, we will try to show you how to combine techniques to achieve better results.

Here are the six strategies we will look at:

• ​​Recreate: Version 1.1 is rolled out after version 1.0 is shut down.
• Ramped: Version 1.1 is slowly rolled out, replacing version 1.0.
• Blue/Green: Version 1.1 is released along with version 1.0, then the traffic is switched to version 1.1.
• Canary: Version 1.1 is released to one user group, then proceeds to a full rollout.
• A/B testing: Version 1.1 is released to a group of users under specific conditions.
• Shadow: Version 1.1 gets live traffic along with version 1.0 without affecting the response.

So buckle up — we’re going to dive deeper into various deployment strategies, their combinations, and an iterative implementation approach.

Recreate

The “recreate” approach involves replacing the current system with a new one. This means all your services must be taken down, updated to the latest version, and then brought back online. This process is usually run during planned downtime windows so that all nodes are replaced simultaneously with no service disruptions.

Advantages:

• Low failure rate
• Easy setup
• Completely renewed application

Drawbacks:

• Service downtime that affects end users

Best for:

• Migrating legacy applications
• Implementing large-scale code deployments
• Overhauling the app's architecture and configuration
• Saving costs on infrastructure
• Using in testing or staging environment

Ramped

With ramped deployment, the new app’s version is slowly rolled out to end users by replacing components one by one. This way, developers get feedback sooner and can correct their course before users get bogged down by bugs.

The rolling-update process boils down to this: one or several components of the new version are deployed within a pool of the old version, gradually replacing them. Once the service accepts traffic, the new components are added to the pool, and the old components are removed.

By adjusting these parameters, you can adapt the deployment time to your system needs:

• Parallelism: number of components rolled out at once. It helps you balance speeding up the continuous deployment process and ensuring stability.
• Max batch size: how many instances or clusters should be updated in one go.
• Max surge: number of components to add on top of the current amount. Setting a high max surge value gives your app more resources to take on the additional load during deployment. However, you risk disrupting performance or triggering downtime if you add too many instances.
• Max unavailable: number of components that can be offline simultaneously during deployment. It’s essential for mission-critical applications, as it ensures there’s always enough capacity to handle incoming requests.

Advantages:

• Easy to implement
• Causes fewer errors due to compatibility issues
• Incremental deployment provides more control during testing

Drawbacks:

• Slow rollback
• Hard to support multiple APIs
• Lack of traffic control

Best for:

• Stateful platforms that can manage data rebalancing
• Gradually migrating data and ensuring it’s synced across all instances
• Scenarios where a complete app migration is not possible in one go

Blue/Green

Unlike the previous two approaches to continuous deployment, Blue/Green runs two identical instances of the app in parallel—one as the “blue” version (the current live instance) and another as the “green” version.

This method keeps only one version live at a time. When the new version is ready for deployment, you first deploy it to the green instance while routing the traffic to the blue one. Next, you run automated tests on the green instance, double-checking that it meets all functional requirements. Once you’re done testing, you route traffic to the new version and keep the blue instance for quick rollback or decommissioning.

Advantages:

• Eliminates downtime with instant rollback
• Improved compatibility and safety
• No versioning issues

Drawbacks:

• High costs as it needs double the resources
• Requires a way to switch between versions
• Needs all-out testing before production release

Best for:

• Frequent code deployments and minimized downtime
• Applications with complex testing requirements
• Scalable infrastructure
• Databases and environments with N+1 compatibility

Canary

Canary deployment, also known as feature flipping, involves deploying a new software version to a small subset of users before rolling it out to the general public. You can split the traffic 90/10, where 90% of user requests go to the old version and 10% to the new one. Best practices recommend choosing the traffic weight based on SLA.

When the new version is rolled out, you must carefully monitor performance metrics and act according to feedback. Once the change is tested and accepted by users, you can roll it out to the entire infrastructure.

Advantages:

• Mitigates risks of deploying new features and bug fixes
• Suitable for performance monitoring
• Swift rollback

Drawbacks:

• Slow rollout
• High costs as it requires doubling the resources
• Needs a way to switch between versions

Best for:

• Frequent changes and updates without exhaustive testing
• Mission-critical services
• Tight infrastructure budget
• Databases and environments with N+1 compatibility

A/B Testing

A/B testing involves running tests on different app versions to determine which one performs better or produces the desired outcome. Usage activity tracked from both versions provides invaluable feedback, helping you decide which features should stay and which ones should be dropped.

This approach adds extra functionality to canary continuous deployment, which routes users based on traffic weights, while A/B testing targets specific users based on various parameters.

Here are the parameters you can apply to distribute traffic among versions:

• Browser cookies
• Query parameters
• Geolocalization
• Browser version, screen size, operating system, etc.
• Language

Advantages:

• Testing several versions in parallel
• Control over the traffic distribution

Drawbacks:

• An intelligent load balancer is a must
• Requires distributed tracing to troubleshoot errors

Best for:

• Incremental improvements or updates that need precise data about user behavior
• Databases and environments with N+1 compatibility
• Teams with full control over the traffic distribution

Shadow

Shadow deployment involves running parallel copies (shadows) alongside live systems, splitting traffic between the existing version and a new one. Once it meets the stability and performance criteria, the new version is released to the public.

Unlike A/B testing and canary releases, shadow continuous deployment doesn't need user feedback to move forward. Instead, data collected from shadow versions are used as a diagnostic tool. However, this method requires extra resources (increased storage, computing, and network capacity) to run the two versions simultaneously.

Advantages:

• Testing a new version in production without affecting the public
• No impact on end-users
• Meeting stability and performance criteria before rollout

Drawbacks:

• Requires extra resources to run two versions simultaneously
• Quite complex to configure
• Some cases need mocking service

Best for:

• Data validation and real-world performance testing before code deployments
• Scalable infrastructure
• Flexible budget
• High performance standards

At some point after choosing a basic deployment strategy, you might need to reduce the drawbacks to zero, make releases more stable, and expand your pipeline capabilities.

Combining Strategies

Combining strategies is a great way to bridge the gaps and ensure stable releases. We recommend expanding the functionality of your continuous deployment pipeline gradually, introducing additional strategies one by one.

Let's look at some approaches to combine deployment strategies for the greatest benefit.

Ramped + Blue/Green

Ramped deployment combined with Blue/Green allows you to gradually increase the number of instances and reduce downtime with immediate rollback.

Use this method when deploying new versions or changing configurations, services, or architecture.

Positive flow:

Negative flow:

Ramped + Blue/Green + Canary

This combination gives you complete control over the release process: with the incremental rollout, testing changes in a controlled environment (Blue+Green), and monitoring performance before full deployment to production. Adding Canary to your continuous deployment pipeline helps you make decisions about rollback based on errors that only affect some users.

Positive flow:

Negative flow:

Ramped + Blue/Green + Canary + Shadow

By adding a Shadow strategy to the mix, you can check whether your changes were successful without affecting all users. You deploy two versions of the service: one without modifications and the other with specific changes visible only to specific users. It’s beneficial when you still support the old version of your app, but develop the new one to load with production traffic.

All traffic that passes through the shadow version is not visible to end-users, but the data collected about requests are transferred back to the production environment. This helps you compare "experimental" and normal behavior, enabling validation in high-load scenarios.

Ramped + Blue/Green + Canary + Shadow + A/B testing

Imagine that a new version of your app is partially ready for testing – but only for mobile app users. In this case, you need to test the new functionality without changing the current production versions. Adding A/B testing lets you analyze user behavior for specific features against various parameters.

With this approach, you deploy the changes safely while figuring out how multiple variables affect user experience in a controlled environment. The Canary part acts like a small "test gate" placed between the normal traffic route and the “experimental branch," so you can spot early signs of an issue before it becomes fully visible.

Once you get the hang of the tried-and-true approaches, you’re only limited by your imagination and the restrictions of your deployment process. As a result, you can tailor the strategy to your specific needs to leverage CI/CD practices.

Continuous Deployment with Techstack

There’s no ready-made solution when it comes to choosing the right continuous deployment strategy.

Understanding the pros and cons of each method is crucial for making an informed decision. By mixing traditional and modern strategies, you can achieve the balance that works for your specific needs. On top of that, you will mitigate risks and maximize your chances for success.

Techstack is a software development company with seasoned DevOps engineers and cloud developers on board. We help businesses get the most out of CI/CD and streamline their development process and time-to-market. Our DevOps case studies speak for themselves. Contact us, and we will choose a deployment strategy that perfectly fits your needs and budget.