Edit

Blue/green deployments for applications on Azure Spring Apps

Azure Spring Apps
GitHub
Azure DevOps

This article describes a high-availability blue/green deployment solution for applications on Azure Spring Apps.

The blue/green deployment pattern involves keeping an existing version of an application live (called the blue version) while a new version of the application deploys (called the green version). This deployment allows you to restart, warm up, and test the new application version independently. After the new version of the application is running, you can switch to it and redirect any new incoming traffic to it. For the user of the application, the deployment of the new version happens without any visible downtime. Blue/green deployment makes it easy to abandon a new version without affecting the live version if a new deployment doesn't work as expected.

Architecture

The following diagram depicts the architecture for this approach:

Diagram that shows an architecture for blue/green deployment that uses GitHub, GitHub Actions, and Azure Spring Apps.

Download a Visio file of this architecture.

Components

This solution uses the following components:

  • Azure Spring Apps is a modern microservices platform for running Java Spring Boot and Steeltoe .NET Core applications. The service eliminates boilerplate code for running microservices and helps you quickly develop robust apps in the cloud. You can also use Azure Spring Apps to deploy code on a per-application basis.

  • GitHub is a code-hosting platform that provides version control and collaboration. GitHub provides Git distributed version control, source code management, and other features.

  • GitHub Actions helps you automate software development and deployment workflows from within a repository. You can use the platform to create a fully automated continuous integration and continuous delivery (CI/CD) setup. You can also use GitHub Actions to create environments for which you can configure rules like requiring reviewers.

Workflow

The solution architecture implements the following workflow:

  1. A developer makes a change to an application. The GitHub repository holds the app code that needs to be deployed to Azure Spring Apps. Every change to the app code happens under source control. GitHub completes the following tasks:

    • Ensure changes are reviewed.

    • Prevent unintended or unauthorized changes.

    • Ensure quality checks are completed.

  2. The GitHub repository also holds a GitHub Actions workflow to build the code changes and complete the necessary quality checks. After the code compiles, the GitHub Actions workflow deploys the latest version of the app code to Azure Spring Apps. The GitHub Actions workflow includes the following steps:

    1. Determine the current active production environment.

    2. Deploy the code to a nonproduction environment. If a nonproduction environment doesn't exist, create the environment.

      At this point in the deployment, the old (blue) version of the app in the production deployment continues to receive all production traffic.

    3. Wait for deployment review and approval of new app.

      This step gives the newly deployed app (the green version) time to start and warm up.

      Before approval, you can use the nonproduction URL of the app to verify the new version and ensure it's ready.

    4. After approval, switch the production deployment and the nonproduction deployment.

      All production traffic now routes to the new version of the app.

      Note

      If you reject the new deployment, GitHub doesn't switch the environments. The previous version continues to receive production traffic.

    5. After approval and traffic switch over, delete the old production deployment.

      This cleanup step produces a more cost-effective setup.

Alternatives

This solution uses GitHub Actions to automate deployment. You can also use Azure Pipelines or any other CI/CD automation system as an alternative. The sample provided in the Scenario deployment section uses Azure CLI statements as much as possible, so you can easily translate this setup to another automation tool. Use a CI/CD tool to set up an environment and create an approval flow on it.

This architecture uses Azure Spring Apps with Deployments as a target service. You can use Azure App Service staging slots as an alternative. A slot contains the new version of the application, which can be reloaded, warmed up, and tested before a slot swap is done. The slot swap puts the new version in production. This process is built into the service, so the setup is easy.

As another alternative, you can place any Azure service that hosts web endpoints behind a load-balancing solution. If you use this approach, you can spin up a second instance of the Azure service, where you can deploy a new version of your application. As a next step, you can create a zero-downtime deployment by switching the traffic at the load-balancing solution to the Azure service that holds the new version of the app. Keep in mind that this approach to blue/green deployment requires significant management overhead.

Scenario details

For some cloud applications, keeping uptime as high as possible is critical. One solution is to use a high availability configuration, which can double costs. Another solution is a disaster recovery plan, which brings up the application again in another region after an outage. The cost for the latter might be lower, but bringing the entire application online again takes time.

This article describes a process for ensuring high availability during the deployment of a new version of an application. In a traditional configuration, the new bits of the application are deployed to the service that's hosting the application. This configuration often leads to a reload and restart of the application. During that process, the application is unavailable.

This solution uses Azure Spring Apps to implement blue/green deployment and addresses automating the deployment of applications.

Potential use cases

This solution can benefit any organization that requires high availability. The solution is especially suitable for industries such as e-commerce and gaming, where downtime can lead to a loss of business and revenue.

You can further improve your availability by implementing zero-downtime deployments. For more information, see the Alternatives section of this article.

Considerations

The following solution considerations implement the pillars of the Azure Well-Architected Framework. This framework is a set of guiding tenets that can be used to improve the quality of a workload. For more information, see Microsoft Azure Well-Architected Framework.

Availability

This solution helps you maintain availability for your application during the deployment of a new version. It doesn't increase the overall SLA that Azure Spring Apps provides. Service failures on the platform can still affect your app.

If you want a solution to increase the overall SLA of your configuration, look into setting up a high-availability Azure Spring Apps service over multiple regions. In this approach, you front the configuration with a global load-balancing solution.

Scalability

This solution works on a per-application basis, so it's well suited for microservices applications. It also allows application teams to work independently of other application teams without influencing the uptime of the overall solution.

This solution also works best on a per-application basis, where each application has its own blue/green deployment workflow. If you combine applications in the same workflow, this configuration becomes complex quickly, so we don't recommend that approach.

Security

Security provides assurances against deliberate attacks and the abuse of your valuable data and systems. For more information, see Overview of the security pillar.

Apart from setting up repository permissions, consider implementing the following security measures in Git repositories that hold code that you want to deploy to Azure Spring Apps:

  • Branch protection. Protect the branches that represent the production state of your application from having changes pushed to them directly. Require every change proposal to be submitted as a pull request (PR). Use PRs to do automatic checks. Checks might include building all code and running unit tests on the code that a PR creates or modifies.

  • PR review. To enforce the four-eyes principle, require that PRs have at least one reviewer. You can also use the GitHub code owners feature to define individuals or teams that are responsible for reviewing specific files in a repository.

  • Immutable history. Allow only new commits on top of existing changes. Immutable history is especially important for auditing purposes.

  • Further security measures. Require your GitHub users to activate multi-factor authentication. Also, allow only signed commits, which can't be altered at a later time.

We also recommend that you deploy to only one Azure Spring Apps service. In a production setup, you should first test your code on other environments before you deploy it to production. Your production environment should preferably be in a different environment from your development and test environment.

For information about extra security for your Azure Spring Apps service, see Deploy Azure Spring Apps in a virtual network. If you implement the recommended deployment, you can't use GitHub-hosted runners. You need to use your own runner for the deployment workflow.

DevOps

Automation of this setup via GitHub Actions workflows increases DevOps productivity. One of the most useful features is the ability to quickly revert changes that behave unexpectedly. Just reject the new deployment.

Teams often manage multiple environments for the same application. It's typical to have several versions of an application deployed to different Azure Spring Apps services. The Git repository, which is the single source of truth, shows which versions of applications are currently deployed to a cluster.

Cost optimization

Cost optimization involves looking for ways to reduce unnecessary expenses and improve operational efficiencies. For more information, see Overview of the cost optimization pillar.

Use the Azure pricing calculator to estimate costs.

Azure Spring Apps has a Basic tier and a Standard tier. For details, see Azure Spring Apps pricing. When you use the blue/green deployment strategy, you pay for extra virtual SPU for only a short time, while your deployment runs.

GitHub offers a free service. However, to use advanced security-related features like code owners or required reviewers, you need the Team plan. For more information, see the GitHub pricing page.

Scenario deployment

For a sample of this configuration, see the Automated blue/green deployment for Azure Spring Apps applications GitHub repo. The repo also includes the steps for setting up your Azure Spring Apps service by using a Bicep template.

Contributors

Microsoft maintains this content. The following contributor developed the original content.

Principal author:

To see nonpublic LinkedIn profiles, sign in to LinkedIn.

Next steps