Answers: <p>Just some freeform thoughts from your question.</p>
  <p>For perspective, I run a large enterprise DevOps team that has automated build &amp; deployment for a wide range of large scale services (which run over k8s/AWS primarily).  That doesn't necessarily mean I'm good at things, haha (always check your sources) - but I think we're in a very good spot personally =).  But the advice comes from practical experience and lots of time spent iterating at least.</p>
  <ul>
  <li>When we hire people we really don't care what CI/CD tool they knew, or what &quot;automation&quot; tool they knew.  We just care that they know one well and can explain some pipelines and their challenges in depth.
  <ul>
  <li>Note that if you're not in k8s, deployment usually involves terraform, cloud formation, ansible, or one of many other tools on top of your CI/CD engine.</li>
  </ul>
  </li>
  <li>So, rather than overthinking which tool to learn (they evolve constantly), my recommendation is pick a mainstream one and focus on a &quot;hard use case&quot; so that you have to do something complex in it that forces you to learn.</li>
  <li>We use GitLab CI, and previously Jenkins.  People in the industry also seem to like Spinnaker, CircleCI, and the equivalent cloud tools (AWS and Azure have all their own).  GitHub Actions is also huge now.</li>
  <li>I don't think tools just do CI or CD.  That's a very arbitrary line.  CD just means your pipeline pushed to production (in a hopefully validated and safe manner).  Jenkins can do that, GitLab can do that, any of those tools can.  They're free form and you tell them what to do.</li>
  <li>Having everything in  one tool is revolutionary and makes life 1000 times easier.  E.g. GitLab, GitHub, etc are going all in to do code, wikis, testing, container and artifact registries, deployment, monitoring, even things like incident management.  It's amazingly helpful and goes far beyond &quot;CI and CD&quot;.  More tools = more integration issues and more sprawl and a greater chance you miss or get lazy about something / waste time coding integrations.</li>
  <li>For getting started, anything really works again.  I might recommend GitHub actions, GitLab, or Jenkins.  The first 2 may be a little better as they have more tools in them.  With Jenkins you'll need external artifact registries and such.  But Jenkins is good as it is super common still.</li>
  </ul>
  <p>FYI, I don't know much about Jenkins vs JenkinsX, so ignoring that part :).</p>
  
Answers: CC BY-SA 4.0
Answers: 2022-04-11T18:21:09.443Z
Answers: Very helpful and appreciated! I just don't understand what you mean by the following: "if you're not in k8s, deployment usually involves terraform ..."
Answers: Omar Shazly
Answers: CC BY-SA 4.0
Answers: 2022-04-11T19:24:37.987Z
Answers: No problem =).  K8s is the short name for Kubernetes (very heavily used in the ecosystem).  Kubernetes "abstracts away your infrastructure" so that you can use things like HELM or GitOps (or just kubectl) to deploy apps.  But, if you don't have kubernetes, you either need to push code to a server (ansible, etc), or you need to create a new image/new servers/etc to get the code out.
Answers: John Humphreys
Answers: CC BY-SA 4.0
Answers: 2022-04-11T19:26:50.020Z
Answers: Packer builds machine images (e.g. take red hat / centos base image, install new software, update, create some directories, install your app).  Then terraform can create-or-apply the image to an auto scaling group in the cloud which will bring up servers with that packer built image, which should be good enough to bring up a server with the app you're deploying already running.  This is the normal "cloud way" to deploy code outside of kubernetes.
Answers: John Humphreys
Answers: CC BY-SA 4.0
Answers: 2022-04-11T19:28:16.433Z
Answers: Even if you have kubernetes, you should have a CI/CD pipeline for building your kubernetes itself =).  You'll also have databases, caches, storage mediums, etc to manage which are tasks for terraform/etc.
Answers: John Humphreys
Answers: CC BY-SA 4.0
Answers: 2022-04-12T19:18:35.137Z
Answers: This totally fits what I've seen with hiring practices.  If you're using one of the top 5-10 tools in any category then you can probably translate those skills into whatever tool we've picked internally.
Answers: chicks
Answers: CC BY-SA 4.0
Answers: 2022-04-11T17:39:34.437Z
Answers: 2022-04-12T22:39:09.813Z
Answers: 2022-04-12T22:39:09.813Z
Answers: John Humphreys
Body: <p>I'm new to DevOps and I'm learning that:</p>
  <ol>
  <li><a href="https://dev.pro/insights/15-devops-trends-2022-from-dev-pro-experts/" rel="nofollow noreferrer">The adoption of containerization and GitOps have been clear trends</a></li>
  <li><a href="https://thenewstack.io/what-is-jenkins-x-and-how-it-differs-from-jenkins-and-cloudbees-core/" rel="nofollow noreferrer">Some CI/CD tools (e.g. Jenkins X) are more geared toward this trend than others (e.g. Jenkins)</a></li>
  <li><a href="https://blog.container-solutions.com/fluxcd-argocd-jenkins-x-gitops-tools" rel="nofollow noreferrer">While some CI/CD tools are limited to CI (e.g. Jenkins) or CD (e.g. ArgoCD) but can be extended to cover both, others inherently cover both (e.g. Jenkins X)</a></li>
  </ol>
  <p>In light of all that, I've been trying to answer these questions:</p>
  <ol>
  <li>To which extent is it advantageous to have one tool for CI &amp; CD?</li>
  <li>Which tool(s) would you recommend someone new to start with?</li>
  </ol>
  
Tags: <jenkins><cicd><toolchain><jenkins-x>
Title: Which CI/CD tool(s) should a DevOps newbie learn?
UserDisplayName: Omar Shazly
ThreadText: # Which CI/CD tool(s) should a DevOps newbie learn?
  
  (Asked by: username_0 on 2022-04-11)
  
  I'm new to DevOps and I'm learning that:
  
  1. [The adoption of containerization and GitOps have been clear trends](https://dev.pro/insights/15-devops-trends-2022-from-dev-pro-experts/)
  2. [Some CI/CD tools (e.g. Jenkins X) are more geared toward this trend than others (e.g. Jenkins)](https://thenewstack.io/what-is-jenkins-x-and-how-it-differs-from-jenkins-and-cloudbees-core/)
  3. [While some CI/CD tools are limited to CI (e.g. Jenkins) or CD (e.g. ArgoCD) but can be extended to cover both, others inherently cover both (e.g. Jenkins X)](https://blog.container-solutions.com/fluxcd-argocd-jenkins-x-gitops-tools)
  
  In light of all that, I've been trying to answer these questions:
  
  1. To which extent is it advantageous to have one tool for CI & CD?
  2. Which tool(s) would you recommend someone new to start with?
  
  **Tags:** jenkins, cicd, toolchain, jenkins-x
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2022-04-11. Score: 3 | Accepted answer
  
  Just some freeform thoughts from your question.
  
  For perspective, I run a large enterprise DevOps team that has automated build & deployment for a wide range of large scale services (which run over k8s/AWS primarily). That doesn't necessarily mean I'm good at things, haha (always check your sources) - but I think we're in a very good spot personally =). But the advice comes from practical experience and lots of time spent iterating at least.
  
  * When we hire people we really don't care what CI/CD tool they knew, or what "automation" tool they knew. We just care that they know one well and can explain some pipelines and their challenges in depth.
    + Note that if you're not in k8s, deployment usually involves terraform, cloud formation, ansible, or one of many other tools on top of your CI/CD engine.
  * So, rather than overthinking which tool to learn (they evolve constantly), my recommendation is pick a mainstream one and focus on a "hard use case" so that you have to do something complex in it that forces you to learn.
  * We use GitLab CI, and previously Jenkins. People in the industry also seem to like Spinnaker, CircleCI, and the equivalent cloud tools (AWS and Azure have all their own). GitHub Actions is also huge now.
  * I don't think tools just do CI or CD. That's a very arbitrary line. CD just means your pipeline pushed to production (in a hopefully validated and safe manner). Jenkins can do that, GitLab can do that, any of those tools can. They're free form and you tell them what to do.
  * Having everything in one tool is revolutionary and makes life 1000 times easier. E.g. GitLab, GitHub, etc are going all in to do code, wikis, testing, container and artifact registries, deployment, monitoring, even things like incident management. It's amazingly helpful and goes far beyond "CI and CD". More tools = more integration issues and more sprawl and a greater chance you miss or get lazy about something / waste time coding integrations.
  * For getting started, anything really works again. I might recommend GitHub actions, GitLab, or Jenkins. The first 2 may be a little better as they have more tools in them. With Jenkins you'll need external artifact registries and such. But Jenkins is good as it is super common still.
  
  FYI, I don't know much about Jenkins vs JenkinsX, so ignoring that part :).
  
  > **Comments:**
  > **username_0**: Very helpful and appreciated! I just don't understand what you mean by the following: "if you're not in k8s, deployment usually involves terraform ..."  
  > **username_1**: No problem =).  K8s is the short name for Kubernetes (very heavily used in the ecosystem).  Kubernetes "abstracts away your infrastructure" so that you can use things like HELM or GitOps (or just kubectl) to deploy apps.  But, if you don't have kubernetes, you either need to push code to a server (ansible, etc), or you need to create a new image/new servers/etc to get the code out.  
  > **username_1**: Packer builds machine images (e.g. take red hat / centos base image, install new software, update, create some directories, install your app).  Then terraform can create-or-apply the image to an auto scaling group in the cloud which will bring up servers with that packer built image, which should be good enough to bring up a server with the app you're deploying already running.  This is the normal "cloud way" to deploy code outside of kubernetes.  
  > **username_1**: Even if you have kubernetes, you should have a CI/CD pipeline for building your kubernetes itself =).  You'll also have databases, caches, storage mediums, etc to manage which are tasks for terraform/etc.  
  > **username_2**: This totally fits what I've seen with hiring practices.  If you're using one of the top 5-10 tools in any category then you can probably translate those skills into whatever tool we've picked internally.  
  
  ---
  
  