How to Set Up Jenkins From Scratch on Your Own PC in 5 Minutes

Author: Thabo Krick | Date: September 16, 2020

  • Jenkins continues to grow even more popular in all branches of software development but the getting-started-barrier is still conceived to be quite high by some people
  • You don't have to wait for your IT department to get hands-on experience and start automating your software delivery process
  • See how easy it is to get started with Jenkins from scratch on your own Windows 10 laptop!

"We know that Jenkins is great and all but we're not some cloud-based start up. It would take ages to have server infrastructure available only to realize that it doesn't support our workflows and tools after all."

Even though Jenkins is rapidly growing in automotive embedded software development I hear a lot of stories like the one above. This tells me that:

  1. The threshold to get started with Jenkins is conceived to be quite high
  2. People prefer not to involve the IT department if there's another way
  3. A certain level of confidence can only be aquired by hands-on experience

In contrast to many other examples I avoided the use of the command line because many Windows users are not as comfortable with command line interfaces as Linux users. This article requires no prior knowledge of Jenkins but assumes that you have an internet connection and know the basics of using source code management systems (scm) like Git, Subversion, Mercurial, TFS or similar. If SCM terms like commit / checkout / clone / push / pull don't mean anything to you I recommend to do some research on the topic. The getting started page from Git explains the concept pretty nicely.

In order to get have Jenkins running on our own laptop we will perform the following three simple steps:

  1. Install the required software
    • Git as the scm tool
    • Tortoise to have a user interface to interact with Git
    • Jenkins
  2. Create a local git repository
  3. Create and run a pipeline





Setting up a git repository

We will make use of git to have a local source code repository but you can replace that by any other source code management system (Subversion, TFS, etc.). A source code repository is the central container for any continuous delivery (CD) pipeline. One of the core principles of designing a solid CD pipeline is to make the steps work in isolation. It shouldn't matter where your code is built and tested. However, what you can still rely on is the internal structure of the files in your source code repository.

We'll create a local repo on you machine that you can freely use for experiments without impacting existing production systems:

Creating & Running the Pipeline

Hook it up to Jenkins

Since the Jenkinsfile already contains every detail about which steps to execute it's easy to add this to Jenkins as a Pipeline job.

Running the Pipeline

Before we run the pipeline let's switch over to the Blue Ocean UI (see screenshot). Although the Blue Ocean UI looks much nicer it's easy to get lost if you're used to the classic UI. You can always return to that by clicking onto the -> button on the upper right corner ("Go to classic").


Further thoughts

You might be asking yourself why we only needed to install one piece of software for Jenkins. Isn't Jenkins supposed to run in a client-server setting? It's true that there's usually one main server* which orchestrates everything and provides the web ui and a couple of agent machines that take over the actual workload. However, the Jenkins master (which is what we installed) can also take over work. Although this is not recommended for production systems it's a great way to have a small local setup to use for experiments.

*there could be more than one - but let's ignore that for now

Next Steps

You have now successfully installed Jenkins on your local PC or laptop and know how to create local repositories that you can commit files to. Use this to your advantage and try to create some prototypes that support workflows which are relevant for your team's software build. I hope this article motivates you to get started with Jenkins to get some hands on experience.

Check out to learn more about the syntax and available steps for your Pipeline (Jenkinsfile) or reach out to the community in case you need help with something more specific.

And please also watch our video tutorial showing the main steps of this process:

 The Author:

Thabo Krick studied Economic Computer Science at the University of Oldenburg and joined BTC Embedded Systems AG in 2013 as a student. With his team he set up the Jenkins-based software pipeline for BTC development and testing activities across all departments. After his Bachelor degree, he developed plugins and provided technical support for BTC EmbeddedPlatform customers world-wide. Since 2017 Thabo has provided trainings and consulted customers from the automotive domain regarding their testing process, ISO 26262 and automation. In 2018 he became a "Certified Jenkins Engineer" by successfully passing the exam at the Jenkins World Congress in Nice/France. 

Connect with me on LinkedIn


Jenkins Master

The server running jenkins which provides a web ui for user access, serves as the central connection hub for agent machines and manages global configuration, credentials and scheduling of jobs.

Jenkins Agent

Also called "slave", "worker" or "node". A (virtual) machine that runs the main workload. The Jenkins Master distributes the work on the available pool of slaves and handles a queue in case there's too much to do.


A job defines configuration (e.g. link to a source code repository, specification of the required environment) and specifies tasks that shall be executed. There are different types of jobs, mainly the "classic Job" which is configured via the Jenkins web UI and the Pipeline job for which the configuration is done in a text file. Having the job configuration in a text file which is stored along side the code is a huge advantage because changes in the configuration are just as visible as changes in the code and makes it easy to consistently revert to an earlier version.

A job is created once and can then be executed many times. The individual runs of a job are called "Build". An incremented build number is used to distinguish between multiple builds of the same job.


After completion a build usually has one of the following status values:
- Successful (green): everything worked as expected, tests have passed
- Unstable (yellow): there were no errors but something marked the build as unstable (e.g. warnings or failed tests)
- Error (red): there was an error during the execution of the job. This usually implies that the job did not produce any results.


To visualize different phases in your Pipeline you can define different stages and each stage may contain any number of steps.