If you’ve followed our previous content on Unified Commerce, then you are aware of the iterative model of continuous innovation in the context of retail digital transformation. It is all about continuous evolution across various customer channels, touchpoints and related backend applications in incremental proportions. It is followed by the ability to fail fast, learn faster and redo the cycle for better outcomes in each iteration cycle.

This blog series takes this que and is about a successful DevOps strategy and why it’s a critical piece for Unified Commerce’.

Problem statement (if we say so) – The ability to have a release methodology across application landscape that helps you go-live faster with development, QA and operations teams coming together and the ability to keep on learning for continuous improvement release after release.

Current Retail

 

 

 

 

 

 

 

 

So, all of this brings us to 3 important questions we must ask ourselves

1.What does DevOps for a retail ecosystem mean?

The ever-demanding customers and the barrage of experiences being rolled out to keep on wowing them have pushed retailers to derive the maximum out of their systems. The biggest hindrance to all this has been the ability to have multiple releases in short intervals (imagine a few years back thinking of a set of feature and fixes released every week).

The catch: “it’s a cultural change to the whole feature development approach and will require organizations to overcome inherent resistance to change because of the belief that it has worked so far”.

With a mix of applications in any landscape, there will always be what can be onboarded and what cannot. A good DevOps strategy will require identifying where to start and what to include. E.g. let’s say your Order Management System is on a subscription-based, cloud-hosted, 3rd party-maintained model with their own release cycle while your eCommerce is controlled by a release cycle you own, and both have a different tech stack. This essentially means, any feature for eCommerce which will require OMS to make certain changes will need to align with OMS release cycle and not eCommerce. Your DevOps process will need to ensure this is captured and accounted for when planning releases. Also, the tool and tech stack for release automation will need to account for each application’s tech stack capability.

2.Wasn’t some form of DevOps always there?

Yes, any release process you have is essentially a DevOps process. However, a true DevOps process works on complete or near-complete automation of release cycles across environments and true Continuous Integration and Continuous Delivery, while your current release process might be heavily manual.

3.How Much Automation is too much Automation?

Being the cultural shift that it is and given the possible realignment of required technical skillsets as well as investments, it’s important to avoid overkill.

Consider upgrading if the answer to any of the goals below is ‘yes’ –

 

 

 

 

So now that we have deliberated over these basic questions, let’s talk about the ‘how’ in brief.

Building a Stronger Retail Ecosystem Thru 4D-DevOps

The 4D approach is template oriented with a set of parameters that are grouped into logical categories that we call dimensions. In this part, we will concentrate on the 4 dimensions.

 

The 4 dimensions

 

 

 

Infrastructure Management and Automation-

  • Infrastructure Management
    • Dynamic environment provisioning (on-demand capability)
    • Availability of enough stable environment for dev, QA, pre-prod
    • Infrastructure as Code (IaC) – a developer should be able to build and run their own infrastructure including their environment necessities and operations team should be empowered to understand the product, identify the gaps and errors, whenever warranted. This ensures deployment setups are intact without any risk of environment drift in release pipelines
  • Automation
    • Every retailer has its own complexities and customizations, so it only goes to follow that their automation plan needs to be customized accordingly
    • Variety of tools and strategies available for each step in the workflow. Need to know which one works
    • Not all can be automated but what can be, must be
    • ‘N’ release automation – Unit to Integration QA

Release Management and Continuous Integration –

  • Release
    • Agile methodology
    • Containerization – bundling libraries and environments to achieve improved CPU/operational efficiency and scalability
    • Modularization of deliverables
    • Geography and scale
    • Upgrade planning and scheduling
    • Rollback/mitigation plan
  • CI
    • Must evaluate ROI with every release
    • Applicable for multiple developments, QA teams, geographies
    • Needs the right tool and tech stack

Continuous Testing –

  • Automated testing of every commit
  • Fail fast for faster feedback (parallel execution)
  • Provide metrics on development efficiency

Orchestration and Feedback –

  • Establish complete workflow
    • Build/deploy/release pipeline
    • Control mechanism – notifications/alerts
  • Meaningful metrics for actionable decisions (more details on next slide)
    • Process
    • Release
    • Performance
    • User
    • Operational

We will talk more about the 4D approach and dimension parameters that are required to design each of these dimensions in our next part of the blog.

Recommended Blogs

1.7-flavours-of-DevOps-implementation

2. Templated approach to DevOps

3.Role of Continuous Integration & Continuous Delivery in transforming DevOps

4. Challenges of CICD implementation and its impact on your business

Latest posts by Shifali Dumpala (see all)