Jenkins is the way to finally bring a retail giant into the 21st Century

Faster Integration Delivery

Submitted By Jenkins User John Pope

This UK-based grocery retailer wanted to put automation first and foremost, ensure that they respected bespoke systems, and kept the learning curve to a minimum. They did it all with Jenkins.

Organization: Sainsburys Supermarkets Ltd., https://www.sainsburys.co.uk  

Industry: Retail

Programming Language: Java, Golang

Platform: Docker or Kubernetes

Version Control System: GitHub

Build Tool: Maven

Community Support:  Jenkins.io websites & blogs, Spoke with colleagues and peers

The flexibility for Jenkins was — and is — critical
to a large established retail organization.

Background: Our main challenges were as follows; 

  1. Automation first: There is no current automation from development to deployment. Moving to an automation-first principle, we wanted a pipeline that fit this need. 
  2. Bespoke needs: As a heavily bespoke internal/on-prem environment, with a number of 3rd party applications and integrated systems, we needed a development pipeline that provided the flexibility to ‘fit’ around these requirements as these are not going away anytime soon. 
  3. Minimize the learning curve: Yes, let’s t-shape, but do it smart! 
  4. Future-proof: What gives us confidence that we can achieve this? 
  5. Faster and regular deployments: Go faster…but how?

Goals: Our main goal was to provide a consistent platform for internal shared services at Sainsburys.

“Shared libraries were a huge benefit to us. Jenkins provides all capabilities to integrate easily with numerous mainstream and bespoke systems.”
John Pope, Cloud Engineer, Sainsburys

Solution & Results: 

We dealt with our objectives/challenges thus;

  • Automation First: We are already heavy users of GitHub, thus integration with that was a given need. Jenkins hooks into GitHub, meaning this was a quick win, with just a tiny amount of understanding of ‘how,’ there was no need for any tremendous upskilling — meaning developers could keep on developing as they had been!
  • Bespoke Needs: We found that the Jenkins pipeline provided ease of integration with other services like AWS, ServiceNow, CheckMarx, MS. Teams/Slack, to name but a few, either using open source plugins or some custom groovy/bash script. Using this aspect of Jenkins meant we could achieve this need.
  • Keep the learning curve to a minimum: A few of us already had some Jenkins exposure in previous roles; using Jenkins meant that we were keeping a narrower tech scope than, say, if we were to use a managed service like that provided by AWS/Azure, thus minimizing any learning curve required for this. Plus, learnings are always shared.
  • Future proofing (well, as best as possible!): We were moving toward a microservices architecture. Jenkins already had a proven history in this tech. Once again, this was a really easy argument to win. Using Jenkins in/with K8s opens up a whole world of functionality and future-proofing for many years.
  • Go faster: With Jenkins? YES, OF COURSE, GO FASTER!!

We used the following capabilities:

  • Shared libraries 
  • Kubernetes plugin 
  • OAuth plugin (for SSO integration) 
  • AWS plugins (S3, Credentials, Lambda, Secrets Mgr) 
  • Emailer plugin 
  • MS Teams plugin 
  • Cucumber reporting plugin

The results were overwhelmingly positive:

  • 100% confidence in a consistent and repeatable pipeline 
  • Faster deployment times – from 5 days to several minutes 
  • Easy onboarding for new applications 
  • Easy integration with bespoke systems

Like what you see? Share your Jenkins user story today.

Jenkins® is a CD Foundation project and a registered trademark of Software in the Public Interest, Inc. Copyright Jenkins 2020