Full Stack JavaScript Strategies

Chapter 25. Making Deployments

Now that you have integration testing in place, it’s time to decide when you want to do deployments and what the strategy behind them should be. Every deployment you do is meaningful to someone, whether it’s the dev working on a change, a QA engineer doing feature and regression testing, stakeholders taking a look at things, or your end users. Each deployment also affects something else. When you push changes to the backend, it’s going to affect the frontend even if it’s indirectly. Pushing frontend changes affects anyone who works with the product through that part of the app.

Having a strategy and understanding the timing around deployments are essential to avoiding surprises. When you roll out changes, that affects the organization and your team’s reputation for quality and reliability. These are some of the things you have to think about. It can be easy to consider your job done as soon as all of the code changes have been merged, but this is the beginning of one of your more visible jobs.

In this chapter, I’ll cover:

• Frontend-only or backend-only updates

• Blue-green deploys

• Canary deploys

• Strategies for doing rollbacks

Just like you had to consider a lot of “behind the scenes” things for the initial development across the full stack, you have to do that with deployments, too. This is the planning part of the deployments from a holistic view. When you were building the app, you made sure everything worked with your tools and technology. ...