There are four key dimensions in regard to how we host and isolate customers and our customers can isolate their applications when using Build.One:
- application at run time
- database
- infrastructure
- development
For the application when running the code can isolate different users and applications within one instance of Buid.One. Fine grained RBAC (Role-based access control) allows for this.
When data is stored in databases or file system, the database has the ability to introduce isolation by setting up unique databases for each application. This is preferred to just creating prefixed tables in s single database. Multiple databases can be operated in one database management system. Today we use in Portal the Progress OpenEdge PASOE technology to introduce multi-tenancy, as used in Create tenants for HoX
On the infrastructure you can use above to deploy a system for multi-tenant use, meaning multiple users that do not even know each other are securely isolated through application code and database and persistence isolation (files and folders or any other storage technology), that they can operate all on the same single environment hosted on a single system. An example is portal.build.one, many Build.One users that have administrator rights can use it to create demos and HoX where a new tenant is created to assure each set of users is not interfering with others, see above that means they are able to logon and follow the runbook Create tenants for HoX . The alternative setup is what many of our customers need to assure further isolation, especially when it comes to networking into their core systems and setting up private networks or being able to schedule updates on their own, then a standalone setup is needed. Here still the same application code and database technologies are used, but by convention we put the customer on a single dedicated installation, e.g. hydro.build.one
For the development we have currently three key efforts which are hosted on BitBucket:
- SWAT - our core framework
- OFFER - an addon to SWAT for creating offers and building highly customizable CPQs
- DocXFactory - a Microsoft Office docx format template engine to create high fidelity complex docx renditions
Internally Build.one developers work on each, the code is hosted in repositories. To assure developers do not mess up their colleagues work in progress, they create feature branches, these are ideally short lived and when a feature or bug fix that is developed in this branch is done, code is merged back to a main branch. Our team uses a complex branching methodology, an introduction on workflows can be found here https://www.atlassian.com/git/tutorials/comparing-workflows
Our customers need their own repository, meaning it is in their authority to accept changes and they govern access to it. So it is a copy of what we have in SWAT or OFFER repository and then updated over time, though the authority lies with the customer.
We often utilize the OFFER as the base, which we initialize a new repository for them with it. E.g. we created a new repository for IGUS in https://bitbucket.org/build-one/igus/ now the IGUS developers or the partner they have will decide on their own branching strategy and when they pull in updates from SWAT and OFFER. For the IGUS example the PoC code was then deployed to https://igus-develop.demo.build.one/ we call this a stand alone environment, as it was stood up only for IGUS customer.
To sum up on single tenant and its relationship to standalone environment:
A "standalone" is an instance of an application deployed onto a portainer stack. If deploy n number of instances of an application, each instance is a single tenant. So, for example, offer, ln-test and portal are instances of the offer application However, each portal instance is also MT enabled, so one instance can "serve" multiple clients Any application that creates code or new screens will need a separate git repository as these changes are relevant only to that application hydro, maisel, dataforce, igus are all examples of apps that have custom code and screens These apps also have "standalone" instances, using the hydro, maisel, dataforce, igus images that are built as part of the CI/CD pipeline.