Deployment

This chapter describes how API Bridge and connected elements are deployed in internal and cloud infrastructure.

Note: The elements described here are described only from PD perspective. Meaning, the deployment for internal use.

There are several elements in API landscape which needs to be run and they are connected with each other.

All above projects (except Aperio Backend) have corresponding projects in GitLab repositories. There is general rule to keep at least two branches for each repository:

• develop - This branch is used to keep changes ready for internal testing
• master or main - This branch contains features which are ready to publish.

Development for these projects are done in separate branch, usually connected to Jira tickets. When development is done and ready for internal testing, developer merge (or open merge request) his work into “develop” branch. At this moment the internal deployment starts. The image with tag “develop” is created and the deployment creates a container on dkdcvs134.ibs.net server.

Note: At the moment of writting this documentation the internal deployment is limited to creating image with tag “develop”. On dkdcvs134.ibs.net server there is a Watchtower deamon installed which recognise new version of image and automatically upgrades containers to the latest “develop” image. The configuration files required to run containers are located in /apps/… folder in the corresponding subfolders.

Work done by developer can be tested internally. In case of errors developer can fix them and once again publish under new image with “develop” tag. When the feature is tested and approved by test team (consultant/s), it is the time now to merge develop branch into main (master) branch. This merge does not trigger any task - no deployment starts. Several times per year (depending on the build shedule), a new version of software is released. At this moment the new tag is added to main (master) branch in GitLab. Together with the tag, release notes are created. The tagging operation triggers another CI-CD procedure. This time, a new image is created with the tag equal GitLab’s tag.

For example, for version 1.0.0, images tagged with ‘1.0.0’ are deployed on Openshift (test cluster, iptor-go project). This time the deployment is performed from separate GitLab repository to not mix the deployment setup with the development project. The links to deployment GitLab repositories are shown in the table above. The developer is responsible to update the config maps accordingly.

Note: It happens sometimes that for testing purpose “develop” image is deployed on Openshift test cluter (iptor-go) project. But eventually this deployment is replaced by correct deployment of tagged version of software.