Release of new major version
New versions are deployed using Swarm autodeployment. For all versioning we use Semantic Versioning
1. Create docker image v2
In the repository create a new branch and tag for current version (for example
v1) and assume that the new version will be developed in
Add new section into file
.gitlab-ci.yml. In this section describe
registry_deployment with the right new name of docker image.
In following example for the
# Example build_image_v1: stage: build script: - echo $CI_COMMIT_SHA > commitsha - docker build -t $CI_REGISTRY_IMAGE/v1/$CI_COMMIT_REF_NAME:$CI_PIPELINE_ID -t $CI_REGISTRY_IMAGE/v1/$CI_COMMIT_REF_NAME:latest . only: refs: - v1 registry_deployment_v1: stage: deploy script: - docker login -u gitlab-ci-token -p $CI_BUILD_TOKEN $CI_REGISTRY - docker push $CI_REGISTRY_IMAGE/v1/$CI_COMMIT_REF_NAME:$CI_PIPELINE_ID && docker push $CI_REGISTRY_IMAGE/v1/$CI_COMMIT_REF_NAME:latest only: refs: - v1
Now we have separated docker images for each version.
2. Create new Docker service
docker service, same as current service (example for output-gateway).
Just change the name of the service to include postfix with current version (example
output-gateway-v2). All other services can call this service as
output-gateway-v2 (for example in routes of
Set a different number of Redis database than previous versions! To set a specific database number use the env
REDIS_CONN with db number in the URL, e.g. to use db number
2 set url to
In permission-proxy, get all current routes for current version and create the new ones (via API). New routes will contains
4. Database migrations
For the backward compatibility of current API you should do just nondestructive changes. When you stop obsolete API, it is strongly recommended to add migrations for removal outdated structures and data.