/
JENKINS TIPS Ideas  for making your life with Jenkins easier JENKINS TIPS Ideas  for making your life with Jenkins easier

JENKINS TIPS Ideas for making your life with Jenkins easier - PowerPoint Presentation

pamella-moone
pamella-moone . @pamella-moone
Follow
348 views
Uploaded On 2018-12-06

JENKINS TIPS Ideas for making your life with Jenkins easier - PPT Presentation

JENKINS TIPS November 2014 When presented with a choice pick a solution thats easy to configure and maintain Me just now DISCLAIMER This presentation is not meant to be regarded as scripture Instead it captures the authors personal preferences when dealing with Jenkins ID: 737508

build jenkins plugin post jenkins build post plugin project plugins install email configuration http windows support port updating builds

Share:

Link:

Embed:

Download Presentation from below link

Download Presentation The PPT/PDF document "JENKINS TIPS Ideas for making your life..." is the property of its rightful owner. Permission is granted to download and print the materials on this web site for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.


Presentation Transcript

Slide1

JENKINS TIPSIdeas for making your life with Jenkins easierSlide2

JENKINS TIPSNovember 2014 Slide3

“ When presented with a choice, pick a solution that’s easy to configure and maintain. ”(Me, just now)Slide4

DISCLAIMER: This presentation is not meant to be regarded as scripture. Instead, it captures the author’s personal preferences when dealing with Jenkins as a Continuous Integration server.Slide5

CONTENT TABLE1. Jenkins configuration

2

.

Jenkins project configuration

Internal Only

The presentation is divided into two big chapters:Slide6

1. Jenkins configurationInternal Only1.a

Jenkins

installation

1.b Post install configurationSlide7

Standalone installation vs.Deploying to an application server 1.a) Jenkins installationStandalone installation:Native package available for Windows, MacOS and most popular Linux/BSD distrosOn Windows, Jenkins is installed as an independent service, and it is configured to start automatically upon system boot

Deploying to an application server potential advantages:

n

o extra port used :)

slightly lower RAM usage, in theorySlide8

Editing Jenkins’ configuration file1.b) Post install configurationThe jenkins.xml file is located in Jenkins' installation folder (Windows 32-bit default: C:\Program Files (x86)\Jenkins\).Recommended : change Jenkins' HTTP port from its default value of 8080 (to prevent current / future Tomcat conflicts)Optional

: change java version /

java arguments (

i.e

-XX:-

UseGCOverheadLimit

-

Dmail.smtp.starttls.enable="true" -Xms256m -Xmx512m -XX:MaxPermSize=512m -XX:+CMSClassUnloadingEnabled -XX:+CMSPermGenSweepingEnabled)Slide9

Running Jenkins as “Local System”vs.Using a dedicated account1.b) Post install configurationThe Windows “Jenkins” service runs as the “Local System” user by default; change it to a dedicated account to get rid of PATH-related headaches (i.e. missing folders/configuration files for Maven

/ A

nt

builds; personal experience with

grunt

(JS

build tool))Slide10
Slide11

Jenkins Global Settings(http://localhost:<HTTP_port>/configure)1.b) Post install configurationThe Global Settings screen exposes a limited set of basic configs, including:- workspace / build root directories- number of executors: number of concurrent build jobs

- JDK, ANT, Maven installations

This screen will also be used for configuring additional plugins.Slide12

Updating Jenkins and plugins1.b) Post install configurationOften, when accessing the “Manage Jenkins” section, you will be greeted with the following screen:Slide13

Updating Jenkins and plugins1.b) Post install configurationPersonal suggestions for updating Jenkins / plugins:Jenkins: go right ahead, you can always downgrade if needed (which shouldn’t happen very often)plugins: don’t fix it if it’s not broken - I wouldn’t recommend updating plugins for no good reason, especially after you start configuring projects using those plugins (as a practical example, Jenkins comes with a 1.x version of the SVN plugin, while early versions of the 2.x plugin did not support SVN format 1.8)Slide14

Installing additional plugins(http://localhost:<HTTP_port>/pluginManager/available)1.b) Post install configurationUseful plugins:1) pre-scm-buildstep – allows running tasks before code checkout2) Deploy to container plugin

– deploy war to application server

3)

Email-

ext

plugin

– provides an upgrade over

the default email plugin, being more configurable4) GitHub Plugin – adds Git

support (Jenkins doesn't support Git repositories out of the box)5) Gradle Plugin – adds Gradle

support

6)

Cucumber Reports Plugin

– adds support

for

creating "pretty

" Cucumber reportsSlide15

Configuring the email-ext plugin for a gmail account1.b) Post install configurationSlide16

2. Project configurationInternal Only2

.a “Staging” environment

2

.b Managing disk usage

2.c Downstream projects

2.d Using scripts

2.e Build triggers

2.f Email notificationsSlide17

2.a) “Staging” environmentTest project updates in a “staging” environment before applying them to your “production” Jenkins!However, if the “staging” environment is on a development machine, make sure you keep your workspaces separated; don’t check “Advanced Project Options - Use custom workspace” (personal experience with conflict between IntelliJ IDEA – which uses the locally installed SVN client – and Jenkins – which uses its SVN plugin)Slide18

Out of the box, Jenkins keeps everything forever!2.b) Managing disk usageN.B: Depending on project specifics, additional clean up may be required (e.g. C:\Windows\Temp)Check

"Days to keep artifacts" / "Max # of builds to keep with artifacts" (as appropriate) if you only want to delete artifacts (

war,jar,zip

) but keep logs/reports for project

metrics!Slide19

2.c) Downstream projectsDefine independent projects for build / automated testsUse "Build other project" post-build action on the main build, check "Block build when downstream project is building" Advanced option

Only

include a small set of smoke tests to run for each build; run full automated regression for the "nightly" build

Keeping

build and automated tests projects separatedSlide20

2.d) Using scriptsHighly recommended for control freaks (can be used to replace some plugins, e.g. deploy, which fails sometimes)Can be executed before/during/after buildFor project independence, use embedded scripts if you don't want to keep track of your filesSlide21

2.e) Build triggersBuild triggering strategies:Use “Build periodically” for “nightly” builds“Poll SCM” for everything elseFor impatient people, builds can be triggered “on commit” - copy .git\hooks\post-commit.sample to .git

\hooks\post-commit

-

add the following line to the

post-commit

file:

“curl http://localhost:<port>/job/<

yourJob>/build?delay=0sec”Slide22

2.f) Email notificationsDon’t spam!Only send notifications for failed builds (configure trigger in the extended email plugin’s “Advanced Settings”)Slide23

Q & A