If you’ve followed this blog series, Part 1 and Part 2 talk about DevOps, its relation to the retail ecosystem, and the 4D approach to it. Besides, it also discusses the defined parameters that are required to withstand the continuous and accelerated development releases.

The concluding piece of this series shall talk about the concepts of story management, branching, CICD, and the high-level plan of action post-build. The development and release cycle, processes, the relevant monitoring metrics of what the development and operations teams require in their daily routines shall be integral to this blog.

Process

A good strategy requires a robust process. A good process design ensures that an organization finds faster gap resolution methodologies. Some of the crucial factors are:

  1. Including the business team as stakeholders
  2. The process should aim to complement your team structure and not hinder. For example, feature releases must include application team(s) that can come under the same release cycle or break a feature down to accommodate the team cohesiveness. Having a release in production with the feature but not making it live is an unnecessary effort
  3. Must ensure that QA and Ops team are onboarded from the beginning and not later in the release cycle. The cost of quality and maintenance transition shoots up due to inadequate planning
  4. There are challenges to adopting practices like TDD (Test Driven Development) and BDT (Behavior Driven Testing). But like all other processes, you can tune its adoption to fit into the scheme of things. And proper implementation will bring in recurring benefits
  5. Regression testing is crucial. The quality must align with the criticality of the application. For instance, is the app financial, revenue-generating, healthcare-related, or a human resource procedure? In each of these cases, there would be different levels of risk with limited availability of regression testing
  6. Maximum automation is necessary but observing mindfulness is essential. Thus, automation should only happen in areas that have a business requirement
  7. There should be a continuous improvement that involves a thorough analysis of the deliverables. A synthetic script or fake user can simulate near production and find the issues before the go-live happens
  8. Define clear monitoring metrics as part of your adoption process and find the right KPI to tail

A few aspects within the development that accelerate the success of adopting DevOps include

  1. Efficient story management
    1. Common sprint board to centralize feature releases for development
    2. Each feature into multiple tickets for each sub-team (eComm, mComm, Integration, etc.)
    3. Break each new feature for the smallest development period for a faster release cycle
    4. Plan for dependent and sequential features
    5. Discuss features, not tickets in scrums
    6. Have Scrum of Scrums
  2. Code and test script branching
    1. Maintain a stable branch of code with no developer accesses
    2. Source code for each application can be separate. But the branching strategy should be general and common for all feature/application teams
    3. Each feature in sprint has a new short-lived branch for each application that requires a change
  3. CI/CD
    1. All commits, inclusive of merges, to any of the pre-prod branches should trigger CI/CD pipeline (i.e., build, test, deploy and test)
    2. The deployment can happen for each of the application’s environments
    3. All build and deployment must be automated (using a variety of tools based on the existing skillset and convenience)
  4. Post-build process – Have CI/CD pipeline also run the following
    1. Unit tests
    2. Static code analysis
    3. Automated regression tests
    4. Automated performance tests
    5. Automated security analysis

A sample recommended branching that we propose can look like this 

 

Control

The success of DevOps depends on choosing the right KPI. Taking a cue from the same, we can classify DevOps metrics into five categories. Among those five there are some indispensable KPIs. The proper capturing of these metrics can accurately represent the DevOps performance along with the corrective actions. It should align with the Unified Commerce approach of analyzing your deliverable and putting it back in the system with course correction for an intuitive learning-enabled journey.

 

Conclusion

The process above is neither exhaustive nor a comprehensive process guide. But it focuses on some of the key factors that you must consider before adopting a DevOps strategy.

We believe that this blog offers key insights about the role of DevOps in some of the Retail digital transformation programs like Unified Commerce. However, any successful iterative programs must comprise a harmonious synergy of a robust strategy, rich processes, advanced technology, and the right tool stack.

DevOps is the perfect pathway to embark upon digital transformation programs.

Recommended Blogs