At Loyalty Juggernaut Inc. ("LJI"), we continuously strive to refine our product GRAVTY®, to provide our Users with the best of our services. We perform changes to cloud infrastructure, product software, and application software provided by LJI Services to maintain operational stability, upgrades, availability, security, performance and to ship new features.
For this, we use release management to create tasks into individually workable items like projects, stories, epics, and tasks. Once these work items are complete, we review, test, and approve these changes before deploying them to the Production systems. We strive to protect our Users from potentially disruptive or unacceptably risky changes by performing rigorous testing and approving those changes before rolling them out to Production.
Types of Changes
Typically there are two types of changes that go to Production:
- Releases are new product features and bug fixes.
- Infrastructure changes are related to cloud services, operating systems, databases, or any configuration affecting the internal services of GRAVTY®.
All these changes happen at off-peak hours to minimize the impact on businesses.
Roles
Technical Operations (TechOps/DevOps) teams are responsible and have required access for promoting the build to Sandbox and Production environments.
Releases
Our releases include new or incremental product features (either from the product roadmap or LJI User asks) and bug fixes. We follow the Agile methodology for software development, giving us flexibility in shipping small changes quite often as they mature. At the end of the Sprint, we have a shippable product with incremental changes. Before we deploy any releases to the Sandbox environment, we communicate new changes via the release notes to the LJI Users.
All these releases are versioned and have code/config changes. We use three-digit product versioning, e.g., X.Y.Z, and follow the well-known Semantic Versioning methodology. Each patch release is subjected to mandatory risk assessment to understand the impact better.
| Type of Release | Release Frequency | Release Contents | Possible Client Impact |
|---|---|---|---|
| Major Release (increments 'X' in the version) | Released every three months | These include new features that are part of GRAVTY®'s stated/committed roadmap | Two hours of downtime |
| Minor Release (increments 'Y' in the version) | Released every six weeks | These include a set of minor features that might involve enhancements to the data model and/or User experience and are always backward compatible. | One hour of downtime |
| Micro Release (increments 'Z' in the version) | Released every week on a need basis | These include critical bug fixes, micro enhancements with minimal impact radius. Any change to the data model is backward compatible. | One hour of downtime |
| Patch Release (increments 'Z' in the version) | Can release any day on a need basis | These include fixes to business show-stopper issues and cannot wait for the next micro release. These critical fixes are always backward compatible and have a limited impact radius. | 0 to 30 minutes of downtime depending on the nature of the patch |
Quality Checks
Strict and thorough Quality Checks is our way of ensuring that each release is of the highest standard. To do this, we:
- Ensure the verification of the features or fixes in the build by the QA
- Ensure the Automation certification for the regression sanity of the existing features
- Carry out the Code review or code-diff to understand the impact radius of the build
- Assess the Risks for the patch and minor releases to understand their impact radius
- Perform Static Analysis on the source code to detect and fix any security vulnerabilities
- Perform Software Composition Analysis on the source code to detect any vulnerable dependencies
- Carry out Dynamic Application Security Testing on source code after we deploy to the staging environment
- Perform a Vulnerability Assessment on the source code in the staging environment
After performing all these quality checks, we roll out the build to the Sandbox first and, later, to the Production environment.
Environments
Any new change for Production is pushed through internal and external-facing environments. Here, Development and QA environments are internal to LJI. The Sandbox is for integrations and UAT, whereas Production is exclusively for live LJI User data. This is how the development process works:
- When the feature development is complete, a build gets created and deployed to the Development environment.
- The build is then promoted to the QA environment for verification by an independent QA team.
- If the QA team verifies the sanity of the build and new features, the build moves to Sandbox.
- The build remains in Sandbox for 4 to 7 days before it goes to Production.
Infrastructure Upgrades
Infrastructure updates include operating system upgrades, configuration changes, security patches, etc. Upgrades to infrastructure components sometimes need a total downtime of that specific component. Such downtimes are communicated in advance and happen during off-peak hours to minimize any impact on businesses. Such changes are replicated to QA and Sandbox environment first before going to Production.