Open shift will need to be setup to facilitate the building and testing of all components. Its not yet been decided if we are going to use Jenkins (in openshift) or if we are going to use Github's Actions (and BCDevOps prototype for it). Either way, we need to provision the environments and configuration manifests, similar to what has already been done for the entities team, but with the adoption of the BCDevOps Pipeline model.
This model helps ensures that when a pull request is made, it creates a hash of the component-directories and openshift-configuration, and only redeploys component (pods) that have a differing hash from what is currently deployed. This helps ensure that we can keep the 'jobs' minimal and fully encompassing of the project, while reducing the build time and effectiveness of the job.
Open shift will need to be setup to facilitate the building and testing of all components. Its not yet been decided if we are going to use Jenkins (in openshift) or if we are going to use Github's Actions (and BCDevOps prototype for it). Either way, we need to provision the environments and configuration manifests, similar to what has already been done for the entities team, but with the adoption of the BCDevOps Pipeline model.
See: https://github.com/BCDevOps/ocp-cd-pipeline
This model helps ensures that when a pull request is made, it creates a hash of the component-directories and openshift-configuration, and only redeploys component (pods) that have a differing hash from what is currently deployed. This helps ensure that we can keep the 'jobs' minimal and fully encompassing of the project, while reducing the build time and effectiveness of the job.
Acceptance Criteria