Moving a Loan Origination Software maintenance towards a continuous integration

Insight Consultants have been involved in the design, development and ongoing maintenance of a leading loan origination system.

 

The LOS is developed on the Microsoft .NET Framework with ASP.NET MVC and SQL Server as the database server. It supports multiple customer instances, however, each instance has its own database. 

 

The application suite consists of the main Lender application, an API Layer and a Customer Portal. 

 

Before DevOps

 

The project code was hosted on Azure DevOps repos (TFS). There was no central “Main” branch. A new branch was created for each new release. As a result, there were a lot of branches in TFS and growing. 

 

There were also dependency issues between the 2 different components. Elaborate manual regression testing had to be done after each release to ensure that the new code did not break existing functionality. 

 

Deployment to both staging and live sites was done using traditional copy-pasting from the staging environment to the site folder. This process was tedious and error-prone since there were multiple bank sites and all had to be kept in sync (Currently, the Lender application has 17 sites, the API has 17 sites and the Customer Portal has 21 sites). 

 

When a new product extension was built, the process was to merge the maintenance branch with the feature branch. The merge process always resulted in heavy QA effort and processes even with automated test scripts.

 

The New Process

 

The code for the Lender application, the API Layer, and the Customer Portal was first migrated to Git.  Features are now broken into user stories and story points. Branches are created for user stories and merged with the main branch after development and testing. The emphasis is now on smaller and more frequent releases. This makes it easier to resolve merge conflicts that invariably occur when there are multiple developers working on different parts of the project. 

Certain common elements like the Data Access Layer that is used by all the 3 projects has been made into a NuGet package and hosted on Azure Artifacts.

 

This eliminates “Version Hell” since each branch can take the package version appropriate to it. 

Code merges are done using the Pull Request feature on Azure DevOps. This allows for code review and merges conflict resolution in the browser. 

 

Builds are done using Azure Pipelines. Since Azure Pipelines supply detailed logs on each run, it is easy to locate when and why a build fails. Currently, we have not integrated automated testing into the build pipeline, but we have plans to do so in the near future. 

 

Deployments to Development, Staging, and Live environments are also done using Azure Pipelines. We use reusable YAML templates to avoid repetitive code. Using these pipelines reduces deployment errors and speeds up the whole process as multiple sites can be deployed with a single click. It is also easy to roll back to a previous build if something goes wrong. 

 

Future Plan

 

We are currently in the process of integrating automated tests using xNUnit and Playwright (for E2E tests) into the pipelines. Once this is complete, the entire pipeline will be fully automated, and we will should be able to release a lot more frequently with complete confidence.

 

Contact Us

Address

USA

2117 Central Drive, Suite 101,

Bedford, TX – 76021

☏ +18178067966

INDIA

No. 924, 5A Cross, 1st Block, HRBR Layout, Bengaluru, Karnataka