Odin
  • Introduction
  • Why Odin?
  • Key Concepts
    • Environment
      • Environment Type
    • Provisioning
      • Provisioning Config for Component Types
    • Component
      • Available Component Types
      • Component Type reference
        • Optimus Components
          • Aerospike [6.3.0.7-1.0.0]
    • Service
      • Know Your Service Definition
    • Versioning
      • Clearing the Confusion: A Simplified Guide to Artifact, Component, and Service Versions
    • Service Sets
    • Labels
  • Reference
    • CLI reference
  • Onboard Your Service
    • Installation
    • Configure
    • Odin -h
    • Getting Started
    • Create Environment
      • Operations on Environment
    • Service Definition
    • Provisioning Config
    • Deploy Service
    • Release Service
    • Optimus Datastore Operations
      • How to use Optimus Datastore in my service?
      • RDS Operations
      • Aerospike Operations
      • Kafka Operations
    • Operating Service & Components
      • Redeploy
        • In Place Deployment
        • Blue Green Deployment
      • Rolling Restart
      • Adding & removing components
      • Revert a deployment for application component
      • Downscaling a Passive Stack
      • Updating the no. of stacks of application component
    • Dev <> QA iteration
    • Frequently Asked Questions
    • Deploy Concrete Service
    • Undeploy Service
    • Delete Environment
    • Appendix
  • How To
    • Define error threshold for canary deployment
    • Add or Remove a component in an already deployed service
    • Integrate mono-repo(cronjobs) with Odin
    • Deploy crontab with Odin
    • Integrate Data pipeline with Odin
    • Push logs to log central
    • Build artifacts for multi module applications
    • Load test with Odin
    • Track Deployments against Commit Ids
    • Deploy Service on Production - Dream11
    • How and when images are created
    • Check logs for deployed infrastructure - Dream11
    • Onboard Stepfunction as a component
    • Onboard Serverless as a component
    • Login to Kubernetes clusters
  • Release Notes
    • 1.2.0-beta.2 - 11 August, 2022
    • Odin October Release
    • Odin 1.2.0 - Nov 9th 2022
    • Odin February Release
Powered by GitBook
On this page
  • Service Version
  • Component Version
  • Artifact Version
  • Relationship between the Versions
Export as PDF
  1. Key Concepts
  2. Versioning

Clearing the Confusion: A Simplified Guide to Artifact, Component, and Service Versions

Taking a look at a typical service definition in Odin containing a datastore and an application component.

{
  "name": "odindemo3",
  "version": "2.0.0",
  "team": "devx",
  "components": [
    {
      "type": "application",
      "name": "odindemo",
      "version": "1.0.0",
      "config": {
        "build_type": "java",
        "build_version": "11",
        "artifact_name": "odindemo",
        "artifact_version": "3.0.0"
      }
    },{
      "type": "rds",
      "name": "demo-rds",
      "version": "5.7-1.0.0"
    }
  ]
} 

There are three major types of versions involved:

  • Service version

  • Component version

  • Artifact version

Service Version

A service version is a version of the service. Service is a set of components along with their configuration. This version needs to be upgraded whenever there is a change in any of the components in the service definition.

This version is defined at the scope of the service definition. (line 3 in the above example)

This version can be a SNAPSHOT version or a concrete version. The SNAPSHOT version of a service can consist of artifacts with SNAPSHOT versions but the other way around is not true. It is mandatory for a service with a concrete version to have all artifacts with a concrete version.

Component Version

A component version is a version of the component offered by odin. This version has two parts separated by a hyphen. The first part (only available in datastores) indicates the true version of the datastore whereas the second part of the version denotes the version of the default set configuration used by that component.

To help understand better, consider the component version at line 19 in the above example. The first part of the version implies that the MySQL version is 5.7 and there is a default set of configurations involved (say the engine version is 5.7.mysql_aurora.2.09.1), the combination of both will make the version 5.7-1.0.0

In the case of the application component, there is just a default set of configurations offered by odin. So the version number is just 1.0.0 (without two parts). The list of available application component versions can be viewed by the command

odin list component-type --name application

Artifact Version

The artifact version is the version of the code artifact used to deploy the application component. This version can also be concrete as well as SNAPSHOT. The SNAPSHOT version of an artifact is allowed to be used in a service with SNAPSHOT version only.

The SNAPSHOT versions are overridable. That means you can create multiple artifacts with the same SNAPSHOT version and the latest will be used for deployment. Whereas a concrete version of an artifact is not allowed to override.

Relationship between the Versions

Consider the above example.

  • The service version 2.0.0 consists of two components.

  • One is MySQL with a component version 5.7-1.0.0 where MySQL version 5.7 will be provisioned.

  • The other is an application component with a component version 1.0.0 and artifact version 3.0.0

  • We can say that the artifact version of the application component will use the default configuration of component version 1.0.0 used in the service definition version 2.0.0

PreviousVersioningNextService Sets

Last updated 2 years ago