Getting Started with Choosing the Right Deployment Strategy

Carlos Sanchez co-authored this chapter.

So far, we’ve performed many deployments of our releases. All those created from master branches were deployed to the staging environment, and a few reached production through manual promotions. On top of that, we deployed quite a few releases to preview environments.

The default deployment strategy

Nevertheless, except for in serverless deployments with Knative, we didn’t have a say in how an application is deployed. We just assumed that the default method employed by Jenkins X is the correct one. As it happens, the default deployment process used by Jenkins X happens to be the default or, most commonly used deployment process in Kubernetes. However, that does not necessarily mean that the default strategy is the right one for all our applications.

Should you be concerned about deployment strategies?

For many people, deploying applications is transparent or even irrelevant. If you are a developer, you might be focused on writing code and allowing magic to happen. By magic, I mean letting other people and departments figure out how to deploy your code. Similarly, you might be oblivious to deployments. You might be a tester, or you might have some other role not directly related to system administration, operations, or infrastructure.

Now, I doubt that you are one of the oblivious, chances are that you would not even be reading this if that’s the case. If against all bets, you do belong to the deployment-is-not-my-thing group, the only thing I can say is that you are wrong.

Generally speaking, there are two types of teams. The vast majority of us are still working in groups based on types of tasks and parts of application lifecycles. If you’re wondering whether that’s the type of team you work on, ask yourself the following:

• Are you in development, testing, operations, or some other department?
• Is your team focused on a fraction of a lifecycle of an application?
• Are you handing your work to someone else?
• When you finish writing code, do you give it to the testing department to validate it?
• When you need to test a live application, are you giving it to operations to deploy it to an environment?
• Or, to formulate the question on a higher level, are you only in charge of a part of the lifecycle of your application?

If the answer to any of those questions is “yes”, you are NOT working in a self-sufficient team.

Now, I’m not going to tell you that’s wrong, nor am I here to judge you. Instead, I’m only going to state that there is a high probability that you don’t know in detail how your application is deployed. As a result, you don’t know how to architecture it properly, you don’t know how to test it well, and so on. That, of course, is not true if you are dedicated only to operations. But, in that case, you might not be aware of the architecture of the application. You might know how the application is deployed, but you might not know whether that is the optimum way to go.

On the other hand, you might be working in a self-sufficient team. Your team might be fully responsible for each aspect of the application lifecycle, from requirements until it is running in production. If that’s the case, your definition of done is likely defined as “it’s running in production and nothing exploded.” Being on a self-sufficient team has the distinct advantage of everyone being aware of every aspect of the application lifecycle. You know the architecture, you can read the code, you understand the tests, and you are aware of how it is deployed. That is not to say that you are an expert in all those and other areas. No one can know everything, but everyone can have some high-level knowledge of most things while specializing in something.

Why am I rambling about team organizations? The answer is simple. Deployment strategies affect everyone, no matter whether we are focused only on a single aspect of the application lifecycle, or if we are in full control. The way we deploy affects the architecture, testing, monitoring, and many other aspects of our apps. These things are closely related and affect each other in ways that might not be obvious at first glance.

What to expect from this chapter

We already learned many of the things Jenkins X does out-of-the-box and quite a few others that could be useful to customize it to behave as we want. But, so far, we’ve ignored deployment strategies. Excluding our brief exploration of serverless deployments with Knative, we assumed that the application should be deployed using what strategy was defined in a build pack. Not only that, but we didn’t even question if the types of resources defined in our Helm charts are the right ones. We’ll fill at least one of those holes next.

The time has come to discuss different deployment strategies and answer a couple of questions.

• Is your application stateful or stateless?
• Does its architecture permit scaling?
• How do you rollback?
• How do you scale up and down?
• Do you need your application to always run?
• Should you use Kubernetes Deployments instead of something else? Perhaps, StatefulSets?

Those are only a few of the questions you need to answer to choose the right deployment mechanism. Answers to these questions won’t do much unless we are familiar with some of the most commonly used deployment strategies. Not only that, knowledge will help us choose which one to pick, but they might even influence the architecture of our applications.

---

In the next lesson, we will discuss which features we should expect from a deployment.