Let’s paint a high-level picture of the continuous delivery pipeline. To be more precise, we’ll draw a diagram instead of painting anything. But, before we dive into a continuous delivery diagram, we’ll refresh our memory with the one we used before for describing continuous deployment.
The continuous deployment pipeline contains all the steps from pushing a commit to deploying and testing a release in production.
Continuous delivery removes one of the stages from the continuous deployment pipeline. We do NOT want to deploy a new release automatically. Instead, we want humans to decide whether a release should be upgraded in production. If it should, we need to decide when will that happen. Those (human) decisions are, in our case, happening as Git operations. We’ll comment on them soon. For now, the important note is that the deploy stage is now removed from pipelines residing in application repositories.
Continue reading
Every once in a while I get asked a variation of the same question. “Viktor, how do we create a learning culture in our company?” In most cases, my answer receives a bad reception. The short version of it is to “stop doing what you’re doing, and get out of the way.”
First things first… We need to find out the IP of our cluster or external LB if available. The commands that follow will differ from one cluster type to another.
Soon after I started working on 
