Nice mustache, sir! Jenkins 2.x tips and tricks

One year ago the first Jenkins 2.x release has changed the product paradigm dramatically. Now you don’t have to waste hours clicking UI buttons calling shell scripts from stage windows. Now you can do almost everything from a source code.

You can use a Groovy DSL. Surely, that’s less readable than YAML supported by TravisCI and other CI/CD systems. But Groovy lets you customize your CI workflow as you wish. With Groovy you can write complex high-level programming constructions, making CI logic stronger.

Generally Jenkins became more automated for setup and configuration. Here I’d like to share my experience after migration from Bamboo. The post is divided by 3 lists: plugins, DSL tips and gotchas.

Plugins

From the box Jenkins provides only the core functionality. At the setup process it suggests some plugins for your future workflow. If you have no idea, I’d suggest you to skip this step and install plugins as it will be necessary.

You might know about “Pipeline” plugin which allows to make your CI as a code. Probably, it doesn’t lack description and information, so don’t talk about it. Surely, you’ll install a Docker build plugin if you use Docker for builds and testing. I’d like to suggest some plugins which you might not know. But they’re very useful, trust me.

1. Amazon EC2 plugin

Page: Amazon EC2 plugin

This is the feature you’ll really love being on AWS. This plugin sets up dynamic slaves running on EC2. All you need – ready AMI for the slave and a couple of minutes to configure the instance settings.

Finally you’ll get as much slaves as you want restricting only by EC2 limits. It scales by itself although the plugin is waiting for 10-15 minutes when queue is not empty. The idea in autoscaling. You can get 10 slaves when you have to build a lot of services, but have zero at nights and weekends. Cool, isn’t?

2. Mission Control plugin/Pipeline aggregator

Page: Mission Control plugin/Pipeline aggregator

These 2 plugins provide an alternative view on Jenkins jobs. Plugins for hobbyists, but allow to look at the Jenkins different way.

3. Google Login plugin

Page: Google Login plugin

Fits nice if you host your mail on Google or hast have everyone on your team having a GMail. You can sign up and sign in from a Google account through oAuth restricting the domain if necessary. Now you don’t have to to proceed a manual registration or make a new users manually.

4. Github Organization Folder plugin

Page: Github Organization Folder plugin

The most lovely plugin in Jenkins if you’re using a Github organization. You can set up an organization as a special job. At first Jenkins will scan all repositories in organization. If Jenkins will find a Jenkinsfile – it will create a job for each repo and each branch automatically. Now you shouldn’t do a lot in Jenkins UI to have multiple builds set up at once.

5. Github Pull Request builder

Page: Github Pull Request builder

This plugin lets you to create a special build job for each pull request.

6. Blue Ocean

Page: Blue Ocean

Fresh and powerful Jenkins UI for pipeline builds visualisation. Just take a look at it and you’ll desire to have a Blue Ocean installed in your Jenkins.

7. Embeddable build status

Page: Embeddable build status

Generates a build status icon as every self-respecting CI. You can use embeddable build status in Markdown, Confluence docs and so on.

8. AWS Pipeline plugin

Page: AWS Pipeline plugin

This plugin offers beautiful one-line Groovy methods for AWS tasks. Examples are: upload/download files from S3, invalidate Cloudfront cache. Also plugin provides a withAWS construction to configure region, account credentials and other parameters.

9. Active Choices Plug-in

Page: Active Choices Plug-in

I use this plugin to dynamically generate choice parameters for the job. One of the use-cases is to create a Deployment job and fetch stable builds from appropriate job. This might be the only way you can clearly link build and deployment in Jenkins. From the box Jenkins provides only build concept, but not the deployment. That’s the main feature of Bamboo that we used before.

DSL tips

To make this post slim, I will leave the code in my Github repo. Also I left there some comments for functions purposes.

You can make a global library and write the code you use in multiple projects. This global libraries feature may be called a killer feature. You don’t need to copy-paste a code anymore or use global functions!

Gotchas

Of course, Jenkins has some shortcomings and pitfalls. Here they are.

1. Plugins sandboxes

I talk about the thing that doesn’t really exists. And that’s a problem. Sometimes you can see the ugly stacktrace because of one plugin configuration mismatch. One time after Slack plugin configuration I’ve got a stack trace on the home page!

It’s not so terrible and distracting as you may think. Just watch out installing and configuring new plugins.

2. Groovy. Just a Groovy

If you already know what Groovy is, you may skip this gotcha. But, personally, as a Python-only developer, some Groovy concepts took me by surprise breaking some of my builds. Probably, that’s all are human mistakes. But Groovy won’t protect you of them having a flexible syntax as you won’t have in YAML.

3. Buggy Blue Ocean interface

It’s fresh and buggy. Probably, CloudBees need some time to make it mature. If you, for example, push the button, the screen won’t refresh to proceed to the new pipeline stage by itself. In most cases you have to reload page and all will be fine, but from the first time it seems like a button doesn’t work.

Also you cannot use an Active Choice plugin with Blue Ocean. The plugin doesn’t support a dynamic parameterization.

Conclusion

Hope that I clearly explained how awesome new Jenkins is. We also tried another release-engineering base systems to skip a tool evangelism. But there is no one system who allows you to break the borders if you want to go deeper with workflow configuration. Also Jenkins is open-source which allows you to save a lot of money. In comparison, all systems except GoCD, Concourse, GitlabCI and Buildbot are must-paid.

So, try some things in your CI/CD and let me know at the comments if I missed something.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s