How To: Rolling Deployments with CloudBees Flow

CloudBees Flow was designed to enable teams to streamline and to simplify their DevOps processes - from the most mundane automation workflows to the most complex and large-scale scenarios. As part of that, we've set to revolutionize one of the most nail-biting parts of software releases: deployments.  Aiming to make this process as boring, repeatable and push-button as possible, CloudBees Flow boasts the industry's most robust deployment automation feature set, providing several out-of-the-box ways to deploy applications that are designed to take the stress, guess work, and complex, one-off, scripting out of the equation.

These include deployment options such as Smart Deploy , staging artifacts , and automatic error handling or process branching, as well as advanced deployment strategies and deployment policies such as rolling deployments, blue/green, canary, and dark launch . In the coming blog posts in this series, I'd like to describe some of the use cases for these deployment strategies, as well as step-by-step tutorials - which you can implement for your own deployments using our free community edition!

Why do we need advanced deployment strategies?

In most deployment scenarios applications are deployed by default to all the resources in the environment at once, and process steps are run sequentially. CloudBees Flow allows you to customize how an application is deployed in various ways, for example:

• When modeling a process, you can define the error handling method for a process step or use automated rollback.
• Before deploying an application, you can stage artifacts to ensure that all the artifacts are available at runtime, reducing the deployment time.
• At runtime, you can deploy everything (full run), deploy only changed objects (Smart Deploy), or specific objects (partial run), and/or Snapshots.

In some use cases, you may prefer to deploy the application in batches , instead of deploying to all machines in the environment at once. Why? because a phased approach is often safer -  to minimize possible service interruptions, or to test out new capabilities only on a sub-set of users.

As you get closer to Production environments and live user interaction and data, reducing risk and downtime when releasing newer versions becomes more critical. This is especially true with applications that service traffic 24/7 - where you can not afford (or even are legally prohibited) to take the application down for a longer 'maintenance window', or risk losing transactions from 27/4 customer traffic. In some cases, the applications are the backbone of the business - such as with online retail or banking/investment sites - and any downtime on the Production website can adversely affect the business.

This is when you'd consider phased deployments and advanced deployment strategies - such as Rolling Deployments, Blue/Green deployments, and more. CloudBees Flow can greatly simplify those for you, enabling even small teams to deploy like the Etsy and Netflix of the world, with just a few clicks. CloudBees Flow allows you to model these various deployment strategies and 'practicing; them throughout the pipeline- from the lower environments all the way through to Production, making this process routine and safe. In short: making even the most complex deployments scenarios boring :)

To demonstrate how to use these deployment strategies in CloudBees Flow, let's start by jumping in to what's considered the most difficult deployment pattern: Rolling deployments. Once you see how easy CloudBees Flow makes this, the others will be a snap!

Rolling Deployments

One way to reduce the downtime and the risk associated with application deployments is to use Rolling Deployments. In this pattern, the application is gradually deployed to the machines one at a time or in batches (depending on the size of the cluster).

The Rolling Deployment strategy is useful when:

1. The Production environment that you want to upgrade must remain on and continue to cater to real time end-user traffic at the same time
2. Often, when the Production environment is too large, so it may not be feasible/cost effective for you over-provision and create a clone of the entire Production footprint - across tens of thousands of servers - in order to deploy without risking processing requests in Production.

The diagram below shows an example of a Rolling Deployment in a load-balanced environment. When a new version needs to be added to both nodes, it is first deployed to one node while the other is actively handling the end-user traffic. After the new version is successfully installed and tested on the first node, the traffic is directed to that, while the second node is being upgraded. After the new version is successfully installed on the second node, both nodes can actively handle traffic.

Rolling deployment is an excellent strategy for reducing downtime when you have environments with large numbers of static resources. Note, however, that patterns requires thinking about backward compatibility across the application components, and what's your (automated) rollback strategy in case things go wrong in Production. As you'll see, it is recommended with all advanced deployment patterns to run a quick smoke test to verify that the new code is behaving as you expect, prior to rolling out the deployment across the entire environment. It is still one of the safest options, since even if you identify an error in Production, it is generally discovered when it still affects only a partial set of the nodes, and not the entire environment. Therefore, while you're working on rolling back or resolving the issue, the nodes in the batches that have yet to be upgraded are still active, processing requests with the previous stable version of the application.

CloudBees Flow natively supports Rolling Deployments out of the box. This means that instead of relying on heavy, brittle scripting and snowflakes processes, you can simply push a button and configure Rolling Deployment policies for any environment, leveraging them consistently release after release. For environments where Rolling Deployment is enabled, you can specify if it will be carried out as a phased-based or batch-based deployment.

• Rolling Deployment using phases:  Useful where there is a deterministic mapping between resources and the phase to which they belong. You can either assign resources to phases manually or dynamically using expressions.
• Rolling deployment using batches:  Useful for environments with large numbers of resources where deterministic mapping between resources and batches is not necessary/feasible.You can decide batch sizes by specifying a number or percentage per tier . For example, you can deploy at a pace of 2 VMs at a time for the Web tier, or to 25 of the resources at a time in the application server tier. You can also specify a property reference ($ ). This is useful when you want to apply a property reference to control the batch size based on applications, external configuration files, and so on.

---

How to set up Rolling Deployments in CloudBees Flow:

Since your application model is independent from your environment model or deployment process, you can enable Rolling Deployments either when you model an environment, or selecting this option when you deploy an application. In the below example, we're using Rolling Deployment to deploy to Production the "shopping cart" application of an eCommerce site. The application consists of three tiers: Web, App and DB and will be deployed to the PROD environment in four phases:

1. Deploy only to the DB tier and verify the DB upgrade.
2. Deploy to a few resources in the App and Web tiers and verify that the application was deployed successfully.
3. Deploy to a few more resources in the App tier based on certain rules.
4. Deploy to the remaining resources.

Here are the steps for modeling a Rolling Deployment for this use case:

1. Create the "ShoppingCart" application with three tiers that map to the corresponding components
2. Create an environment named PROD with tiers matching application tiers
3. Configure the PROD environment to support Rolling Deployment
4. Define the Rolling Deployment phases
5. Run the application on the PROD environment using Rolling Deployment
6. View the application deployments details

!  Note: If you're new to CloudBees Flow and the platform's object model and key areas of the application, you may want to start with this video  and our step-by-step in-product tutorials  (look for the Tutorials popup when you log in to the product).

---

1Creat the "ShoppingCart" Application

Create the "ShoppingCart" application with three tiers that map to the 3 components: App, Web and DB.

2Create the PROD Environment

Create an environment named PROD with tiers corresponding to the 3 applications tiers.

3Enable Rolling Deployment for the PROD Environment

Click on the Menu icon () in the upper right corner of the Environment Visual Editor, and select Rolling Deploy .

The Rolling Deploy dialog box opens.

There are two rolling deployment strategies that are supported out of the box:

• Phases:  preferred option when you want to control the resources and specify the order in which they are used.
• Batch Sizes:  preferred option when you do not need to control the resources. The resources are selected at random based on the specified batch size.

You can configure both these strategies on the environment, but only one can be active at a time.

4Define the Rolling Deployment Phases

In this example, the Phases strategy will be used during the Rolling Deployment. What you need to know about phases:

• Phases are ordered, and rolling deployment relies on this phase order.
• There are three types of phases:
  • Tagged:  Useful when you want to explicitly control the resources used during a rolling deployment
  • Expression:  Useful when you want to pick resources for a phase dynamically at run time using conditions. This is done using JavaScript expressions. This is useful when you do not want to tag individual resources and instead want to apply an expression to pick the resources.
  • Broadcast:  Can be used where you want the deployment to run on all the unused resources in environment.While not mandatory, the Broadcast phase will most likely be the last phase in the phase order. The Broadcast phase combined with the Expression will provide flexibility during the Rolling Deployment.There can be only one broadcast phase for an environment.

In this example:

• PHASE1 is a Tagged phase.
• PHASE2 is a Tagged phase.
• PHASE3-EXP is an Expression phase.
• PHASE3-BC is the Broadcast phase.

To add phases:

1. In the Rolling Deploy dialog box, click Phases to use phasing as the rolling deployment strategy.
2. In the Phases dialog box, click Add+  in the upper right corner to add a phase.
3. Enter the name of the first phase (PHASE1) and click Save .
4. Enter the name of the second phase (PHASE2) and click Save .
5. Enter the name of the third phase (PHASE3-EXP) and click Save .
6. Enter the name of the fourth phase (PHASE-BC) and click Save .

Remember: You can name the phases in your Rolling Deployment any name you want, such as Orange, Yellow, East, West, and so on. What is important when defining the phases is the order and type of the phases.

To assign resources to the phases:

• In PHASE1, you'll need to assign the only resource in the DB tier to PHASE1.
  1. Select PHASE1 from the list.
  2. Click Assign Phases to this Environment Resources . A dialog box showing all the resources across all the tier opens.
  3. Select the resources that you want for this phase, and then click Assign Phase in the upper right corner. For PHASE1, select the DB resource:
  4. Select PHASE1 .
  5. Click OK .
• In PHASE2, repeat the same steps described for PHASE1 and assign a few resources from the App and Web tiers to PHASE2.
• For PHASE3-EXP, enter an expression to deploy a few more resources in the App tier based on some rules:
  1. Select PHASE3-EXP and click  to define the phase with an expression phrase.
  2. Enter the expression phrase. For example, below is a simple condition that selects those resources that have resourceName equal to BR1 or BR2. Regular expressions and other properties on the resources, such as hostPlatform, can also be used to select the resources to add to a phase: var phaseResources = ; for(var i=0;i<resourceList.length;i++){ if(resourceList.resourceName == "BR1" || resourceList.resourceName == "BR2" ){ phaseResources.push(resourceList); } } return phaseResources;

     Note: When you click ? , a pop-up window opens and shows sample code for phase conditions.

  3. Click Save .
• For PHASE3-BC, click () to make this a broadcast phase to deploy to the remaining resources.
• Click Save to save the definition.

At this point, Rolling Deployment is enabled on the environment with Phasing as the default strategy, and Phases are defined as follows:

Note: This is an example setup explaining the available options. It is not necessary to use all the different types of phases. For your deployment, choose the phase types that apply to your use case.

5Running the Application on the PROD Environment Using Rolling Deployment

When you are ready to run the application, go to the dialog box to set the runtime settings for the deployment:

When you select the PROD environment, the option to enable Rolling Deployment is available because it was enabled for this environment. If you select another environment where Rolling Deployment is not enabled, the rolling deploy option will not be available. This way, the same application process can be executed in different ways based on the chosen environment, giving you the benefit of the model-driven approach.

Rolling deployment is now enabled.

Clicking the arrow icon to the right will show shows the rolling deployment details.

You can enable or disable phases, or insert a manual step after each phase. When you click Insert Manual Step after each Phase , the options to run the manual step and the field to assign users who can perform the step are available.

6Viewing the Application Deployment Details

Once the Rolling Deployment starts on the PROD environment, you can view the job details to see the breakdown and progress of the deployment. You will notice the job step breakdown corresponds to PHASE1, PHASE2, PHASE3-EXP, and PHASE3-BC. You will also see the automatically inserted manual step after each phase.

Note: Any phase that is skipped because there is no resource associated with it is not shown.

You can also use property references to access the current Rolling Deployment type or the iteration that is in progress:

• To return the Rolling Deployment type (phase or batch ), use $  .
• To return the Rolling Deployment iteration that is in progress (such as PHASE1 , PHASE2 , and so on for batch rolling deployment strategy or phase name for Phase strategy), use $  .

Summary

This example shows how to deploy an application to the PROD environment using the Rolling Deployment strategy and meet these conditions:

• The deployment ran in four phases.
• In the first phase, deploy only to the DB tier and verify the DB upgrade.
• In the second phase, deploy to a few resources in the App and Web tiers and verify that the application was deployed successfully.
• In the third phase, deploy to a few more resources in the App tier based on some rules.
• In the fourth phase, deploy the remaining resources.

Get started with CloudBees Flow and Rolling Deployments for free: