3 ms·

It's possible to deploy Jenkins "right", but good grief is that rare. The typical Jenkins deployment feels like every new project or pipeline demands a new plug

by subway 8y ago

It's possible to deploy Jenkins "right", but good grief is that rare. The typical Jenkins deployment feels like every new project or pipeline demands a new plugin, and will harass the ever loving piss out of you to upgrade if any of those plugins get a bit stale. Why run a command in a shell build step when you can install a plugin that abstracts everything away in a non-intuitive manner?

simmanian 8y ago
In your opinion what does a good jenkins deployment setup look like? Do you have any examples? Our Jenkins looks like it's about to blow up from all those plugin warnings.
- subway 8y ago
  They keys, in my book, are to avoid plugins absolutely anywhere possible. Don't allow your Jenkins Master to create the Jenkins Slaves -- instead create the slaves via the same tooling your create the master, and register them with the master via the same (or similar) discovery mechanisms you use elsewhere in your environment. Don't use plugins that configure your build tool of choice. Yes, it's initially spiffy that you can click around and change ant's behavior, but when things break you can almost never repro manually. Shell steps. Shell steps. Shell steps. Make sure it's trivial to manually execute any step in the pipeline. It should be rare that you actually manually execute the step, but it helps you avoid landing in situations where it's impossible to debug the Jenkins build, because your plugin or non-shell step insists on cleaning up after itself in a manner you can't manually override. Finally, read this before even getting started: https://queue.acm.org/detail.cfm?id=2841313 https://queue.acm.org/detail.cfm?id=2841313 Once you've read it, read it again.
nineteen999 8y ago
We keep Jenkins job config/logs in a git repository which is checked out into /var/lib/jenkins. When we want to add a plugin or whatever we just add it to the plugins repos, git add/commit the repository and re-kickstart the Jenkins VM. The Jenkins kickstart then just restore the previous git config/logs back into /var/lib/jenkins. Everything comes back as it was, but the new/upgraded plugins are available. Easy peasy. But then again we don't have a huge number of jenkins jobs or a massive cluster of Jenkins masters/slaves so yeah. You could feasibly do it without re-kickstarting the machine, but we like to show off how the Jenkins server can rebuild itself with a self-hosted Jenkins job.

by subway 8y ago

simmanian 8y ago

In your opinion what does a good jenkins deployment setup look like? Do you have any examples? Our Jenkins looks like it's about to blow up from all those plugin warnings.

subway 8y ago
They keys, in my book, are to avoid plugins absolutely anywhere possible. Don't allow your Jenkins Master to create the Jenkins Slaves -- instead create the slaves via the same tooling your create the master, and register them with the master via the same (or similar) discovery mechanisms you use elsewhere in your environment. Don't use plugins that configure your build tool of choice. Yes, it's initially spiffy that you can click around and change ant's behavior, but when things break you can almost never repro manually. Shell steps. Shell steps. Shell steps. Make sure it's trivial to manually execute any step in the pipeline. It should be rare that you actually manually execute the step, but it helps you avoid landing in situations where it's impossible to debug the Jenkins build, because your plugin or non-shell step insists on cleaning up after itself in a manner you can't manually override. Finally, read this before even getting started: https://queue.acm.org/detail.cfm?id=2841313 https://queue.acm.org/detail.cfm?id=2841313 Once you've read it, read it again.

nineteen999 8y ago

We keep Jenkins job config/logs in a git repository which is checked out into /var/lib/jenkins. When we want to add a plugin or whatever we just add it to the plugins repos, git add/commit the repository and re-kickstart the Jenkins VM. The Jenkins kickstart then just restore the previous git config/logs back into /var/lib/jenkins. Everything comes back as it was, but the new/upgraded plugins are available. Easy peasy. But then again we don't have a huge number of jenkins jobs or a massive cluster of Jenkins masters/slaves so yeah. You could feasibly do it without re-kickstarting the machine, but we like to show off how the Jenkins server can rebuild itself with a self-hosted Jenkins job.