Build and Release Automation for Enterprise Retail Application

Azure DevOps automated software build, test and release pipeline for retail enterprise application

The Overview

This national retailer operates a network of retail outlets marketing multiple product brands along with a vibrant online transactional storefront. This large organization is regularly challenged by providing logistics for a massive existing user base and high traffic growth through their supply chain and storefronts. Organizational expansion through organic growth supplemented with acquisition is highly relevant to their ongoing operations.

  • Industry

    Retail

  • Technology

    Azure, Azure DevOps, Microsoft Cloud, YAML

01

The

Challenge

The client’s mission-critical enterprise application had been built and released manually for several years.  After a series of release-associated outages and reduced ability to release following engineering staff turnover, IT leadership moved to implement both continuous integration (CI) and continuous deployment (CD) to smooth their software delivery.  Manpower reductions and production exceptions made automation the only real solution to the audited and reliable deployment of their application.

02

The

Solution

Financial compliance requirements such as PCI and public company controls for SOX compliance added importance to the required precision of system construction and release execution.  MercuryWorks engineers designed a best practice continuous build and release pipeline including the challenge of some unique audit-related testing scenarios.  Since the client was already an Azure shop and user of Azure DevOps for code repos and boards, Azure DevOps pipelines were a natural match for their CI/CD endeavors.

03

The

Results

The resulting CI/CD pipeline took an enterprise application from a manual two to three hour build/debug/package operation (that often resulted in re-releases due to “forgot to configure that correctly” errors) to a rock-solid automated process that runs well under an hour.  Not only did this solution fit the need for this critical application, the resulting pipeline strategy and implementation now forms the base pattern for the client’s subsequent release automation endeavors.

Faster Deploys

50% reduction in net application release time

Better Visibility

Entire team is up to speed on release status

More Releases

25% increase in the number of releases per month

Quality Increase

Automated tests results in 15% fewer re-releases

The client’s resulting build and release pipeline reflects a classic gated automation process.  Initiated by a commit and approved PR to the code repo’s mainline, Azure DevOps builds the application and executes testing and validation processes.  Provided the build validates, release processes automatically trigger and move the application through Dev, Stage and Prod environments.

.NET Development

Push Button Release

While the build and release to the application’s development environment is automatic and frequent (each approved PR into code mainline kicks off the automation), promotion to Stage and Prod environments requires a human “push button” approval.  Azure DevOps enforces a limited set of users who are approved to release to these higher environments.

Automated Testing

Automated unit tests run as part of each automated build, followed by execution of integration and functional tests.  Provided all tests pass, initial deployment to Dev occurs and subsequent integration and functional tests are automatically executed.  Following a full pass of this final testing, release approvers are able to deploy to higher environments.

Continuous Deployment to Azure Infrastructure

This diagram illustrates the Azure topology the deployment automation needed to deploy to.  In addition to the literal distribution of the client’s application, there are several other key outcomes.

Serverless

The client’s topology diagram is conspicuous in the absence of virtual machines.  The application’s supporting infrastructure is thoroughly PaaS (including the data tier) which eased the number of steps and execution for automated release.

Distributed Build Agents

Multiple build agents hosted in Azure allow for code to be built and deployed quickly, even in a multi-team code contribution environment

Build and Releases Targeted to Code Branch

Targeted builds are based on the code branch where work has been committed (for instance a feature branch vs mainline).  This allows for specific environment releases; PRs will always result in a build but the end destination to production will depend on the code’s branch.

Performance Testing and Linting

Code linting automatically checks source code (back-end and front-end) for programmatic and stylistic errors.  In this case dotnet-format, clang-format and esLint run on each pipeline execution with thorny lint checks blocking release.

Even More

Other Key Highlights

Release Auditing

Every application build and release action is logged as part of pipeline execution, easing audit compliance checks

Least Privilege

CI/CD implementation exercises the principle of least privilege by limiting the population of production approvers

Serverless Quality

We utilized SonarCloud for industry standard code quality checks, avoiding the need to stand up a SonarQube server

Azure Monitor

We also implemented Azure Monitor to provide conditional alerts for user-impacting performance and availability

"Automated build and release is table stakes these days for enterprise applications, whether on premises or in the cloud. We were already in the cloud but definitely in need of enterprise DevOps tooling and processes - MercuryWorks delivered in spades."

Director of Applications

Behind The Curtain

Core Technology

Azure DevOps

Provides a solid base for enterprise Agile planning, code Git repos and, most importantly, CI/CD pipeline automation development

Services

Microsoft Azure

Provides database storage, web app and processing services.  In this scenario we utilized Platform as a Service (PaaS) assets.

YAML

A human-readable language often used for configuration files.  As applied to CI/CD, we utilized YAML to define and script actions.

Want brilliance sent straight to your inbox?