Hey there, fellow engineers and tech enthusiasts! I\u2019m excited to share one of my favorite strategies for modern software delivery: combining Docker and Jenkins to power up your CI\/CD pipelines.\u00a0<\/p>\n
Throughout my career as a Senior DevOps Engineer and Docker Captain, I\u2019ve found that these two tools can drastically streamline releases, reduce environment-related headaches, and give teams the confidence they need to ship faster.<\/p>\n
In this post, I\u2019ll walk you through what Docker and Jenkins are, why they pair perfectly, and how you can build and maintain efficient pipelines. My goal is to help you feel right at home when automating your workflows. Let\u2019s dive in.<\/p>\n
Continuous integration (CI) and continuous delivery (CD) are key pillars of modern development. If you\u2019re new to these concepts, here\u2019s a quick rundown:<\/p>\n
Continuous integration (CI):<\/strong> Developers frequently commit their code to a shared repository, triggering automated builds and tests. This practice prevents conflicts and ensures defects are caught early.<\/p>\n Continuous delivery (CD):<\/strong> With CI in place, organizations can then confidently automate releases. That means shorter release cycles, fewer surprises, and the ability to roll back changes quickly if needed.<\/p>\n Leveraging CI\/CD can dramatically improve your team\u2019s velocity and quality. Once you experience the benefits of dependable, streamlined pipelines, there\u2019s no going back.<\/p>\n Docker<\/a> allows you to containerize your applications, creating consistent environments across development, testing, and production. Jenkins, on the other hand, helps you automate tasks such as building, testing, and deploying your code. I like to think of Jenkins as the tireless \u201cassembly line worker,\u201d while Docker provides identical \u201ccontainers\u201d to ensure consistency throughout your project\u2019s life cycle.<\/p>\n Here\u2019s why blending these tools is so powerful:<\/p>\n Consistent environments: <\/strong>Docker containers guarantee uniformity from a developer\u2019s laptop all the way to production. This consistency reduces errors and eliminates the dreaded \u201cworks on my machine\u201d excuse.<\/p>\n Speedy deployments and rollbacks: <\/strong>Docker images are lightweight. You can ship or revert changes at the drop of a hat \u2014 perfect for short delivery process cycles where minimal downtime is crucial.<\/p>\n Scalability: <\/strong>Need to run 1,000 tests in parallel or support multiple teams working on microservices? No problem. Spin up multiple Docker containers whenever you need more build agents, and let Jenkins orchestrate everything with Jenkins pipelines.<\/p>\n For a DevOps<\/a> junkie like me, this synergy between Jenkins and Docker is a dream come true.<\/p>\n Before you roll up your sleeves, let\u2019s cover the essentials you\u2019ll need:<\/p>\n Docker Desktop<\/a> (or a Docker server environment) installed and running. You can get Docker<\/a> for various operating systems.<\/p>\n Jenkins downloaded from Docker Hub<\/a> or installed on your machine. These days, you\u2019ll want jenkins\/jenkins:lts (the long-term support image) rather than the deprecated library\/jenkins image.<\/p>\n Proper permissions for Docker commands and the ability to manage Docker images on your system.<\/p>\n A GitHub or similar code repository where you can store your Jenkins pipeline configuration (optional, but recommended).<\/p>\n Pro tip:<\/strong> If you\u2019re planning a production setup, consider a container orchestration platform like Kubernetes<\/a>. This approach simplifies scaling Jenkins, updating Jenkins, and managing additional Docker servers for heavier workloads.<\/p>\n After prepping your environment, it\u2019s time to create your first Jenkins-Docker pipeline. Below, I\u2019ll walk you through common steps for a typical pipeline \u2014 feel free to modify them to fit your stack.<\/p>\n Jenkins offers countless plugins, so let\u2019s start with a few that make configuring Jenkins with Docker easier:<\/p>\n Docker Pipeline Plugin<\/p>\n Docker<\/p>\n CloudBees Docker Build and Publish<\/p>\n How to install plugins:<\/p>\n Open Manage Jenkins<\/strong> > Manage Plugins<\/strong> in Jenkins.<\/p>\n Click the Available<\/strong> tab and search for the plugins listed above.<\/p>\n Install them (and restart Jenkins if needed).<\/p>\n Code example (plugin installation via CLI):<\/p>\n Pro tip (advanced approach):<\/strong> If you\u2019re aiming for a fully infrastructure-as-code setup, consider using Jenkins configuration as code (JCasC)<\/a>. With JCasC, you can declare all your Jenkins settings \u2014 including plugins, credentials, and pipeline definitions \u2014 in a YAML file. This means your entire Jenkins configuration is version-controlled and reproducible, making it effortless to spin up fresh Jenkins instances or apply consistent settings across multiple environments. It\u2019s especially handy for large teams looking to manage Jenkins at scale.<\/p>\n Reference:<\/strong><\/p>\n Jenkins Plugin Installation Guide<\/a>.<\/p>\n Jenkins Configuration as Code Plugin<\/a>.<\/p>\n In this step, you\u2019ll define your pipeline. A Jenkins \u201cpipeline\u201d job uses a Jenkinsfile (stored in your code repository) to specify the steps, stages, and environment requirements.<\/p>\n Example Jenkinsfile:<\/p>\n Let\u2019s look at what\u2019s happening here:<\/p>\n Checkout<\/strong>: Pulls your repository.<\/p>\n Build<\/strong>: Creates a built docker image (your-org\/your-app) with the build number as a tag.<\/p>\n Test<\/strong>: Runs your test suite inside a fresh container, ensuring Docker containers create consistent environments for every test run.<\/p>\n Push<\/strong>: Pushes the image to your Docker registry (e.g., Docker Hub) if the tests pass.<\/p>\n Reference:<\/strong> Jenkins Pipeline Documentation<\/a>.<\/p>\n Now that your pipeline is set up, you\u2019ll want Jenkins to run it automatically:<\/p>\n Webhook triggers<\/strong>: Configure your source control (e.g., GitHub) to send a webhook whenever code is pushed. Jenkins will kick off a build immediately.<\/p>\n Poll SCM<\/strong>: Jenkins periodically checks your repo for new commits and starts a build if it detects changes.<\/p>\n Which trigger method should you choose?<\/p>\n Webhook triggers<\/strong> are ideal if you want near real-time builds. As soon as you push to your repo, Jenkins is notified, and a new build starts almost instantly. This approach is typically more efficient, as Jenkins doesn\u2019t have to continuously check your repository for updates. However, it requires that your source control system and network environment support webhooks.<\/p>\n Poll SCM<\/strong> is useful if your environment can\u2019t support incoming webhooks \u2014 for example, if you\u2019re behind a corporate firewall or your repository isn\u2019t configured for outbound hooks. In that case, Jenkins routinely checks for new commits on a schedule you define (e.g., every five minutes), which can add a small delay and extra overhead but may simplify setup in locked-down environments.<\/p>\n Personal experience<\/strong>: I love webhook triggers because they keep everything as close to real-time as possible. Polling works fine if webhooks aren\u2019t feasible, but you\u2019ll see a slight delay between code pushes and build starts. It can also generate extra network traffic if your polling interval is too frequent.<\/p>\n Here comes the fun part \u2014 automating the entire cycle from build to deploy:<\/p>\n Build Docker image<\/strong>: After pulling the code, Jenkins calls docker.build to create a new image.<\/p>\n Run tests<\/strong>: Automated or automated acceptance testing runs inside a container spun up from that image, ensuring consistency.<\/p>\n Push<\/strong> to registry: Assuming tests pass, Jenkins pushes the tagged image to your Docker registry <\/strong>\u2014 this could be Docker Hub or a private registry.<\/p>\n Deploy<\/strong>: Optionally, Jenkins can then deploy the image to a remote server or a container orchestrator (Kubernetes, etc.).<\/p>\n This streamlined approach ensures every step \u2014 build, test, deploy \u2014 lives in one cohesive pipeline, preventing those \u201cwhere\u2019d that step go?\u201d mysteries.<\/p>\n Once your pipeline is up and running, here are a few maintenance tips and enhancements to keep everything running smoothly:<\/p>\n Clean up images: <\/strong>Routine cleanup of Docker images can reclaim space and reduce clutter.<\/p>\n Security updates: <\/strong>Stay on top of updates for Docker, Jenkins, and any plugins. Applying patches promptly helps protect your CI\/CD environment from vulnerabilities.<\/p>\n Resource monitoring: <\/strong>Ensure Jenkins nodes have enough memory, CPU, and disk space for builds. Overworked nodes can slow down your pipeline and cause intermittent failures.<\/p>\n Pro tip: <\/strong>In large projects, consider separating your build agents from your Jenkins controller by running them in ephemeral Docker containers (also known as Jenkins agents). If an agent goes down or becomes stale, you can quickly spin up a fresh one \u2014 ensuring a clean, consistent environment for every build and reducing the load on your main Jenkins server.<\/p>\n Although Jenkins supports multiple pipeline syntaxes, Declarative Pipelines<\/a> stand out for their clarity and resource-friendly design. Here\u2019s why:<\/p>\n Simplified, opinionated syntax: <\/strong>Everything is wrapped in a single pipeline { … } block, which minimizes \u201cscripting sprawl.\u201d It\u2019s perfect for teams who want a quick path to best practices without diving deeply into Groovy specifics.<\/p>\n Easier resource allocation: <\/strong>By specifying an agent at either the pipeline level or within each stage, you can offload heavyweight tasks (builds, tests) onto separate worker nodes or Docker containers. This approach helps prevent your main Jenkins controller from becoming overloaded.<\/p>\n Parallelization and matrix builds: <\/strong>If you need to run multiple test suites or support various OS\/browser combinations, Declarative Pipelines make it straightforward to define parallel stages or set up a matrix build. This tactic is incredibly handy for microservices or large test suites requiring different environments in parallel.<\/p>\n Built-in \u201cescape hatch\u201d: <\/strong>Need advanced Groovy features? Just drop into a script block. This lets you access Scripted Pipeline capabilities for niche cases, while still enjoying Declarative\u2019s streamlined structure most of the time.<\/p>\n Cleaner parameterization: <\/strong>Want to let users pick which tests to run or which Docker image to use? The parameters directive makes your pipeline more flexible. A single Jenkinsfile can handle multiple scenarios \u2014 like unit vs. integration testing \u2014 without duplicating stages.<\/p>\n Below are sample pipelines to illustrate how declarative syntax can simplify resource allocation and keep your Jenkins controller healthy.<\/p>\n Example 1: Basic Declarative Pipeline<\/strong><\/p>\n Runs on any available Jenkins agent (worker).<\/p>\n Uses two stages in a simple sequence.<\/p>\n Example 2: Stage-level agents for resource isolation<\/strong><\/p>\n Each stage runs in its own container, preventing any single node from being overwhelmed.<\/p>\n agent none at the top ensures no global agent is allocated unnecessarily.<\/p>\n Example 3: Parallelizing test stages<\/strong><\/p>\n Splits tests into two parallel stages.<\/p>\n Each stage can run on a different node or container, speeding up feedback loops.<\/p>\n Example 4: Parameterized pipeline<\/strong><\/p>\n parameters { stages { Lets you choose which tests to run (unit, integration, or both).<\/p>\n Only executes relevant stages based on the chosen parameter, saving resources.<\/p>\n Example 5: Matrix builds<\/strong><\/p>\n stages { Defines a matrix of PLATFORM x BROWSER, running each combination in parallel.<\/p>\n Perfect for testing multiple OS\/browser combinations without duplicating pipeline logic.<\/p>\n Additional resources<\/strong>:<\/p>\n Jenkins Pipeline Syntax<\/a>: Official reference for sections, directives, and advanced features like matrix, parallel, and post conditions.<\/p>\n Jenkins Pipeline Steps Reference<\/a>: Comprehensive list of steps you can call in your Jenkinsfile.<\/p>\n Jenkins Configuration as Code Plugin (JCasC)<\/a>: Ideal for version-controlling your Jenkins configuration, including plugin installations and credentials.<\/p>\n Using Declarative Pipelines helps ensure your CI\/CD setup is easier to maintain, scalable, and secure. By properly configuring agents \u2014 whether Docker-based or label-based \u2014 you can spread workloads across multiple worker nodes, minimize resource contention, and keep your Jenkins controller humming along happily.<\/p>\n Ready to supercharge your setup? Here are a few tried-and-true habits I\u2019ve cultivated:<\/p>\n Leverage Docker\u2019s layer caching: <\/strong>Optimize your Dockerfiles so stable (less frequently changing) layers appear early. This drastically reduces build times.<\/p>\n Run tests in parallel: <\/strong>Jenkins can run multiple containers for different services or microservices, letting you test them side by side. Declarative Pipelines make it easy to define parallel stages, each on its own agent.<\/p>\n Shift left on security: <\/strong>Integrate security checks early in the pipeline. Tools like Docker Scout<\/a> let you scan images for vulnerabilities, while Jenkins plugins can enforce compliance policies. Don\u2019t wait until production to discover issues.<\/p>\n Optimize resource allocation: <\/strong>Properly configure CPU and memory limits for Jenkins and Docker containers to avoid resource hogging. If you\u2019re scaling Jenkins, distribute builds across multiple worker nodes or ephemeral agents for maximum efficiency.<\/p>\n Configuration management: <\/strong>Store Jenkins jobs, pipeline definitions, and plugin configurations in source control. Tools like Jenkins Configuration as Code simplify versioning and replicating your setup across multiple Docker servers.<\/p>\n With these strategies \u2014 plus a healthy dose of Declarative Pipelines \u2014 you\u2019ll have a lean, high-octane CI\/CD pipeline that\u2019s easier to maintain and evolve.<\/p>\n Even the best systems hit a snag now and then. Here are a few hurdles I\u2019ve seen (and conquered):<\/p>\n Handling environment variability: <\/strong>Keep Docker and Jenkins versions synced across different nodes. If multiple Jenkins nodes are in play, standardize Docker versions to avoid random build failures.<\/p>\n Troubleshooting build failures: <\/strong>Use docker logs -f <container-id> to see exactly what happened inside a container. Often, the logs reveal missing dependencies or misconfigured environment variables.<\/p>\n Networking challenges: <\/strong>If your containers need to talk to each other \u2014 especially across multiple hosts \u2014 make sure you configure Docker networks or an orchestration platform properly. Read Docker\u2019s networking documentation<\/a> for details, and check out the Jenkins diagnosing issues guide<\/a> for more troubleshooting tips.<\/p>\n Pairing Docker and Jenkins offers a nimble, robust approach to CI\/CD. Docker locks down consistent environments and lightning-fast rollouts, while Jenkins automates key tasks like building, testing, and pushing your changes to production. When these two are in harmony, you can expect shorter release cycles, fewer integration headaches, and more time to focus on developing awesome features.<\/p>\n A healthy pipeline also means your team can respond quickly to user feedback and confidently roll out updates \u2014 two crucial ingredients for any successful software project. And if you\u2019re concerned about security, there are plenty of tools and best practices to keep your applications safe.<\/p>\n I hope this guide helps you build (and maintain) a high-octane CI\/CD pipeline that your team will love. If you have questions or need a hand, feel free to reach out on the community forums<\/a>, join the conversation on Slack<\/a>, or open a ticket on GitHub issues<\/a>. You\u2019ll find plenty of fellow Docker and Jenkins enthusiasts who are happy to help.<\/p>\n Thanks for reading, and happy building!<\/p>\n Subscribe to the Docker Newsletter<\/a>.\u00a0<\/p>\n Take a deeper dive in Docker\u2019s official Jenkins integration documentation.<\/a><\/p>\n Explore Docker Business<\/a> for comprehensive CI\/CD security at scale.<\/p>\n Get the latest release of Docker Desktop<\/a>.<\/p>\n Have questions? The Docker community is here to help<\/a>.<\/p>\n New to Docker? Get s<\/a>t<\/a>arted<\/a>.<\/p>","protected":false},"excerpt":{"rendered":" Hey there, fellow engineers and tech enthusiasts! I\u2019m excited to share one of my favorite strategies for modern software delivery: […]<\/p>\n","protected":false},"author":0,"featured_media":0,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"site-sidebar-layout":"default","site-content-layout":"","ast-site-content-layout":"default","site-content-style":"default","site-sidebar-style":"default","ast-global-header-display":"","ast-banner-title-visibility":"","ast-main-header-display":"","ast-hfb-above-header-display":"","ast-hfb-below-header-display":"","ast-hfb-mobile-header-display":"","site-post-title":"","ast-breadcrumbs-content":"","ast-featured-img":"","footer-sml-layout":"","ast-disable-related-posts":"","theme-transparent-header-meta":"","adv-header-id-meta":"","stick-header-meta":"","header-above-stick-meta":"","header-main-stick-meta":"","header-below-stick-meta":"","astra-migrate-meta-layouts":"default","ast-page-background-enabled":"default","ast-page-background-meta":{"desktop":{"background-color":"var(--ast-global-color-4)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"ast-content-background-meta":{"desktop":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"footnotes":""},"categories":[4],"tags":[],"class_list":["post-1629","post","type-post","status-publish","format-standard","hentry","category-docker"],"_links":{"self":[{"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/posts\/1629","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/types\/post"}],"replies":[{"embeddable":true,"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/comments?post=1629"}],"version-history":[{"count":0,"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/posts\/1629\/revisions"}],"wp:attachment":[{"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/media?parent=1629"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/categories?post=1629"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/tags?post=1629"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}Why combine Docker and Jenkins for CI\/CD?<\/h2>\n
Setting up your CI\/CD pipeline with Docker and Jenkins<\/h2>\n
Building a robust CI\/CD pipeline with Docker and Jenkins<\/h2>\n
1. Install necessary Jenkins plugins<\/h3>\n
\njava -jar jenkins-cli.jar -s http:\/\/<jenkins-server>:8080\/ install-plugin docker-pipeline
\njava -jar jenkins-cli.jar -s http:\/\/<jenkins-server>:8080\/ install-plugin docker
\njava -jar jenkins-cli.jar -s http:\/\/<jenkins-server>:8080\/ install-plugin docker-build-publish\n<\/div>\n2. Set up your Jenkins pipeline<\/h3>\n
\n agent any
\n stages {
\n stage(‘Checkout’) {
\n steps {
\n git branch: ‘main’, url: ‘https:\/\/github.com\/your-org\/your-repo.git’
\n }
\n }
\n stage(‘Build’) {
\n steps {
\n script {
\n dockerImage = docker.build(“your-org\/your-app:${env.BUILD_NUMBER}”)
\n }
\n }
\n }
\n stage(‘Test’) {
\n steps {
\n sh ‘docker run –rm your-org\/your-app:${env.BUILD_NUMBER} .\/run-tests.sh’
\n }
\n }
\n stage(‘Push’) {
\n steps {
\n script {
\n docker.withRegistry(‘https:\/\/index.docker.io\/v1\/’, ‘dockerhub-credentials’) {
\n dockerImage.push()
\n }
\n }
\n }
\n }
\n }
\n}\n<\/div>\n3. Configure Jenkins for automated builds<\/h3>\n
4. Build, test, and deploy with Docker containers<\/h3>\n
5. Optimize and maintain your pipeline<\/h3>\n
Why use Declarative Pipelines for CI\/CD?<\/strong><\/h3>\n
Declarative Pipeline examples<\/strong><\/h3>\n
\n agent any
\n stages {
\n stage(‘Build’) {
\n steps {
\n echo ‘Building…’
\n }
\n }
\n stage(‘Test’) {
\n steps {
\n echo ‘Testing…’
\n }
\n }
\n }
\n}\n<\/div>\n
\n agent none \/\/ Avoid using a global agent at the pipeline level
\n stages {
\n stage(‘Build’) {
\n agent { docker ‘maven:3.9.3-eclipse-temurin-17’ }
\n steps {
\n sh ‘mvn clean package’
\n }
\n }
\n stage(‘Test’) {
\n agent { docker ‘openjdk:17-jdk’ }
\n steps {
\n sh ‘java -jar target\/my-app-tests.jar’
\n }
\n }
\n }
\n}\n<\/div>\n
\n agent none
\n stages {
\n stage(‘Test’) {
\n parallel {
\n stage(‘Unit Tests’) {
\n agent { label ‘linux-node’ }
\n steps {
\n sh ‘.\/run-unit-tests.sh’
\n }
\n }
\n stage(‘Integration Tests’) {
\n agent { label ‘linux-node’ }
\n steps {
\n sh ‘.\/run-integration-tests.sh’
\n }
\n }
\n }
\n }
\n }
\n}\n<\/div>\n
\n agent any\n
\n choice(name: ‘TEST_TYPE’, choices: [‘unit’, ‘integration’, ‘all’], description: ‘Which test suite to run?’)
\n }<\/p>\n
\n stage(‘Build’) {
\n steps {
\n echo ‘Building…’
\n }
\n }
\n stage(‘Test’) {
\n when {
\n expression { return params.TEST_TYPE == ‘unit’ || params.TEST_TYPE == ‘all’ }
\n }
\n steps {
\n echo ‘Running unit tests…’
\n }
\n }
\n stage(‘Integration’) {
\n when {
\n expression { return params.TEST_TYPE == ‘integration’ || params.TEST_TYPE == ‘all’ }
\n }
\n steps {
\n echo ‘Running integration tests…’
\n }
\n }
\n }
\n}\n<\/p><\/div>\n
\n agent none\n
\n stage(‘Build and Test Matrix’) {
\n matrix {
\n agent {
\n label “${PLATFORM}-docker”
\n }
\n axes {
\n axis {
\n name ‘PLATFORM’
\n values ‘linux’, ‘windows’
\n }
\n axis {
\n name ‘BROWSER’
\n values ‘chrome’, ‘firefox’
\n }
\n }
\n stages {
\n stage(‘Build’) {
\n steps {
\n echo “Build on ${PLATFORM} with ${BROWSER}”
\n }
\n }
\n stage(‘Test’) {
\n steps {
\n echo “Test on ${PLATFORM} with ${BROWSER}”
\n }
\n }
\n }
\n }
\n }
\n }
\n}\n<\/p><\/div>\nBest practices for CI\/CD with Docker and Jenkins<\/h3>\n
Troubleshooting Docker and Jenkins Pipelines<\/h2>\n
Conclusion<\/h2>\n
Learn more<\/h2>\n