Speaker 1: In this video, we're diving into the world of deploying code to production. Nothing beats the satisfaction of seeing our code go live to millions of users. It is always thrilling to see. But getting there is not always easy. Let's explore some of the common strategies. One of the earliest methods of deploying changes to production is the Big Bang Deployment. Picture it as like ripping off a Band-Aid. We push all our changes at once. This causes a bit of downtime as we have to shut down the old system to switch on the new one. The downtime is usually short, but be careful, it can stain if things don't go as planned. Preparation and testing are key. If things go wrong, we roll back to the previous version. Rolling back is not always pain-free, though. We still might disrupt users, and there could still be data implications. We need to have a solid rollback plan. Big Bang is sometimes the only choice, for example, when an intricate database upgrade is involved. Then we have the rolling deployment. It is more like a marathon than a sprint. With this method, let us incrementally update different parts of the system over time. It's a staged rollout where we gradually deploy the new version of the application to the production environment. Here's an example of how it might work. Imagine we have 10 servers running our application. In a rolling deployment, we might take down the first server, deploy the new version of our application there, and bring it back online. Once we've confirmed everything is working as expected, we'll move on to the second server, and so on. This approach allows the new version to gradually replace the old one, server by server, until the entire system is updated. One big advantage of rolling deployment is that it usually prevents downtime. While we are updating one server, the others are still up and running serving our users. Another advantage is that we can spot and mitigate any issues early during the rollout. This reduces the risk of widespread problems. We are only ever exposing a small part of our system to the new version at any one time. However, rolling deployment is typically a slower process, and while it reduces the risk of system-wide issues, it doesn't entirely eliminate it. If an issue slips past our initial checks, it might still propagate as we update more servers. This strategy doesn't support targeted rollouts. We can't control which users get the new version during the rollout. All users will gradually see the new version as we update the servers. We can't direct the new version to specific users based on criteria like location, device type, etc. Rolling deployment is a popular choice for many teams. It balances risk and user impact in a controlled, methodical way. Let's take a look at blue-green deployment. Here we maintain two identical production systems, cleverly named blue and green. At any given time, one side is active and visible to users, and the other side is idle. The active environment, say blue, serves the current live version of the application to the users. The idle one is our playground, where we can safely deploy and test the new version. Here's how it might work. When we have a new version, ready to go, we deploy it to the green environment. While this is happening, the blue system is still live and serving the current version of the application to users. Our QA team then tests the new version in the green environment. This gives us the chance to catch and fix any bugs or issues before they reach our users. Once the new version in the green environment is team ready, we simply switch the load balancer to redirect traffic from the blue environment to the green one. Users are seamlessly transitioned to the new version of the application with zero downtime. Now the blue environment becomes idle and serves as a safety net. If we encounter any issues with the new version, we can quickly switch back to the blue environment, effectively rolling back the previous version. While blue-green deployment allows for seamless transitions and easy rollbacks, there's a catch. Just like the rolling deployment, we can't direct the new version to specific users. The switch from blue to green happens for all users at once. It is also resource intensive. Maintaining two identical production environments doubles the infrastructure and resource needs. We could spin down the idle environment between deployments, but this introduces complexity. Managing two parallel production environments and ensuring seamless data synchronization can add significant complexity to the deployment process. It requires sophisticated infrastructure management and tooling. However, with its high level of control and minimized risk, blue-green deployment remains a popular strategy for smooth user experience and reliable rollbacks. Next up is canary deployment, named after the age-old practice of using canaries in coal mines to detect dangerous gases. If the canary was in distress, miners knew it was time to evacuate. Similarly, in software deployment, we use this strategy to test our air before the full-scale rollout. Here's how it goes. Instead of deploying the new version to all servers or users, we choose a small subset, our canaries. It can be a percentage of servers or a group of users, often selected based on certain criteria. For example, we might start by deploying to a single server, or a small cluster, or even a certain geographical location. This allows us to monitor the performance of the new version under real-world conditions, but on a much smaller scale. If everything goes well and our new version performs as expected, we can gradually roll it out to the rest of the servers or users. But if something goes wrong, we've got a safety net. We can halt the deployment, fix the issues, and try again, all without impacting the majority of our user base. This incremental approach gives us both safety and control. Canary deployment also gives us the power of targeted rollouts. Unlike rolling or blue-green deployments, we can direct our canary based on user-specific criteria like geographical location or device type. However, canary deployment does come with its own set of challenges. It requires careful monitoring and automated testing for the canaries. It requires somewhat complicated infrastructure tooling to ramp up or halt the deployment as needed. The strategy can be complex to implement and manage, especially when dealing with database schema changes or API compatibility issues. Canary deployment is usually not a stand-alone strategy. It's often combined with rolling deployment to create an approach that brings together the best of both worlds. Finally, as a bonus strategy, we have Feature Toggle. It stands a bit apart from the other strategies we've discussed. It's not about deploying a new version of the entire application, but rather about managing specific new features within the application. With Feature Toggle, we introduce a toggle or switch in the code for new features. This allows us to turn the feature on or off for certain users or circumstances. Think of it as a gate that we can open or close. It controls who gets to see the new feature. Feature Toggle can be used in combination with any of the deployment strategies we've discussed. Let's say we are doing a canary deployment. We can turn on the Feature Toggle for just the canary users, letting them test out the new feature while the rest of the user base carries on with the current version. Feature Toggle offers excellent control over new features and allows for targeted user testing. It's great for A-B testing or gradually rolling out a feature to see how it performs. However, Feature Toggle has its downsides. If not managed properly, toggles can add complexity to the code base and make testing more difficult. Old or obsolete toggles need to be cleaned up to prevent toggle debt, which can make the system increasingly hard to maintain. So there you have it, five deployment strategies, each with their strengths, challenges, and use cases. Remember, the best strategy depends on the application's characteristics and the user's expectations. Now it's over to you. Which deployment strategy have you used? What works best for your team? Let's discuss in the comments below. If you like our videos, you may like our system design newsletter as well. It covers topics and trends in large-scale system design, trusted by 400,000 readers. Subscribe at blog.bytebytego.com.