Jenkins Pipeline TTFHW

CI Server: No More Manual Project Setup:

One of the greatest ironies of recent times has been that the least automated part of our process has been the very heart of automation, the CI server. To set up each project, you had to operate a UI manually, only to have to repeat the process again manually if anything ever happened to that server, or even just that project. Crazy.

Finally, with Jenkins Pipeline – now every CI project can be code, and it’s stored with the rest of the code in the project’s SCM, where it belongs. Niiiiice. Other CI systems, like TravisCI might have arrived there first, but so many of us already use Jenkins, and the price is right, too.

Extra Win for Personal Projects or MicroServices

Jenkins Pipeline is even a bigger win for personal projects or microservices, because the proliferation of lots of projects on less stable machines is more common.

As an architect or product guy, for example, I might experiment with dozens of projects over a period of weeks, trying out different combinations of platforms or tooling, to get just the right combination. Using a CI server for such projects would be extremely time consuming if I had to click through all those installs with a UI screen. And I wouldn’t even use a cloud instance for such a server, I’d grab some abandoned local box and use that. But only if it was fast, and the setup was disposable.

13 minute Walk Through

It took me longer to slog through the docs on the Jenkins Pipeline than it should have. The docs are good, and thorough. I just needed a faster ramp up. And a much smaller set of options, I only care about pipeline code that lives in my source repo.

Don’t even worry if you want to move it to another box or boxes later. That’s what Jenkins Pipeline is about – the server is just that – a server. Your pipeline code lives in the project source, where it belongs.