Blue-Green Deployment with Azure DevOps and App Service

Blue/Green deployment is a deployment model in which we keep two production-like environments on active-active standby. In this case, one of the environments is always serving production traffic while the other one can be idle or be used for testing features. So, what happens, in this case, is that one environment always contains the latest code which needs to be in production while the other environment contains the older production code.

Getting the latest changes in production is as simple as swapping the DNS to point to the environment containing the latest code. Rolling back a deployment which doesn’t meet the expectations is as simple as rolling back to the previous environment containing the older production code.

Let’s discuss how we can use Azure Web App Deployment Slots and Azure DevOps Tools like Repos, Pipelines (Build/Release) to automate this process.

Azure Boards provides backlogs and work item tracking to help development teams collaborate and coordinate their work.

Azure Repos fires a trigger to launch a Build Pipeline. The Build Pipeline includes jobs and tasks that clone the repo, install tools, build the solution, and then package and publish artifacts to Azure Artifacts.

Release Pipeline is responsible for deploying the application artifacts to development, QA, and production environments. The Release Pipeline is organized into stages which, although executed sequentially, act independently of each other. In this scenario, the Dev stage deploys the application to a Dev environment. This environment is typically hosted in a non-production Subscription and may share an App Service Plan with other non-production environments such as QA.

Between stages, you use approvals and gates to control when the next stage is executed. This allows your team to perform testing and validation in each stage before moving onto the next.

Blue-Green Deployment, the staging slot represents your “green” deployment. The production slot represents your “blue” deployment. Once you validate that everything has been successfully deployed to the staging slot (i.e. green), the Prod stage performs a swap of green and blue. This makes the green deployment live for end-users and moves the blue deployment to your staging slot where it remains until you remove it. If problems arise with the new green deployment then you can swap again to move blue back to production.

Read more

Set up continuous testing for your builds using Team Services 2015/2017

We always want to find problems early after changes are checked in and built by running continuous tests using Visual Studio Team Services or Team Foundation Server.

This article explain how to set up continuous testing for your builds using TFS 2015/2017.

It is three step configuration process.

Step 1: Set up app deployment for your build
Step 2: Set up test deployment for your build
Step 3: Set up your tests to run with your build

Read full article –

I hope this will help !!!

DevOps – Commit to Git: Source Control in Visual Studio 2015

Since their 2013releases, Visual Studio and Team Foundation Server have offered out-of-the-box support for Git, the enormously popular source code management system that has upended many traditional options. To complement this source control option, Microsoft has added feature-rich front-end tooling for Git to Visual Studio. But how do you access and leverage these tools?

In this article, I’ll cover how Git differs from the source control technology that’s associated with Team Foundation Server (TFS), formally called Team Foundation Version Control (TFVC). Then I’ll delve into how to configure Git; how to create, connect to and work against a local repository (repo), including how to stage and commit changes; how to manage branches, including merging and viewing history; and how to connect to different types of remote repos, including how to sync changes.

Read full article –

I hope this will help developers who is looking forward to work with GIT.

Deploying SQL Server databases alongside your application just got easier

When the time comes to deploy your application and database changes, ReadyRoll and Octopus Deploy make a great team.

ReadyRoll is a Visual Studio plug-in that automatically generates numerically ordered SQL migration scripts for you, so that you take your schema from one version to the next.

Use ReadyRoll to carefully prepare your database migrations – column additions, stored procedure changes, SQLCR assemblies, or static data.

Add the changes to version control, and then use Octopus Deploy to automate the release of your database and application deployments, all in one process.

Read more documentation – Here

Hope this will help !!!

Octopus Deploy – Automated deployment for .NET

Octopus is a friendly deployment automation tool for .NET developers.

Octopus works with your build server to enable reliable, secure, automated releases of ASP.NET applications and Windows Services into test, staging and production environments, whether they are in the cloud or on-premises.

Build servers build. Octopus deploys.

You already have an automated build/continuous integration server. It compiles your code, and runs your tests. It might seem natural to make it execute your pre-production and production deployments too. Unfortunately, most build servers only offer a way to run a script, and leave it up to you to figure out all the details. That’s where Octopus comes in.

Build servers are great at:

  • Pulling code from your source control system
  • Compiling the code
  • Build-related tasks, like static code analysis
  • Running unit tests and tracking code coverage over time

Octopus is great at:

  • Distributing applications to all the remote machines, securely
  • Environment-specific configuration, like connection strings
  • Configuring IIS sites and installing Windows Services
  • Doing all of the above across many machines in parallel

Learn more about Octopus deploy –

I hope this will help !!!!!