Today’s post will be about the Jenkins build automation server. Jenkins is an open source service, which’s sole purpose is to integrate code changes in a repository as soon as possible. Builds can either be triggered time-based (E.g. every 12 hours) or event-based (everytime someone commits to the GIT or SVN repository). Read more to know how to setup a continuous integration server down below! I also use continuous integration while developing Immortal Dungeons.
What is continuous integration and delivery?
In short, continous integration and delivery means integrating the code changes your developers make into the “project” as soon as possible. This enables you and your team to find and fix errors as early as possible. The project is built from a code versioning repository every now and then, and developers get to see reports, log files and more from every build! This is far better than the old approach, integrating code at the end of the project.
Read more about this on the wikipedia article here.
What can Jenkins do?
Jenkins enables you to perform the steps for integration automatically. As i have written above, automated build-chains can be triggered by one of two things:
- Time-based triggering: Means that Jenkins executes a build every six hours for example.
- Event-based triggering: Means that Jenkins executes a build every time a developer commits code to the repository for example.
Automated build-chains in Jenkins can execute every script you want it to. This enables you to do more than “just” compiling your code automatically. This means you can do the following things:
- Perform software builds using a build system like Maven, Gradle or Ant
- Execute shell scripts
- Archive build results (also called “build artifacts”)
- Run software tests
- Run detailed automated reports, log files, etc…
- Automate deployment to production systems (delivery)
Jenkins carefully monitors these things for you and can decide to stop the build if a set fails.
How do I set up my own Jenkins build server?
Installing your own Jenkins server is as easy as pie: At first, you have to add the official Jenkins repository to your package manager. Jenkins is a very active projects and is frequently updated by it’s community. This makes it easy to keep it up-to-date.
wget -q -O - http://pkg.jenkins-ci.org/debian/jenkins-ci.org.key | apt-key add - sh -c 'echo deb http://pkg.jenkins-ci.org/debian binary/ > /etc/apt/sources.list.d/jenkins.list'
Then, the next logical step would be to update the package lists and install the package on your system:
apt-get update apt-get install jenkins
Per default, the server starts on port “8080” on your machine. If the installation was successful, you should already be able to reach your server. Type the following URL into your browser:
And that is all! It’s easy as that to install your own automated build server. Continue reading if you want to know how to use jenkins!
Setting up Jenkins plugins to extend it’s functionality
This step also includes how to install commonly used plugins for build automation. Some of them include:
- Maven, Gradle or Ant plugin for automatic your builds
- Report plugins for showing you reports on how the build was executed
- Plugins for automatic deployment and delivery
You can install new plugins via “Manage Jenkins” -> “Manage Plugins” menu. If you want a list of all available Jenkins plugins, please see this list here. Basically, plugins extend the already existing functionality of your build server.
Setting up Jenkins “Jobs”
All builds of projects are called “Jobs” in Jenkins. One server can handle multiple jobs for different projects, or just one job if you have only one project. The resulting compiled programs and reports are also called “build artifacts”.
To create a job, select “New Item”. You can then select what type of job you want to create. Options include:
- Freestyle projects (Which will be sufficient in most cases)
- External Jobs
- Multi-Configuration Projects
- .. and many more which will not be covered here!
As your new job is created you can configure it to do many different things. The first page is called the “General” page:
- Projects name and description
- Log rotation (keep “x” number of build artifacts for maximum “x” days)
- Build throttling (to prevent sudden high loads)
- Allowing execution of concurrent build
The second page is the “Source Code” page, which contains information and credentials about your code repository:
- Repositories, which can be GIT or SVN
- Build branches
- Repository Browsers
- Credentials for repository access
The third page is called “Build Triggers”. Here you can tell Jenkins when exactly a build needs to be executed. Options include:
- Remote triggering (Remote scripts, etc…)
- Build after other Builds have been executed (Allows “Build-Chaining”)
- Build periodically (time-based building)
- Git hook triggering
- SCM polling (like cronjobs)
The fourth and last page I will cover here is the “Build” page. Here you can define one or more build steps fo your newly created jobs. Steps can be anything, from executing linux commands, running scripts to compiling with Maven, Gradle or Ant build systems.
That’s it! If you followed the steps carefully, you should now be able to continuously integrate your code changes, and automatically deploy and deliver your builds to production systems, customers and many more! If you want to know more, be sure to check out the comments section or contact me via the guestbook or the contact-page.
The post Continuous Integration and Delivery using Jenkins appeared first on Austrian Homebrew Studio.