Our Client, a leading retail company in the UK, aimed to turn their PoC theft prevention system into an estate-wide operation that would reduce losses resulting from unscanned merchandise in stores. Our DevOps Engineer stepped into the project and immediately took on the challenge.
Challenge
In 2023, one of the largest retailers in the UK, needed an immediate DevOps backfill with a two-week handover window. The project, an in-store theft prevention system based on image recognition, was in a proof of concept (PoC) stage with high expectations and typical pains associated with that phase of development:
- turbulent deployments,
- manual steps required for crucial operations,
- lack of resilience to networking issues.
The Client wished to stabilize, standardize, and automate the operational aspects of the project in preparation for the post PoC phase, when the solution was expected to roll out to hundreds of stores over the upcoming years. Without a more mature process, scaling out would not have been possible.
Solution
Our DevOps Engineer started out by acquiring as much knowledge as possible from his predecessor about the current state of things. He then divided the remediation into three sequential phases — each chosen to unblock the next and allowing for immediate improvements in the areas most important to the client.
Phase 1: Azure DevOps to GitHub Enterprise Migration
The first order of business was migrating existing pipelines from Azure DevOps to an internal GitHub Enterprise instance. This allowed the Client to lessen vendor lock-in and better adherence to the company matrix of approved technologies. Common elements were extracted to become reusable workflows and actions, ensuring a standardized approach to basic operations such as container building and scanning. Another benefit was security: deployments to stores could now be done from the confines of a secure internal network with much more control over firewalls, network hardware, and build agents. This migration was sequenced first because all subsequent modifications would require varying degrees of pipeline changes.
Phase 2: Configuration management: Ansible to Chef
Next in line was moving away from Ansible in favor of Chef. While again adhering to the technology matrix recommendations, this step provided the much-needed resiliency against network issues. While Ansible is a good and popular tool, it depends on a stable ssh connection for the entirety of its operation. This could not be guaranteed due to connectivity drops. Chef solved (or rather - bypassed) the issue by introducing a client-server architecture to configuration management. Now, the machine would only have to pull a set of configuration files, less than 1MB in total, and execute them locally – no stable ssh connection required, eventual consistency by design. This step effectively removed network issues from the equation with the exception of hardware failure.
Phase 3: Automated store onboarding pipeline
The last step was to automate the process of onboarding new stores. With anywhere from 1 to 20 stores being added to the project every week, and initial go-lives requiring the presence of deployment partners in stores for testing and training staff, there was no place for manual steps. Everything had to go through the same standard process of onboard -> deploy -> go live -> ongoing support. Our DevOps Engineer created a fully automated pipeline, centered around Chef, which is the cornerstone for reliably delivering the project’s functionality.
Results
At the time of writing (June 2026), the theft-prevention system is operational in 400 stores across the UK (and growing!). In just 2025 alone, it delivered 17M GBP of savings due to item non-scan detection.
Based on that success, the client decided to introduce the solution in another country of presence. Also, due to the project’s maturity, our Engineer is coordinating its handoff to the client’s central deployment team, so that it can be rolled out at the same cadence as other global services in the client’s ecosystem.
