<p>As I understand all of these tools <a href="https://draft.sh/" rel="noreferrer">Draft</a>,<a href="https://helm.sh/" rel="noreferrer">Helm</a> and <a href="https://ksonnet.io/" rel="noreferrer">Ksonnet</a> have overlapping functionality such as creating a chart as well as deploying kubernetes configurations. </p>

<p><em>I understand that purpose of these tool would be to describe and configure the application as well as the k8s environments.</em> </p>

<blockquote>
  <p>By using Draft we can create Dockerfile, Chart. Nevertheless we can do same thing with Helm and Ksonnet. </p>
</blockquote>

<p><em>My question is If these components create a pipeline in CI/CD then what will be the order?</em> </p>

<p>for example,  </p>

<p><strong>draft -> ksonnet > helm</strong> 
or</p>

<p><strong>draft -> helm -> ksonnet</strong>  </p>

<p>In short, <strong>draft</strong> and <strong>helm</strong> are more or less complimentary and <strong>ksonnet</strong> is orthogonal, specifically providing an alternative to <strong>helm</strong>.</p>

<p>In elaborating I will split my answer up into three major sections, the first of which describes how <strong>draft</strong> and <strong>helm</strong> interact, the second describing how <strong>ksonnet</strong> is orthogonal to the others, and finally a section explaining how I understand these with respect to CI/CD.</p>

<h1>Helm &amp; Draft</h1>

<p>Helm and Draft are complimentary in the sense that Helm, which can be considered to be a package management system for Kubernetes, provides a portion of the functionality offered by Draft which itself is essentially a Kubernetes application development tool.</p>

<p>The relationship between Draft and Helm can be summarized by pointing out that in pursuit of its goal of simplifying Kubernetes application development, Draft produces a Helm chart using metadata inferred from your current application type (more about that below) if one does not already exist or uses and existing one in order to deploy/update a development version of your application without you having to know anything about how it does that.</p>

<h2>Helm for Kubernetes Package Management</h2>

<p>As mentioned previously, Helm is a package management system for Kubernetes-based applications. It provides the following features:</p>

<ul>
<li>A templating approach for defining Kubernetes manifests (called "charts")</li>
<li>Package management, including a basic package repository service to host released packages.</li>
<li>Application lifecycle management including deploy, update, and purging of Helm applications</li>
<li>Package dependencies</li>
</ul>

<p>Helm takes a templated YAML approach to parameterizing Kubernetes manifests and allows values to be shared and overridden between dependent packages. ie, supposed Package A depends on Package B; Package A can re-use configuration values set on Package B and it can override those parameters with values of its own. Values for all packages in a given deployment can also be overridden using the Helm command line tool.</p>

<p>Also worth mentioning is the fact that Helm depends on the availability of its cluster-side component named "Tiller" to actually do the work of reifying templates and deploying the generated Kubernetes manifests to the cluster.</p>

<h2>Draft for Kubernetes Application Development</h2>

<p>The aim of Draft is to <a href="https://github.com/Azure/draft/blob/master/docs/reference/dep-002.md#user-personas-and-stories" rel="noreferrer">dramatically simplify development of Kubernetes applications</a> by being quickly building and deploying the Helm charts/packages and corresponding docker images necessary to run a project -- provided that the following exist:</p>

<ul>
<li>A Kubernetes cluster</li>
<li>Helm's Tiller pod installed in the Kubernetes cluster</li>
<li>A Docker registry</li>
</ul>

<p>The <a href="https://github.com/Azure/draft/blob/master/docs/install.md" rel="noreferrer">draft installation guide</a> provides details for getting these pieces set up to try it out yourself.</p>

<p>Draft also builds on Helm by providing a high-level "packaging" format that includes both the application helm chart and the Dockerfile, the latter giving it the ability to build docker images.</p>

<p>Finally, it has built-in support for specific programming languages and will to a limited extent attempt to infer which programming language and framework(s) you are using when initially creating a new Draft project using <code>draft create</code>.</p>

<h1>Ksonnet for Kubernetes Package Management</h1>

<p>As mentioned previously, Ksonnet is orthogonal in many ways to Helm, providing essentially the same features with respect to package management wrapped in different terminology -- see its <a href="https://ksonnet.io/docs/concepts" rel="noreferrer">core concepts documentation</a>. It's worth noting that it is not compatible with nor does it address the same concerns as Draft.</p>

<p>I say that Ksonnet and Helm are orthogonal because they take mutually incompatible approaches to generating and deploying Kubernetes manifests. Whereas Helm uses templated YAML, Ksonnet generates Kubernetes manifests using a <a href="http://jsonnet.org/" rel="noreferrer">"data templating" language called Jsonnet</a>. Also, rather than conceiving of "dependent" packages as is the case with Helm, Ksonnet blurs the line between dependent services by representing them as composable "prototypes". Finally, rather than depending on a cluster-side application that reifies and deployes manifest templates, Ksonnet has an <code>apply</code> subcommand analogous to <code>kubectl apply</code>.</p>

<h1>CI/CD</h1>

<p>So where do these pieces fit into a CI/CD workflow? Well since there are essentially two mutually incompatible toolsets, let's consider them on a case-by-case basis:</p>

<h2>Draft + Helm</h2>

<p>According to <a href="https://github.com/Azure/draft/blob/master/docs/reference/dep-002.md#qa" rel="noreferrer">the Draft design Q&amp;A section</a>, it is meant only as a developer tool intended to abstract much of the complexity of dealing with kubernetes, helm, and docker from developers primarily interested in seeing their application run in a development cluster.</p>

<p>With this in mind, any CD approach involving this set of tools would have to do the following:</p>

<ul>
<li>Build docker image(s) using the <code>docker</code> CLI if necessary</li>
<li>Build Helm package(s) using the <code>helm</code> CLI</li>
<li>Deploy Helm package(s) to Helm repository using the <code>helm</code> CLI</li>
<li>Install/update Helm package(s) on the appropriate staging/prod Kubernetes cluster(s) using the <code>helm</code> CLI</li>
</ul>

<h2>Ksonnet</h2>

<p>The Ksonnet CD workflow is somewhat abbreviated compared to the <code>helm</code> workflow above:</p>

<ul>
<li>Build docker image(s) using the <code>docker</code> CLI if necessary</li>
<li>Apply the Ksonnet manifest using the <code>ks</code> CLI</li>
</ul>

<p>Whereas with Helm you would deploy your applicat's package to a Helm registry for re-use, if your Ksonnet manifest contains <a href="https://ksonnet.io/docs/concepts#prototype" rel="noreferrer">re-usable prototypes</a> that might be of use to another Ksonnet-based application you would want to ensure it is available in a git repo as described in the <a href="https://ksonnet.io/docs/concepts#registry" rel="noreferrer">Ksonnet registry documentation.</a></p>

<p>This means that how Ksonnet definitions are dealt with in CI/CD is largely dependent on which git repo(s) you decide to store them in and how they are structured.</p>
