Getting Started

This page is all about setting up application level changes at the user's end to help Odin operate at CD level.

A developer starts coding and ends with releasing the changes, the life-cycle of the same process is depicted below. For every step, what action needs to be performed is mentioned in this document.

Software Lifecycle With Odin

Step 1 (code changes) : Application Level Changes

To make your application code odin ready, run the below command in root of application code

odin generate application-template --name APPLICATION_NAME

This command will generate necessary files for odin as shown below.

<application_folder>
    └─── application related files
    └─── .odin
        └─── APPLICATION_NAME
            | application-spec.yml
            | build.sh
            | pre-deploy.sh
            | start.sh

Let's take a look at what each file means.

application-spec.yml

This file will store the version of your application and will be used while pushing the generated artifact to jfrog.

Sample content

version: 1.0.0-SNAPSHOT

Build.sh

Build.sh is used to create artifacts that'll be used to deploy the application component. Artifacts created are then uploaded to jfrog using version in the application-spec.yml file.

Sample content for build.sh file for a Java project

# example for java project
# mvn -U -B clean package -DskipTests

Build.sh is executed in the root of the application code directory as part of the ci process.

Setup.sh

Setup.sh is used to install required packages in the application image and/or make any changes to the application image to make it ready for deployment like adding some file from a public repository. This script is executed while building the application image and is optional.

The following environment variables will be available in setup.sh :

SERVICE_NAME=<name of application component in service definition>
BASE_DIR=<"/app" for container deployment and "/var/www/" otherwise>
DEPLOYMENT_TYPE=<deployment_type of component in provisioning>
BUILD_TYPE=<build_type of component in service definition>
BUILD_VERSION=<build_version of component in service definition>

Pre-deploy.sh

This file is executed just before running start.sh during the deployment step. Things like db migrations or data seeding can be done in the step.

Add the pre-deploy code of your project to this file. If you dont have one, you can use this template for reference(for java projects) and create a new one.

Pre-deploy.sh is executed in the root of the application code after unzipping the artifact present in jfrog

Start Script

Write the code that's needed to start application component in this file. The name of the start script file is start.sh by default. This can be configured by providing config.start_script_path in the service definition.

Add the booting code of your project to this file. If you don't have one, you can use this template for reference(for java projects) and create a new one.

Once your are done with adding content to these files, you are all set to start deploying your service.

Step 2 (Publish Artifact) : Building Application

Odin expects the application artifact / executable in a remote artifactory repository like jfrog.

For use within Dream11, Odin expects artifact / executable zip to be in jfrog in the mentioned url in this link - https://dream11.atlassian.net/wiki/spaces/BAC/pages/2981396517/Odin+Documentation#Building-Artifact

Creation of service artifacts

Automation for application artifact generation can be achieved by using following documents,

https://dream11.atlassian.net/wiki/spaces/PER/pages/3064496885/Getting+Started+With+CI+Using+Ephemeral+Github+Runners

Writing your custom build process

You may choose to write your own build process. The build process should ensure that the below structure is maintained and the artifact is pushed to jfrog at the desired location.

<application_name>
    └─── application related files
    └───  .odin
            | application-spec.yml
            | build.sh
            | pre-deploy.sh
            | start.sh

target directory should be in the root of your application code directory.

Things to know

• Odin commands are executed in the <application_name> folder e.g. ./.odin/pre-deploy.sh ensure correct file paths are mentioned in the scripts.

• Write logs to console in json format for docker containers. You can integrate d11-vertx-logger for this. These logs will be sent to datadog

Important Notes

• The application code will be present in /app/<application_name>/ in case of docker images and in /var/www/<application_name>/ in case of EC2 instances. You might have to change paths in pm2-configs for node projects

Step 3,4, & 6

For Step 3, please refer to the document - Environment Creation Using Odin.

For Step 4, please refer to the document - Deployment Using Odin.

For Step 6, please refer to the document - Release Using Odin.