Type to SearchView Tags

Faster Release Cycles for Hybrid Enterprise Application Platforms
Jaydeep Chaudhuri Operations Director, Digital & Analytics | June 23, 2020
561 Views

Co-authored by:Deepti Gupta

Your DevOps journey to faster releases – Navigating a complex technology landscape of SaaS, COTS and Bespoke!

A typical large enterprise of today, is a complex weaving of SaaS (Software as a Service), COTS (Commercial Off the Shelf) and set of bespoke apps to produce customer journeys, insights and decisioning. While the choice of such a hybrid technology stack was to take advantage of enhancing and running a complex multi-dimensional business, automation across this stack must be hybrid and seamless now. Moving from clunky longer releases to a bi-weekly release across a varied stack is a dream and mission statement of the digitally competitive enterprises.

Business ask for agility and making new features quickly available to the customers is getting increasingly aggressive and CIOs often struggle to find a starting point to address this. There are some pertinent questions being asked to help drive the digital journey.

  1. How fast can we do DevOps?
  2. Can DevOps deliver based on one-click?
  3. How will DevOps across a hybrid landscape deliver on complex and changing business needs?
  4. Where do I start?

In this post, we will demonstrate how HCL’s Extreme Automation team has applied some outside the book techniques to enhance DORA (DevOps Research Association) driven maturity. Faster release cycles are now a reality across hybrid technology stack products/ enterprise.

Business Problem

We had taken up large agile transformation for clients having multi-technology stack product journeys with over 200 members that were delivering just twice a year and with poor quality deployments being a core issue.  We enabled them to release every 2 weeks with zero defects. This transformation was made possible by bringing in DevOps, a key influencing game changer, and applying DORA metrics.

Automation bottlenecks could lie across a stack of SaaS and other technology stacks e.g.:

  • CRM, Salesforce – Sales/ Service/ Marketing Cloud
  • Middleware - Dell Boomi/ Mulesoft
  • Content Management: Adobe Experience Manager
  • Front end: rendered via ReactJS, AngularJS frameworks

As a key part of the change, new feature development & deployment touching technology layers, with manual source-code management, manual packaging/ deployment would now focus on Continuous Integration/ Deployment based automation - while still leveraging some of the built-in DevOps offerings.

Example of Salesforce being SaaS (software as a service), and how the development happens within the Sandbox, code from different developers - merged manually, packaged and deployed manually to all the environments upwards to production. Sometimes, a minimal set of sandboxes makes it even more cumbersome for developers and reviewers to manage the code (manually), based on DORA metrics.

Across such a landscape, that consists of different vendor managed applications/ technologies, it becomes hard for features built to have an end-to-end requirement traceability.

This complete manual cycle results in:

  1. Lesser features getting delivered to business/end user.
  2. Inconsistent and unstable environments.
  3. Poor quality code reviews leading to defects and rework for teams involved.

Salesforce

Figure 1: Salesforce & Dell Boomi Build & Deployment Process Before DevOps (manual)

Here’s how we do it!

The Assessment

The journey, in a complex or simple state is all about a straightforward assessment across- people, process and technology.

Why better assessment is needed for modern Hybrid application platforms?

  • Not all enterprises have the same digital footprint.
  • Organizations have their own processes and standards.
  • Each of the SaaS and COTS is custom made by a third party and integrated in their specific way. There are very few rules, which apply to all as in the case of bespoke.
  • Bespoke is an easy territory, as it is like a self-authored book where the author doesn’t need to shuffle it much in order to locate something. Being managed by a third-party vendor, SaaS and COTS do not come with this flexibility and need specific attention when it comes to automation

A typical assessment should cover the As-is view of the processes for each key technology in the stack. Associating this view with the key DevOps pillars: Continuous Integration (CI), Continuous Testing (CT) Continuous Delivery (CD), Continuous Provisioning (CP), Continuous Monitoring (CM) and Continuous Planning, is the next step.  Outcome of the assessment helps in identifying the impediments to faster releases, leading to a clearly actionable 3-6-9-month plan-on-a-page.

The To be view is driven by the DORA metrics – the DevOps Research and Association forum that drives the metrics and classifies the IT organizations across the low, medium, high and Elite categories.

Salesforce

Figure 4:  DevOps Assessment Representation Across verticals

We chose this view for its simplicity and clarity and the next steps in the charter. This has been well received by the clients, with the statements like, “this gave me a more crisp and actionable view than hundreds of pages of report and presentations from the big 4 assessments that we had ordered for”.

Enable Code Versioning: This is the most complex and crucial step when enabling DevOps for any application. Focus on what developers are configuring/coding/deploying and their ways of working, to identify how the code and the artifacts can be versioned. By understanding the technical depth of the way development happens within SaaS, we came up with the mechanism to make the source code available in version control system. Having versioned source code is a lever for Continuous Integration (CI), Continuous Testing and Continuous Delivery.

Implementing high maturity DevOps

While third-party paid DevOps plug-ins and packaged apps are available, we explored and utilized the APIs provided by the SaaS solutions, built-in aspects, changed developer ways of working to implement CI/CD. For the enterprise example explained above, we performed following activities:

  1. SaaS -Salesforce
    1. Extracted metadata from Sandbox, stored it in GitLab (version control).
    2. Enable mechanism to merge code from different developers in automated environment – establish a future and scale proof branching/ merging strategy.
    3. Automated creation of deployable changesets stored in Artifactory.
    4. Trigger-based pipelines to deploy & promote changesets from one env to the other.
    5. Automated unit-testing, triggered automation testing pipelines.
    6. Automated Code coverage, code quality checks using Sonar.
    7. Established trigger-based pipelines to deploy, promote artifacts over environments.
  2. SaaS -Dell Boomi

    With source code completely managed within Boomi atmosphere, brought automation through DevOps to a completely manual process; leveraged Boomi provided atmosphere-based versioning and implemented Continuous Deployment (CD) using Boomi APIs.

    Salesforce

    Figure 2:  Build & Deployment Process After DevOps

What was the outcome (illustration from actual implementation)

  • Release cycle improved from once in 12-16 weeks to once in 3 weeks.
  • Test automation upto 88%.
  • No environment downtimes, or inconsistency.
  • Production release switchover time improved from average 4 days to 10hrs.
  • Quality checks with Sonar, improved code coverage > 90%.
  • End-to-end traceability of a feature delivery

Salesforce

Conclusion

SaaS & packaged apps need a different treatment to improve release cycle starting with a complete assessment. Continuous Integration & Continuous Testing pillars are the quick bites for maximum impact on yielding faster releases.

We recommend technology aligned CI pipelines and technology/ capability aligned CD. Additionally, in recent times, digital transformation of regulated industries, finance, pharma, insurance etc. has led us to provide Continuous Compliance as an offering - To facilitate faster feature releases, along with avoiding the need of creating, storing and managing millions of physical documents and records.