"An extendable open source continuous integration server" Jenkins is open source and watched over by creator Kohsuke Kawaguchi
Using Jenkins as told by the Jenkins wiki.
I love to use Jenkins because of this philosophy "If something hurts, do it more often". Build up your endurance and make an action so commonplace that you don't notice it anymore. Automating repetitive tasks with Jenkins is my favorite way to make tasks commonplace.
when you have your deployment process under control, you can make your servers dance up and down— patrickdebois (@patrickdebois) January 5, 2015
Here's the secret about Jenkins: Jenkins is just doing what you do locally to build your app.
You're building a Java app with Maven? That's all Jenkins is doing too. Running the same exact
mvn command as you. Your build engineers are not mind readers. They'll need to learn what you know and what you've built.
Does you application require a half dozen special arguments be passed in to the
mvn command that builds it? Then you still need to pass them to your
mvn in Jenkins. Jenkins is magical, but not *that* magical.
You are able to use any custom shell script your team has to build your application. Jenkins can support this by checking the script out with your code and running your build commands.
Same thing for Ant, Gradle or node.js (with Grunt or Gulp task runners).
What you do locally to build your app is what you will have Jenkins configured to do.
After the initial setup, Jenkins jobs can be automated as much as the law allows.
- Check code in.
- It is built.
- It is deployed.
- The app server is bounced.
- Integration tests verify the deployed app.
- Deploy app to next shared app in your build pipeline. Dev -> QA or QA -> Stage etc.
With Jenkins you do step 1 and watch the rest happen.
More like - what doesn't Jenkins do? #amirite
The built in functionality for building your application is arguably trumped by the added functionality of the 922 (and growing) plugins that exist for Jenkins servers.
Like I said with npm (and Chef before that) - it's all been done before!
But some plugins are better than others. Check for key stats like:
- Number of downloads.
- Last updated.
- Start with the web interface for your Jenkins server.
- Graduate to managing your plugins with Chef!
- Chef Identity (I wrote this one, so it gets top billing)
- SCM Sync Configuration
- Active Directory
- Jabber Integration
- Jira Integration
- Artifactory Integration
- Download the jar
java -jar jenkins.war
- Load Jenkins
- Create a job
- Pick your source code location
- Set how often to look for source code changes
- Execute your build command(s)
- Execute your post build steps
But you might be configuring your build jobs for days to get things tweaked just right!
- Use the Long Term Support version for critical build servers.
- Jenkins runs as a user on the build server, with their own SSH keys, etc.
- If you're using Node.js/Ruby/Python you need to install that on the build server, and put it in the $PATH
- Creating new build jobs. As your Jenkins usage matures, this will be scripted with plugins.
Cuddle up with a nice book.
This book will walk you through server setup and give you numerous examples of setting up very precise features in Jenkins with both built in features and plugins. Highly recommended.
"Continous Delivery" is like drinking from a fire hose. Read it, learn it, love it. But to execute on it - pick just one small thing from one chapter you can do to improve your workflow. Rinse and repeat. Which sounds exactly like what? Agile software development. Small chunks, quick feedback and evaluation.
We are going to complete the following actions:
jenkins.waris already on the project's Vagrant VM in the user's home directory.
- Get in to the home directory of the VM to find Jenkins.
- Let's do the most basic startup for Jenkins with a
java -jar jenkins.warand leave the console open. We will need the output.
- Open Jenkins in your browser and complete the installation prompts accepting the defaults.
- Create a new item (from the left menu) that is a Freestyle job named
Docker Imageshas a Build Step of a Execute Shell command of
docker images. and verify output.
- Create a second item that is Freestyle job named
Docker Buildthat will build your Docker image from before.
- Have the Execute Shell command start with a
cd /vagrant/dockerto use our local Dockerfile from the previous section (so we don't have to check out the code again).
- Run our
buildcommand again, but change the tag so we end up with
docker build -t jenkins-atb ./added to our local shell command.
Docker BuildJenkins job and watch the output.
jenkins-atbimage in the list!
ctrl-Cto shutdown the server.