Case Study – Fintech Product Company
A Fintech product Company offering a wide range of products provided DevOps Enabler & Co. with an opportunity to implement SRE on the Public Cloud and DevOps on some of their most complicated products. Some of the major challenges of the product were the following:
Outcomes
- Near Zero-touch Deployments with absolute error-free. End-to-end automation of the process and environments are provisioned on the go.
- Onboarding a new client has been drastically reduced from a week to a matter of minutes.
- Common Process Template for the entire organization, increasing Sprint Visibility at the Senior Management level.
- A well-defined Branching Strategy increased the efficiency in maintaining repositories and branches and reduces merge conflicts and other human errors to negligible.
- CI/CD process is completely present which increases the ease of testing newly pushed code in live environments (Dev, QA, UAT) which reduces the complete manual effort to build, version, track and deploy code across all three environments.
Challenges
- No Proper Process Template
- Repository System
- Naming Convention
- Tagging
- Lack of Folder Structure
- Branching Strategy
- Branch and PR Policies
- No Continuous Integration
- Manual Build Process
- No Automated Testing
- No Continuous Deployment
- Manual Deployment
- Prone to Human Error
Solution
a) Creating Process Template:
After completing the discovery phase, the DevOps team was able to document the differences in Work Items across all the products. After analyzing the differences, DevOps Team created a Process Template to cater to all the needs of all the products.
- Versioning,
- Naming Convention
- Folder Structure
- Tagging
b) AWS Console Architecture Overview:
The above snippet is a very high-level architecture of the client’s AWS Console setup. There are two main blocks – one is of the common components (Elastic Beanstalk and SQL Server) which are common to all the clients and the other block is the client-specific components (VMs with SQL Server hosted on them.)
All these resources are constantly monitored by AWS CloudWatch and alarms are set to note if something unusual occurs.
c) Branching Strategy
Whenever there is a new Sprint requirement. TL creates a new Sprint branch and from it, further feature branches are created and allocated to Junior Developers. Once the development at the feature level is completed the developers can raise a PR to the Sprint branch, post-testing (after completing the CICD process at Dev/QA/UAT level) the Senior Developer can raise a PR to master. Once in master, the code passes a couple of approvals and finally gets deployed into the client’s environment.
To handle any Hotfix, the senior developer creates a Hotfix branch from the master. A developer is assigned, and once development is completed the developer raises a PR to the Hotfix branch after all the checks are passed, another PR is raised to the master and after passing all the pre/post-deployment checks, it gets deployed into the client’s environment.
d) CI/CD Pipeline Overview:
The above snippet depicts the flowchart of the end-to-end CICD process (Focusing Deployment on Prod.) Once the developer pushes the code into the Sprint Branch, it would trigger the respective Jenkins Pipelines, which would generate build artefacts, and finally deploy those artefacts into Dev, QA, and UAT environments where testing at different levels can be carried out.
After successful deployments across all three environments, the senior developer can raise a PR to master. If all the PR policies are met the code gets merged into the master,
similarly, the code gets built and deployed into the Production environment, after passing through the pre/post-deployment checks. In case there is a deployment failure, automated rollbacks are available.