¶ IXL PremFina Platform
Our platform is built on “Microservices”. This means when we are releasing, we are releasing through components or services; rather than the full platform. Each microservice is built using the best of breed technology, tooling and has its own file system, logging and database appropriately. Any microservice is hosted on atleast 2 or more containers (with different nodes) or virtual machines and is load balanced to have high availability.
¶ Release 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 bring new technology, architecture and standards to have this on each of our microservices
- Minimum Impact - We operate on a basis of regular weekly releases (whereever possible). This minimises the impacts as changes are minimal. If things fail, it is also easier for us to roll back changes.
- 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 release so that we can continue pushing new funcationalities without our clients having to change their development. We only break backwards compatinility 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 migrates to the newer version.
- Environments sync - All releases happen on all our multi tenant environments. This is to ensure that all clients are up to date on the platform (or atleast have the chance to benefit from the latest if using our integrations-api); and 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:
¶ General Development Guidelines
All microservices, no matter what programming language they are written in…meets the following standards:
- Full HTTP/2 support with gRPC
- Concurrency, i.e. ability to execute multiple requests & tasks at the same time (an example of this is to be able to send 50 requests to an external microservice at the same time and continuing execution after all responses are received instead of sending the first request, receiving the response, then sending the second request, receiving the response and etc.)
- OpenAPI Specification File
- gRPC interface (server, stub & definitions) that handles all requests and forwards them for execution to the appropriate model
- JWT validation & permission checking
- Database connectivity with mandatory revision tables with full historical data that correspond to each data table
¶ Code Reviews
Any code that goes to development, staging and production environments is reviewed by at least 2 developers.
The people reviewing the code should have knowledge and experience in the programming language and other technologies used in the project. This means that, for example:
- Code for a back-end microservice is approved by back-end or full-stack developers, not by front-end developers or QA people
- Code for a front-end microservice is approved by front-end or full-stack developers, not by back-end developers or QA people
¶ Naming Conventions
To ensure uniformity amongst several projects, services etc, we have strict naming conventions.
Naming conventions are on the following
- Git Repositories for source codes and projects
- Jira Projects / Epics
- Database Names & Objects
- URLs and DNS names
- Request & response Arguments for APIs
- Slack Channels - for project related communications
¶ Source Code Repository, Checks & Security
- Two factor authentication on our source repository
- Locked “Development”, “Staging” and “Master” branches
- Pull requests (PRs) have atleast 4 eyes check and approval
- Merging into “Master” branch requires “Senior Architect” or “Head of Development” approval only
¶ Change Management & Workflow
Our change control and software development methodology is ‘Agile’ at all times. Depending on the platform projects, the #teampremfina adopts the best methodology (even if it means mixing and matching) to reap the maximum benefits and deliver fast.
No one “Agile” methodology is followed strictly. It is always what works best for a project.
Delivery of our platform features and functionalities, into production is the ultimate thing which matters (rather than having war and peace on documentation)
¶ 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 man 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 week; so that we know how it is shaping in reality (in production). This also avoids surprises last minute
¶ Change workflow
For more information about our change management, please
change@premfina.com