csdl

Cobalt Service Definition Language and Tool

https://wiki.ariba.com/display/COB/Cobalt+Service+Definition+Language

Goals

What are we aiming to achieve using CSDL? The design goal is to abstract all the details of the service and provide an abstraction from the underlying complexities of orchestrator and pipeline definitions.

FAQs

Is this a code generator?

Strictly speaking, this indeed generates code for pipelines and deployments, but the generated files are never to be committed back to info source except while usig the init command.

Will this be useful in local vagrant?

Yes, this tool aims to replace the local scripts and instead use the same service definition to run the local builds.

How can pipelines start without a committed Jenkinsfile?

The committed Jenkinsfile will be only having this code

initPipeline{}

That closure will take over the pipeline using generated pipelines in the CI/CD system.

And how can we have partial Vagrantfiles?

Vagrantfile till be generated on the fly. The tool will take care of the details.

Commands

#1. init

User runs cobalt init at any location and the following will be created

• Jenkinsfile with the content

initPipeline{}

• Generates/updates gitignore files
• Asks user a series of questions to generate config.yml
  • TBD
• Should include CS-ID collection or allow the user to create a new CS

#2. build

This expects the service build to be performed both in local and CI/CD environments

• Generates an actual pipeline based on the config.xml and build.xml
  • custom step support to be modelled as committed groovy scripts
• Generate local scripts for local builds (not to be committed)
• We can skip the two implementations and decide on the tool to do the build the same way in both environments. Current capabilies that translates to different mechanisms should be addressed. For example, custom build params, periodic trigger etc.

#3. deploy

This mode takes care of deployment using the generated bundle in both local and CI/CD environments.

• Detect the target
• Performs the deployment

#4 localenv

This mode is to manage the vagrant environments in local laptops

• up to install and bring up vagrant
• Installs vagrant if needed
• Generates Vagrantfile, but not for committing to source
• <any vagrant command>

Open Questions

• Are we developing an elephant?
• Will the advantages outweigh the development efforts, or vice versa?
• Is the history repeating itself?

Ranked Stories

1. Given a service definition, generate build and deployment pipelines for CI/CD in current form (Jenkinsfile) (Related to - #2)
2. Bring up local environment (Related to - #4)
3. Build and deploy in local environment using the same config.xml and build.xml - (Related to #4 and #2)
4. Build and deploy in CI/CD environment using the same config.xml and build.xml - (Related to #2) (This obsoletes the first story)
5. Enable the creation of a new service definition. (Related to #1)
6. Enable the creation of a new cobalt service repo structure. (Related to #1)