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
Export as PDF
  1. How To

Build artifacts for multi module applications

PreviousPush logs to log centralNextLoad test with Odin

Last updated 1 year ago

Application artifacts are prerequisite to create service definitions and deploy them using odin.

We have already seen the output for single application in the .

For multi module applications we'll follow similar steps. Let's say our multi module application has two applications APPLICATION_ONE and APPLICATION_TWO.

To get started we'll create the required structure for both the applications, to do the same run the below command in the working directory,

odin generate application-template --name APPLICATION_ONE
odin generate application-template --name APPLICATION_TWO

This will generate the below structure in your working directory.

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

Creation of service artifacts

Automation for application artifact generation is supported in jenkins jobs. This can be achieved by using automation via pr.jenkinsfile. Adding the below stage in pr.jenkinsfile

stage('Push: Push to Jfrog') {
  steps {
      retryWithBackoff(STAGE_RETRY_COUNT, STAGE_BACKOFF_SECONDS) {
        script {
          releasePackage(["${APPLICATION_1}", "${APPLICATION_2}"])
        }
      }
  }
}

By default releasePackage assumesthe stable branch is master.

If your Github repo has a different stable branch, then you can specify the branch as 2nd argument in the releasePackage

ex: releasePackage(["${APPLICATION_1}", "${APPLICATION_2}"], "main")

Complete the build.sh , pre-deploy.sh and start.sh as required.

onboard your service section
Example given here