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 past two years, 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 matches 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.
If you want to get the most from Jenkins, you really should write your own plugins. This session will explain why you should, what you can change or add to Jenkins, and how to do it.