Versioning

[kevgo]

When working on an application with lots of services I want to be able to specify which app version consists of which service versions So that I have deterministic deployments.

• [ ] application has a version
• [ ] stand-alone services have a version
• [ ] services inside an application are versioned by the last SHA that changed them (git rev-list -1 HEAD <service-dir>)
• [ ] app version specifies service versions in application.yml

Scenario: reverting to a working service version
  Given an Exosphere application version 1 with the services:
    | NAME | VERSION |
    | web  | 11      |
    | api  | 20      |
  And the "web" service version 11 is broken
  When reverting the "web" service back to version 10
  Then I end up with application version 2 with the services:
    | NAME | VERSION |
    | web  | 10      |
    | api  | 20      |

[charlierudolph]

Adding in points I remember from some initial discussions

• versioning does not make sense for services within the codebase
  • there is no way to get a version of the service other than what is currently on that branch (without some complex git logic moving and tags marking each version)
• the version of each service could be the sha of the last commit which changed that service
  • git rev-list -1 HEAD <service-dir>

This versioning of services prevents us from overwriting docker images we push to ecr and allows us to avoid pushing images when we don't need to. Otherwise I don't understand the need for versioning services within the codebase / versioning the application as a whole.

One example you gave a while back is testing out a new version of the service by only directing some traffic to it (sounds exocom specific). To me that means you want two services deployed, the old and new version. Within the current setup, the new service would need to be in a new folder or possibly using the one on ECR as an external image (if possible) and thus can update the service in the codebase.

[kevgo]

Thanks, @charlierudolph, I have added your points to the ticket text.

Canary releases deploy the entire new app version parallel to the older version. The new version receives a small fraction of the traffic while monitoring CPU and memory consumption. Then the amount of traffic is gradually increased. This is not Exocom specific but works with all Exosphere apps where different service versions can share the same database.

[charlierudolph]

Exosphere could be used to deploy the new app to a new AWS account / hosted zone. Do we want to be providing redirecting some of the traffic?

Should app version specifies service versions in application.yml only be applying to standalone service? Also I think standalone should be changed to external to imply they are outside the code base

[kevgo]

Ideally, a new version of an app is deployed into the same AWS account. Then there is an Exosphere command to set the traffic ratio between the two (green and blue) deployments.

Yes, "standalone" == "external". I meant it stands on its own, outside of an application.

Yes, application.yml only needs to specify versions for external (standalone) services.

[charlierudolph]

@kevgo

external services have a version

is done

services inside an application are versioned by the last SHA that changed them (git rev-list -1 HEAD )

is done

---

We do not yet have an application version. I think the green/blue deployments are too far down the road at the moment as I think being able to deploy other projects is more of a priority

[kevgo]

Application version is just a simple number in application.yml. But I agree it isn't high priority, since deployments are always made from Git branches, and then we can just deploy whatever service versions are listed in the config files in that branch.