Door platform is modular; and we are building more “Microservices” which are all “Containerised”. This means when we are releasing, we are tryint to release via small components, modules or specific services; rather than the core platform at all times. All services (macro or micro) are hosted on atleast 2 or more containers (with different nodes) and is load balanced across Availability Zones to have high availability.
¶ Change Management & Workflow
Our product change control and software development methodology is Agile at all times. Depending on the projects, #teamDoor adopts the best methodology to reap the maximum benefits and deliver fast.
Both ‘Sprint’ and ‘Kanban’ - “Agile” methodologies are followed depending on the functionality/area of the platform.
¶ Change Goals
Agility (Speed) - Be fast to deliver the change
Change Changing requirements - We understand that requirements changes. We live in a world where requirements change very fast… as markets move, competitor landscape changes, innovation happens and technology improves
Delivery (Agile) - Gone are the days of waterfall model.
Communication (Cost / Speed / Chinese Whispers) - Avoid middle person communication. Transparency at all levels (End to End) model.
Iterations (Make mistakes faster) - Fail fast and get up fast. Don’t be afraid to make mistakes or take the plunge. Assess true showstoppers (
RED, 
Amber, 
Green)
Incremental (Break down things into smaller chunks) - Break a complex project or a large ticket into sub tickets, incremental changes and deploy every sprint; so that we know how it is shaping in reality (in production). This also avoids surprises last minute.
Delivery of Door platform features and functionalities into Production is the ultimate thing which matters (rather than having war and peace on documentation)
¶ Change Categories
| Category | Description |
|---|---|
| Trending | Anything trending in the industry |
| Value Add | Enhancements and change requests to add extra value to the business |
| Innovation | Looking ahead and futuristic. Building the product to the next stage |
| Regulatory | Regulatory compliance changes which are mandatory |
¶ Change workflow
¶ Deployment Process
¶ Goals
- Zero Downtime - Our releases are planned so that we have zero downtime (or as minimum as possible). This obviously is dependent on the architecture of the component being released. As a result, our teams are continuously bringing new technology, architecture and standards into the platform & process
- Minimum Impact - We operate on a basis of regular 3 weekly sprints (whereever possible). This minimises the impacts as changes are minimal. If things fail, it is also easier for us to push in hot fixes.
- Backwards compatible - Our teams try and ensure that all releases are backwards compatible as much as possible. This is so that if clients/users do not want a certain change, the new change do not impact existing processes. This also holds true for our API releases so that we can continue pushing new funcationalities without our clients having to change their development. We may only break backwards compatibility on major API version (e.g. from 1.x.x to 2.x.x); and will continue to support the older major version until our last client/partner migrates to the newer version.
- Environments sync - The production release happens on Prod, Demo, Support so that it is easier for team DOOR to keep the features/issues in sync while demoing or supporting our partners and clients. The platform is a single code base; thus allowing all our clinets tp benefit from all the changes, features and bug fixes.
¶ Branching & Single Code Base
The following diagram illustrates the process that we follow for software development with respect to branch & repository management:
For more information about our changes, please
change@doorfunds.com. For DOOR’s change management policy, please click here.