Looking forward to 2020
Momentum is still building and now the team is working is on adding more features that will add greatly to the next sprint for funding coming soon. Take a look below and discover where and how the project is growing.
The team believes that now, in the heart of a bear market, is the perfect time to knuckle down and create the very best product.
GETTING READY FOR FULL DEPLOYMENT
The team has been working to build on the progress of the last few months. Our major focus has been the following three modules, which are the heart of the exchange:
- Matching Engine
- Order Entry
- Execution Data Feed
As we finalise each module, we are looking at the following key items:
- Features: Building additional minor features / functionalities to round off the module. For example, we have added another order type - fill or kill.
- Testing: Writing more automated test cases to ensure proper function.
- Protections: Building soft limits so that any potential issues are caught and contained before they escalate. One example of this is limiting the number of open orders a single user can have. We do not intend for any legitimate user to hit this limit, but we have put it in place for instances in which the user's trading bot malfunctions.
- APIs: Standardising the API structure inline with all other modules. For example, camel & snake case, naming conventions, input and outputs.
Administrative tools have taken a back seat since our last dev diary, and there is still more to do. We will get back to this soon and will give more details in the next dev diary.
CONTINUOUS INTEGRATION - CONTINUOUS DEPLOYMENT (CICD)
Earlier in the project, we built a basic CICD pipeline to manage how software is written, tested and then deployed. We felt that it was now time to redo the CICD pipeline. This was necessary due to the number of major architectural changes we have made, specifically relating to how software is deployed with our 1-click installer.
The objective is to create a development environment where lots of small updates can be made and then automatically tested. By making lots of small changes instead of a few major changes, we are able to catch potential bugs / issues as early as possible before they become a major challenge to solve.
Our exchange has a lot of moving parts, servers, containers, webservers, blockchain nodes etc. When an update is made to the codebase, we want to automatically push this update live and keep all parts of the exchange signing in tune. The objective here is to save time managing the deployment process, and it makes it easier to detect any unexpected bugs.
The goal of our CICD pipeline is to allow us to make fast updates to the exchange, and have these improvements immediately live.
3RD PARTY CLOUD DEPLOYMENT
Our CICD is currently aimed at deploying our platform onto our development servers. The next stage is to adapt it so that we can deploy into 3rd party cloud providers including: Google, Amazon and Microsoft.
Our current focus is on the Kubernetes system which is available on all major clouds. We are planning and making gradual changes so that we can easily transition everything onto either a public or private Kubernetes system.
In the last dev diary we discussed database replication and we are happy to announce that the replication facility is now complete.
With the data archive in place, we are now starting to build the previously published features on top of it.
Refactoring continues on all active modules to simplify our code and keep things as efficient as possible.
Thanks for being a part of our community!