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 master
branch.
Add new section into file .gitlab-ci.yml
. In this section describe build
and registry_deployment
with the right new name of docker image.
In following example for the v1
version:
# 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
Create new 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 permission-proxy
).
Redis
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 redis://localhost/2
.
3. Routing
In permission-proxy, get all current routes for current version and create the new ones (via API). New routes will contains target_url: http://output-gateway-v2:3000
.
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.