Build and Release Automation for Enterprise Retail Application
Azure DevOps automated software build, test and release pipeline for retail enterprise application
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.
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.
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.
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.
50% reduction in net application release time
Entire team is up to speed on release status
25% increase in the number of releases per month
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.
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 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.
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.
Multiple build agents hosted in Azure allow for code to be built and deployed quickly, even in a multi-team code contribution environment
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.
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.
Other Key Highlights
Every application build and release action is logged as part of pipeline execution, easing audit compliance checks
CI/CD implementation exercises the principle of least privilege by limiting the population of production approvers
We utilized SonarCloud for industry standard code quality checks, avoiding the need to stand up a SonarQube server
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
Provides a solid base for enterprise Agile planning, code Git repos and, most importantly, CI/CD pipeline automation development
Provides database storage, web app and processing services. In this scenario we utilized Platform as a Service (PaaS) assets.
A human-readable language often used for configuration files. As applied to CI/CD, we utilized YAML to define and script actions.