What is an SDLC?
The Software Development Life Cycle (SDLC) is the process followed to build software. There are various methodologies – from Waterfall to Agile – being used today. 

What do we follow at WealthOS?
We follow the Agile methodology with a strong DevOps focus. We carry out a rigorous build, test and deploy process to continuously integrate and deliver features to you.

What does this mean for you?
The process we follow at WealthOS allows us to deliver fully regression-tested features into your environment continuously, as you sleep, keeping your platform up-to-date. We have a host of automated processes and manual checkpoints in place to ensure that we can introduce change at pace without regressing or breaking backward compatibility - i.e. no impact to you. Further to this, we also use deployment-time feature flags to mask features that are in progress or features that you are not ready to use right now, ensuring you see no unwanted changes at your end.

If you are interested in a bit of history about software development life cycles, read on. If not, skip this bit and jump straight into what we do at WealthOS! 

Introduction to SDLCs
The Software Development Life Cycle, or SDLC, is a process that has been used in the software development industry for many years to guide the creation of software. The process has evolved over time and there have been several different models used in the industry. These are a few of the significant models.

Waterfall Model: considered the first SDLC model. Introduced in the 1970s, this is a linear sequential approach to software development. It involves a series of phases that must be completed in order, including requirements gathering, design, development, testing, and maintenance. Used extensively in enterprise fintech software development at one point, the methodology is time intensive and does not contribute towards collaborative work. This has resulted in most modern software development moving away from this methodology. 

Spiral Model: introduced in the 1980s as an alternative to the Waterfall Model. It is an iterative approach to software development that emphasises risk analysis and management. The model involves a series of cycles, with each cycle consisting of four phases: planning, risk analysis, development, and evaluation. While this model promotes early identification and management of risk, complex software, the high degree of planning required and heavy documentation requirements make this model less attractive for complex platform builds.  

Agile Methodology: introduced in the early 2000s as a response to the limitations of the Waterfall Model and other traditional SDLC models. It prioritises collaboration, flexibility, and adaptability. Agile methods are based on the principles outlined in the Agile Manifesto, which emphasises individuals and interactions, working software, customer collaboration, and responding to change.

DevOps: it is a relatively new approach to software development that emerged in the mid-2010s. It combines development (Dev) and operations (Ops) and emphasises collaboration between these two teams. The goal of DevOps is to improve the speed and efficiency of software development and delivery by automating the process and breaking down silos between development and operations teams.

WealthOS SDLC
At WealthOS we follow a rigorous build, test and deploy process to continuously integrate and deliver features to our clients. We also have a host of automated processes and manual checkpoints in place to ensure that we can introduce change at a pace without regressing or breaking backward compatibility. We also use deployment-time feature flags to mask features that are in progress or features that a client is not ready to use right now – i.e. ensuring there is no impact on our clients. 

Build, Test and Deployment Process

• We follow an agile methodology with a strong DevOps focus. We carry out two-week sprints, focused on delivering a meaningful output at the end of each sprint.
• We maintain a Product roadmap and a Technology roadmap.
  • The WealthOS Product Roadmap is built and regularly refined based on regulatory requirements, market trends and client demand. The VP of product management is accountable for maintaining this roadmap.
  • The WealthOS Technology Roadmap is built and refined based on best-in-class practices in B2B enterprise technology, internal R&D, changes in enterprise wealth-tech trends and client feedback. The Lead Architect is accountable for maintaining this roadmap.
• Once a roadmap item is designed, documented, broken down into user stories and reviewed, these stories are prioritised and selected for a sprint by the scrum master.
• Developers build features in feature branches, and after rigorous dev testing and reviews (self, peer and lead reviews when needed), these features are merged into the develop branch. Sonarcloud and Snyk are used here to capture any vulnerabilities, code smells, security threats etc. 
• A unit and component test suite runs automatically on each code merge, and any identified issues are fixed immediately by a rostered developer.
• Frequent build-and-deploy cycles are run (currently once a day) where the develop branch is deployed in the Integrated Test Environment. Once deployed, an integration test suite is run automatically. Any failures will be immediately fixed by a rostered developer. 
• Test engineers will test each intra-sprint internal build using a combination of manual testing and automated test scripts for new features. The Regression test suite automatically runs on the deployed code frequently (currently once a day for the mini-regression suite, and once a week for the full regression suite) to ensure no features have regressed. 
• Bugs are triaged, and prioritised bugs will be fixed in the development branch and available for testing in the subsequent internal build. 
• Once lead-level approval is obtained, a release is built and deployed into the sandbox. Features that are not ready to be released will be masked behind deployment-time feature flags.  
• Once a release is deployed into Sandbox, test engineers will run a regression on the Sandbox environment. 
• This process allowed us to build and test a complex feature like multi-pot portfolio rebalancing in just three sprints.

Read the original article here.