<p>My company has decided to transition to a micro/service based architecture.</p>

<p>We have been doing a bunch of research for the last couple of months on exactly what the architecture of this thing is going to look like. </p>

<p>So far, we've settled on:</p>

<ul>
<li><p>Dotnet core for service development (although being language agnostic is somewhat of an end goal)</p></li>
<li><p>Kafka for message brokering</p></li>
<li><p>Docker</p></li>
<li><p>Kubernetes</p></li>
<li><p>Ansible</p></li>
</ul>

<p>We have a pretty basic proof of concept working, which seems to have ticked all the right boxes with the management team, and is an absolute joy to work with.</p>

<p>My next task is to investigate options for how the development workflow is actually going to work. They are already used to working in a CI/CD manner, with some of their newer products using Jenkins/Octopus Deploy.</p>

<p>My question is: Do any of you have any firm recommendations for setting up a CI/CD pipeline when deploying to a Kubernetes cluster?</p>

<p>A list of must haves is:</p>

<ul>
<li><p>Multiple environments i.e. Integration, Test, UAT, Staging, Production.</p></li>
<li><p>A means through which different business units can uniquely handle deployments to different environments (development can only push to integration, tester into test, etc). This one is probably their biggest ask - they are used to working with Octopus, and they love the way it handles this.</p></li>
<li><p>The ability to roll back / deploy at the click of a button (or with as few steps as possible).</p></li>
</ul>

<p>We would be deploying to our own servers initially.</p>

<p>I've spent the past couple of days looking in to options, of which there are many.</p>

<p>So far, Jenkins Pipeline seems like it could be a great start. Spinnakar also seems like a solid choice. I did read a bit into Fabric8, and while it offers much of what I'm asking, it seems a bit like overkill.</p>

<p>If you want to use Jenkins, Pipelines are indeed the way to go. Our setup does pretty much what you want, so let me explain how we set it up.</p>

<p>We use a Jenkins agent that has <code>docker</code> and <code>kubectl</code> installed. This agent first builds the docker container and pushes it to our docker registry. It will then call <code>kubectl</code> in various stages to deploy to our testing, acceptance and production clusters.</p>

<p><strong>Different business units:</strong> in a Pipeline you can use <a href="https://jenkins.io/doc/pipeline/steps/pipeline-input-step/" rel="nofollow noreferrer">an input step</a> to ask whether the Pipeline should proceed or not. You can specify who may press the button, so this is how you could solve the deployment to different clusters. <em>(Ideally, when you get to CD, people will realize that pressing the button several times per day is silly and they'll just automate the entire deployment.)</em></p>

<p><strong>Rollback:</strong> we rely on Kubernetes's rollback system for this.</p>

<p><strong>Credentials:</strong> we provision the different Kubernetes credentials using Ansible directly to this Jenkins agent. </p>

<p>To reduce code duplication, we introduced a shared <a href="https://jenkins.io/doc/book/pipeline/shared-libraries/" rel="nofollow noreferrer">Jenkins Pipeline library</a>, so each (micro)service talks to all Kubernetes clusters in a standardized way.</p>

<p>Note that we use plain Jenkins, Docker and Kubernetes. There is likely tons of software to further ease this process, so let's leave that open for other answers.</p>
