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

https://github.com/Majitek/phoenix-versions
  • 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

  1. Execute nightly build and release a test release: MAJOR.MINOR.0-<timestamp>.<git.commit.hash>.

  2. 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.

  3. 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.