Devtron is an open-source software delivery workflow for Kubernetes. It combines CI, CD, and GitOps principles and processes through Argo CD, Argo Workflows, Argo Rollouts, Clair, and quite a few other tools.
Continue readingWhich self-managed kubernetes-native CI/CD pipeline is the best choice? Is it Tekton or Argo Workflows? Which one should you pick?
Continue readingShould we be using Jenkins for our Kubernetes CI/CD pipeline needs in 2021? How to deploy Jenkins in k8s? How to run Jenkins builds in Kubernetes? How would a full CI/CD pipeline look like?
Continue readingTekton is a powerful and flexible open-source framework for creating CI/CD systems aiming at becoming a de-facto standard for running pipelines and workflows in Kubernetes. It allows developers to build, test, and deploy across cloud providers and on-premise systems.
Continue readingChat is continuous integration (CI), continuous delivery (CD), continuous deployment (CDP), and continuous testing (CT)? How do they differ from each other? Which one should we use?
Continue readingWhat do we get if we combine events, workflows, GitOps, progressive delivery, and secrets management? The short answer is that we get automation of everything in Kubernetes in a way that we should be operating in 2021.
We’ll combine Argo Events, Workflows & Pipelines, CD, and Rollouts and sprinkle all that with SealedSecrets, Kaniko, and a few other tools.
Argo Workflows & Pipelines is an open source container-native workflow engine for orchestrating parallel jobs on Kubernetes. It is a cloud-native solution designed from ground-up for Kubernetes.
Since the increase in popularity of continuous delivery (CD), there was an increase in the number of tools marketed as CD solutions. That’s normal. It is only natural for software vendors to ride the waves. They need to sell, and there’s nothing better to sell than whatever is popular at a given moment. Continuous delivery is one of those "popular" waves.
A video version of the same post is available in The DevOps Toolkit Series YouTube channel.
On the surface, there is nothing wrong with buying tools that solve problems. You have a problem, a vendor has a solution, you buy it, they earn money, and you have a good return on investment. Everybody wins, except when the tool does not do what it’s supposed to do. That’s when we run into issues.
After nine months of work, I managed to finish the latest book in The DevOps Toolkit Series. We’re at the seventh book, and this time it’s all about Jenkins X.
The book is called The DevOps 2.6 Toolkit: Jenkins X and the following few paragraphs is how it starts.
Everyone wants to implement continuous delivery. After all, the benefits are too big to be ignored. Increase the speed of delivery, increase the quality, decrease the costs, free people to dedicate time on what brings value, and so on and so forth. Those improvements are like music to any decision maker. Especially if that person has a business background. If a tech geek can articulate the benefits continuous delivery brings to the table, when he asks a business representative for a budget, the response is almost always “Yes! Do it.”
A continuous delivery project will start. Tests will be written. Builds will be scripted. Deployments will be automated. Everything will be tied into an automated pipeline and triggered on every commit. Everyone will enter a state of nirvana as soon as all that is done. There will be a huge inauguration party with a vice president having the honor to be the first one to press the button that will deploy the first release to production. Isn’t that a glorious plan everyone should be proud of?
Continue reading
