Phoenix
Versioning
Tsvetan Dimitrov
Agenda
-
Phoenix Versioning Scheme
-
Deploy Environment Setup
-
Backend Versioning Integration
-
Environment Tracking Repository
-
Release Procedures
Phoenix Versioning Scheme
Overview
-
Each microservice with a separate version.
-
All services united by a parent (distribution) version:
-
GRUMPY (parent version)
-
1.3.0 (core)
-
1.2.0 (legal-values)
-
1.5.0 (frontend)
-
etc.
-
-
Version Formats
-
DEV
-
<CI_build_number>
-
-
STAGING
-
MAJOR.MINOR.0-<timestamp>.<git_commit_hash>
-
-
PROD
-
MAJOR.MINOR.0
-
-
Hotfix on PROD
-
MAJOR.MINOR.PATCH
-
Version Persistence
-
Docker tags on ECS.
-
Git tags of parent version.
-
Environment tracking repository (will explain in the following sections).
Deploy Environment Setup
Environment usage / 1
DEV
-
Remains unversioned.
-
No QA allowed.
-
No guarantee for stability.
-
Release from a development branch.
-
Reproduce bugs on a real environment.
-
Remote debugging.
Environment usage / 2
STAGING
-
MAJOR.MINOR.0-<timestamp>.<git.commit.hash>.
-
Releases occur nightly.
-
Frontend uses this environment.
-
QA tests on this environment.
-
Automation tests run after nightly build and generate reports.
-
Internal company usage.
Environment usage / 3
PROD
-
Contains parent version.
-
MAJOR.MINOR.0.
-
Manually triggered deploys with a parent version.
Backend Versioning Integration
-
Exposed service version in Swagger UI.
-
Synced with Maven's ${project.version}.
-
Exposed Git metadata and build info at /info endpoint.
Environment Tracking Repository
-
staging
-
<service_name>.version
-
...
-
-
prod
-
latest.version
-
<parent_version>
-
<service_name>.version
-
...
-
-
<parent_version>
-
<service_name>.version
-
...
-
-
...
-
Repository
Directory
Structure
-
Tracking of currently running services on all environments.
-
<service-name>.version files contain the service version as file content.
-
Archive of previous production release parent and service versions.
Features / 1
-
Jenkins will manipulate this directory structure and automatically commit the changes (no human intervention).
-
Version stability status.
Features / 2
-
README.md regeneration exposing all current versions in a human readable form.
Features / 3
Release Procedures
STAGING release
-
Execute nightly build and release a test release: MAJOR.MINOR.0-<timestamp>.<git.commit.hash>.
-
Trigger downstream Jenkins job after deploy job that updates <service_name>.version file of the released service with the new version in phoenix-versions repo.
-
Commit changes in phoenix-versions.
New PROD release / 1
1. Manually trigger a special Jenkins job that mirrors the current staging environment:
-
Rebuild and push on or copy built Docker images from STAGING to PROD ECS repositories.
-
Retag or tag docker images with versions in format: MAJOR.MINOR.0.
-
Tag in Git with new parent version.
-
After deploy job trigger phoenix-versions job.
New PROD release / 2
2. On triggered phoenix-versions job:
-
Create a new directory prod/<new_parent_version>.
-
Copy <service_name>.version files from staging directory to the new directory.
-
Edit the copied files by removing PRERELEASE component.
-
Generate README.md listing service versions of the new PROD release.
- ...
New PROD release / 3
2. On triggered phoenix-versions job:
-
...
-
Change latest.version file with the name of the new parent release.
-
Regenerate main README.md with the new latest PROD release versions.
-
Commit and push changes to the repo.
PROD hotfix / 1
1. Execute special hotfix Jenkins job with parameters-service name and new version with format: MAJOR.MINOR.PATCH:
-
After service hotfix, build and tag Docker image with new version.
-
After deploy job, trigger a phoenix-versions job.
PROD hotfix / 2
1. On triggered phoenix-versions job:
-
Update patched <service_name>.version file.
-
Regenerate prod/<parent_version>/README.md.
-
Regenerate main README.md.
Phoenix Versioning
By Tsvetan Dimitrov
Phoenix Versioning
Phoenix Versioning scheme and procedures
- 178