You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
At present, the process for standing up the demo clones the source code of the various repos for the business logic components (Incident Service, Process Service, Alert Service etc...) and stands up a Jenkins instance on the OPenShift cluster to build them.
There are a number of issues with this approach
It takes longer to provision because these builds need to complete
It is less stable as there is a potential for these builds to fail
You get whatever is at the head of master, which may not be stable/correct for your use case.
As an alternative to this, we should introduce CI/CD jobs for each component which will build the various services and push them to a quay.io registry. We can then create a flavour of the installer (via config params and variables for what version of each image to use) which will use these images rather than building from source.
This will allow us to cut the time to provision as well as be able to ensure that the demo is set up at a specific version (based on the config params).
Ultimately, we should be looking at overall demo versioning (ideally via git hub releases of the installer) whereby we can deploy different versions of the demo by targeting different releases of the installer.
NOTE: This should be in addition to what we current have rather than replace it. The reason here is that it is still very useful to have the Jenkins Jobs available for those who are actually developing the demo. The use case for installing from images is more so for people who just want to give the demo, rather than edit the source code.
The text was updated successfully, but these errors were encountered:
At present, the process for standing up the demo clones the source code of the various repos for the business logic components (Incident Service, Process Service, Alert Service etc...) and stands up a Jenkins instance on the OPenShift cluster to build them.
There are a number of issues with this approach
As an alternative to this, we should introduce CI/CD jobs for each component which will build the various services and push them to a quay.io registry. We can then create a flavour of the installer (via config params and variables for what version of each image to use) which will use these images rather than building from source.
This will allow us to cut the time to provision as well as be able to ensure that the demo is set up at a specific version (based on the config params).
Ultimately, we should be looking at overall demo versioning (ideally via git hub releases of the installer) whereby we can deploy different versions of the demo by targeting different releases of the installer.
NOTE: This should be in addition to what we current have rather than replace it. The reason here is that it is still very useful to have the Jenkins Jobs available for those who are actually developing the demo. The use case for installing from images is more so for people who just want to give the demo, rather than edit the source code.
The text was updated successfully, but these errors were encountered: