Release Service

Once you are confident of changes in the code and service can be shared with QA for testing. You can release service with SNAPSHOT version.

Once the service is fully tested and is ready to be released for distribution. To release the service with concrete version follow the steps given below.

1. Provide write access to Dream11bot on the main/master branch

Once the release service step will complete, dream11bot will make a commit to the service repo's main/master branch, for this you need to allow write access to dream11bot

• Go to the settings of your repo

• Click on Branches

• Click edit on protected branch

• Select Allow force pushes checkbox and add dream11bot in specified persons list

• Save the changes and you are good to go 🎉

2. Publish application artifact with concrete version to JFrog

Once the Application Level Changes are done and the application component is deployed with snapshot version, say 1.0.0-SNAPSHOT within a service, you need to add the label publish or release to the PR and merge it with the snapshot changes into your release branch, say master branch.

Once the PR gets merged, your application's PR job gets triggered. the PR job removes the -SNAPSHOT from the version and builds the artifact using build.sh script and publishes the artifact with concrete version 1.0.0 to Jfrog.

The PR job then updates the version by incrementing the patch version i.e from 1.0.0-SNAPSHOT to 1.0.1-SNAPSHOT in your application-spec.yml and commits the changes on the release branch i.e master branch with the message chore: release [email protected].

3. Release service

In order to release a service, you need to add your service definition and the provisioning files(if any) to the service-definition repository. you can refer the readme.

Mutable Releases a.k.a Snapshot Version Release

As soon as you create a PR with your service definition changes against the main branch, a SNAPSHOT version of your service is released. This SNAPSHOT version, like any other service version, is now deployable using odin.

odin deploy service --name foo-service --version 1.0.1-SNAPSHOT --env <env-name>

This SNAPSHOT version is mutable, which means that any changes you make to the service definitions will override the previously released SNAPSHOT version (with the same prefix) of the service.

At this stage, the component artifact versions can be mutable (i.e. have SNAPSHOT versions).

For example-

{
  "name": "foo-service",
  "version": "1.0.1-SNAPSHOT", // SNAPSHOT version of foo-service
  "team": "foo-owners",
  "components": [
    {
      "name": "foo-http",
      "type": "application",
      "version": "1.0.0",
      "config": {
        "build_type": "java",
        "build_version": "11",
        "artifact_name": "foo",
        "artifact_version": "1.0.1-SNAPSHOT" // SNAPSHOT version of foo-http
      }
    },
    {
      "name": "foo-redis",
      "type": "redis",
      "version": "6.2.1-1.0.0"
    }
  ]
}

Immutable Releases a.k.a Concrete Version Release

Once your development is complete and you have concrete versions for all your artifacts, you will need to update your service definition to use the concrete versions for your component artifacts.

{
  "name": "foo-service",
  "version": "1.0.1-SNAPSHOT", // SNAPSHOT version of foo-service, this will be the same
  "team": "foo-owners",
  "components": [
    {
      "name": "foo-http",
      "type": "application",
      "version": "1.0.0",
      "config": {
        "build_type": "java",
        "build_version": "11",
        "artifact_name": "foo",
        "artifact_version": "1.0.1" // Concrete version of foo-http
      }
    },
    {
      "name": "foo-redis",
      "type": "redis",
      "version": "6.2.1-1.0.0"
    }
  ]
}

Now to release a concrete version of your service, you need to merge the PR after getting it approved from the code owners.

As soon as the PR is merged, a new concrete version of the foo-service is released and the service version in the service definition is updated to the next SNAPSHOT version.

{
  "name": "foo-service",
  "version": "1.0.2-SNAPSHOT", // SNAPSHOT version updated.
  "team": "foo-owners",
  "components": [
    {
      "name": "foo-http",
      "type": "application",
      "version": "1.0.0",
      "config": {
        "build_type": "java",
        "build_version": "11",
        "artifact_name": "foo",
        "artifact_version": "1.0.1"
      }
    },
    {
      "name": "foo-redis",
      "type": "redis",
      "version": "6.2.1-1.0.0"
    }
  ]
}

Releasing a service does the following

• Creates deployment artifacts (AWS AMIs incase of EC2 based deployments, and docker images in case of container based deployments).

• Makes it available for users to deploy using odin.

  Copy

  odin deploy service --name <service-name> --version <version> --env <env-name>

Contribution Guidelines

There are certain guidelines that we need to follow while creating or updating the service definition of our services. Various Validations are in place to enforce these guidelines.

• Service directory name must match the service name in the definition.json

• Service name should start with a lowercase alphabet and should only contain lowercase alphabet, digit and hyphen.

• Service owning team handle should be in .github/CODEOWNERS for your service.

• Service version needs to be suffixed with SNAPSHOT. Concrete versions will only be released using automations.

• PRs will only be merged once all artifact versions are concrete versions.