I've just posted the slides and speaker notes from a session I gave a couple of years ago on using the Jenkins CI server. I focussed on the whys and wherefores of writing your own plugins. In time since I wrote and present the session, Jenkins has continued to move on and evolve, but I still believe the slides are valid. To fully exploit a tool, you have to shape it to you, not you to it.
The original abstract reads:
Jenkins is a widely used and extremely capable continuous integration server. While it's been available since 2007, under it's original name of Hudson, in popularity seems to have really taken off in the past year or so. One of the primary reasons for its success is it's extremely flexible configuration. Jenkins has a quite a small core, with most of its functionality provided through plugins. Jenkins plugins provide access to different source code control systems, a wide variety of build tools, test result tracking and charting, static analysis tools, and so on. Nearly every aspect of Jenkins can be customised via a plugin. At time of writing there are over 400 different Jenkins plugins available.
Four hundred is too few.
Over the little while we've from dabbling with CI to Jenkins forming part of our core toolset. Jenkins builds on checkin, yes, but also deploys builds into development environments. It runs performances tests and records the history. It tells us which build contains which bug fixes. It also does our release builds - tagging the repository, building from the tag, writes release notes telling us which work packs have been updated, pushes the build up onto the live server, and emails Ops to say everything is ready to go. The standard plugins provide the foundation, but the our own plugins have put Jenkins at the heart of our development process.
[Add a comment]