5 ms·

Does anyone still use Jenkins willingly?

by tn890 7y ago

lewich 7y ago
what is your problem with it? :) It is usually not the tool bad, but ppl using it can't do it right.
- zelos 7y ago
  Not the OP, but I’m wary about implementing build logic in a form that’s only executable on a server. Pipelines are one step better than the old style build configuration, but still inferior to just having the whole build/test/release cycle defined in scripts in the branch which can be run anywhere.
  - pintxo 7y ago
    Your Jenkins pipeline could just be a singe step: run 'sh ./build.sh && ./test.sh && ./deploy.sh' We have gone for middle ground, the pipeline has a small number of discrete steps, but these steps mainly just call scripts defined besides the code within the respective repo. That way one can replay the process manually wherever needed, but we still can easily see in Jenkins where the process fails, including submitting test results to jenkins to see directly in the web-ui which tests failed.
  - M3t0r 7y ago
    We have started using Makefiles for this. Our Jenkinsfiles are only used for the orchestration and reporting. All our applications can be build, tested, and released by our employees on their machines. Works great for us!
  - pnako 7y ago
    I have a simple Python script with a function for each step. When called with no arg it runs everything; this way I can trivially run a full CI build on my laptop. You can also call individual steps, which I do from a Jenkinsfile. This way you can still see a nice pipeline woth different steps. All this runs in Docker. This is integrated almost properly with Gitea (only thing missing is an icon in Gitea on success/failure). Jenkins is fine behind the firewall. Its not terribly elegant but its very flexible.
- M3t0r 7y ago
  In my experience a ton of corner cases, plenty of bugs, and really really shitty documentation. That doesn't really help people handle the software well.
- ownagefool 7y ago
  I think that's a fairly big statement. I worked with Robert and told him I wasn't a fan of the shared libraries approach because it abstracts the workflow away from the team, when the reality is we want more people to understand the pipeline, not less. Jenkins itself is a bit of a hodgebodge of legacy crap. - Plugins that do next to nothing. Hard to reproduce this. - Inability to run locally; gives you the rope to hang yourself. - Bit of a security mess - Upgrade and admin story historically pretty poor; lack of infrastructure as code, etc. Conflicting versions when you restore. - Unclear story on relying on state. Why isn't my build environment clean? Jenkins is actually a pretty good tool, especially when you use it well. But once you're been around the block a couple of times and deal with teams failing with a tool, for a variety of reasons, you start to wonder if maybe the complexity of the tool itself is the culprit.
  - silon42 7y ago
    I've used Jenkins quite a bit and I like it a log and it's flexibility. The problem is that it has many features but not all have been added in an orthogonal way so can't be combined well. (Pipelines actually made this much worse IMO).
- AnthonBerg 7y ago
  You deserve better than Jenkins. I promise.
johnnyAghands 7y ago
You are not alone wondering this. I find there are less brittle more modern task runners available today, however Jenkins still has a strong hold on traditional enterprise IT systems that struggle with change. My theory is it has to do with the whole traditional break up of responsibilities between dev and operations. As more developers are taking over ops (cough devops cough) they’re quickly replacing Jenkins with systems that align well to what they’re used to (rich CLI support, rich programming support, Unix like) vs. zero programming required plugin based. So it’s not that Jenkins is necessarily bad — it just doesn’t fit in with the new crowd — although I personally think it just sucks in general and can single-handedly destroy modern CI/CD dev culture, but that’s JOPO...
pjc50 7y ago
What's the new hotness that people are replacing it with?
- perlgeek 7y ago
  Not really a new hotness, but https://www.gocd.org/ https://www.gocd.org/ is very good for building pipelines and graphs. Not so great for classical CI workloads (you can't say "test every branch that fits the pattern smokeme/*"). Upgrades to GoCD have been very predictable, in contrast to Jenkins :-)
- chatmasta 7y ago
  GitLab CI is a good choice for new projects. It’s incrementally adoptable, self hostable, there are lots of people working on it, and it will probably be around for a while.
  - vraivroo 7y ago
    I had the misfortune of having to use GitLab CI recently. GitLab gets a lot of leeway from HN, maybe because it's an underdog, but it wasn't ready for prime time. Several features were just broken, and several more did things in surprising ways (not what you usually want to see in a key infrastructure component).
    - chatmasta 7y ago
      Definitely, it has its problems. The documentation also seems to lag behind the product (and there are duplicated pages for CE and EE, very confusing). Personally it was easy for me to switch from travis because all my CI scripts are actually bash scripts, so the .yml CI file is just a few lines pointing to those scripts. All I had to do with gitlab was make a base image to be the "CI image" with all the tooling necessary + docker-in-docker.
- johnnyAghands 7y ago
  Drone, Circle CI, GitLab CI, Concourse CI, Semaphore, Travis CI
BjoernKW 7y ago
Willingly? Probably not. One reason why Jenkins is so widely used in enterprise companies is that within traditional corporate structures person hours are readily available whereas software purchases have to be approved by someone with budgetary discretion. It's generally much more expensive to customise and maintain a brittle Jenkins installation than it is to buy a comparatively low-maintenance turnkey CI / CD solution. However, the people who can do that customisation and maintenance work usually are there already anyway. Therefore people rarely bother with finding the most appropriate or most cost-effective solution but settle for the one that comes with the least resistance.
- peterwwillis 7y ago
  I can't even count how many person-hours we have paid to create virtually unsupportable duplicated Jenkins instances and jobs, most of which are one-offs and nowhere in code. Maintenance isn't even a question; if the old instance is buggy, somebody else just makes a different one-off and you move your job there. Jenkins is a fantastic way to waste time and money.
hcho3 7y ago
I manage a continuous integration server for an open source project that contains CUDA code. To test, we need to run workers with NVIDIA GPUs, and so far I haven't seen a viable alternative to Jenkins.
- mikewhy 7y ago
  Could throw gitlab-ci-runner on a machine: either windows, macos, or linux, and register it. There's also a way to get CUDA working in Docker by passing the device paths, which gitlab-ci-runner can also use.
shodan666 7y ago
I'm managing the production on the server with over 50 engineers working directly in shell on daily basis... I moved 100+ various scripts from Cron to Jenkins in this year, including some mission ciritial applications. Jenkins makes it super easy to know and measure what is going on, and setup procedures for failback.

Does anyone still use Jenkins willingly?

by tn890 7y ago

Does anyone still use Jenkins willingly?

lewich 7y ago

what is your problem with it? :) It is usually not the tool bad, but ppl using it can't do it right.

zelos 7y ago
Not the OP, but I’m wary about implementing build logic in a form that’s only executable on a server. Pipelines are one step better than the old style build configuration, but still inferior to just having the whole build/test/release cycle defined in scripts in the branch which can be run anywhere.
- pintxo 7y ago
  Your Jenkins pipeline could just be a singe step: run 'sh ./build.sh && ./test.sh && ./deploy.sh' We have gone for middle ground, the pipeline has a small number of discrete steps, but these steps mainly just call scripts defined besides the code within the respective repo. That way one can replay the process manually wherever needed, but we still can easily see in Jenkins where the process fails, including submitting test results to jenkins to see directly in the web-ui which tests failed.
- M3t0r 7y ago
  We have started using Makefiles for this. Our Jenkinsfiles are only used for the orchestration and reporting. All our applications can be build, tested, and released by our employees on their machines. Works great for us!
- pnako 7y ago
  I have a simple Python script with a function for each step. When called with no arg it runs everything; this way I can trivially run a full CI build on my laptop. You can also call individual steps, which I do from a Jenkinsfile. This way you can still see a nice pipeline woth different steps. All this runs in Docker. This is integrated almost properly with Gitea (only thing missing is an icon in Gitea on success/failure). Jenkins is fine behind the firewall. Its not terribly elegant but its very flexible.
M3t0r 7y ago
In my experience a ton of corner cases, plenty of bugs, and really really shitty documentation. That doesn't really help people handle the software well.
ownagefool 7y ago
I think that's a fairly big statement. I worked with Robert and told him I wasn't a fan of the shared libraries approach because it abstracts the workflow away from the team, when the reality is we want more people to understand the pipeline, not less. Jenkins itself is a bit of a hodgebodge of legacy crap. - Plugins that do next to nothing. Hard to reproduce this. - Inability to run locally; gives you the rope to hang yourself. - Bit of a security mess - Upgrade and admin story historically pretty poor; lack of infrastructure as code, etc. Conflicting versions when you restore. - Unclear story on relying on state. Why isn't my build environment clean? Jenkins is actually a pretty good tool, especially when you use it well. But once you're been around the block a couple of times and deal with teams failing with a tool, for a variety of reasons, you start to wonder if maybe the complexity of the tool itself is the culprit.
- silon42 7y ago
  I've used Jenkins quite a bit and I like it a log and it's flexibility. The problem is that it has many features but not all have been added in an orthogonal way so can't be combined well. (Pipelines actually made this much worse IMO).
AnthonBerg 7y ago
You deserve better than Jenkins. I promise.

johnnyAghands 7y ago

You are not alone wondering this. I find there are less brittle more modern task runners available today, however Jenkins still has a strong hold on traditional enterprise IT systems that struggle with change. My theory is it has to do with the whole traditional break up of responsibilities between dev and operations. As more developers are taking over ops (cough devops cough) they’re quickly replacing Jenkins with systems that align well to what they’re used to (rich CLI support, rich programming support, Unix like) vs. zero programming required plugin based. So it’s not that Jenkins is necessarily bad — it just doesn’t fit in with the new crowd — although I personally think it just sucks in general and can single-handedly destroy modern CI/CD dev culture, but that’s JOPO...

pjc50 7y ago

What's the new hotness that people are replacing it with?

perlgeek 7y ago
Not really a new hotness, but https://www.gocd.org/ https://www.gocd.org/ is very good for building pipelines and graphs. Not so great for classical CI workloads (you can't say "test every branch that fits the pattern smokeme/*"). Upgrades to GoCD have been very predictable, in contrast to Jenkins :-)
chatmasta 7y ago
GitLab CI is a good choice for new projects. It’s incrementally adoptable, self hostable, there are lots of people working on it, and it will probably be around for a while.
- vraivroo 7y ago
  I had the misfortune of having to use GitLab CI recently. GitLab gets a lot of leeway from HN, maybe because it's an underdog, but it wasn't ready for prime time. Several features were just broken, and several more did things in surprising ways (not what you usually want to see in a key infrastructure component).
  - chatmasta 7y ago
    Definitely, it has its problems. The documentation also seems to lag behind the product (and there are duplicated pages for CE and EE, very confusing). Personally it was easy for me to switch from travis because all my CI scripts are actually bash scripts, so the .yml CI file is just a few lines pointing to those scripts. All I had to do with gitlab was make a base image to be the "CI image" with all the tooling necessary + docker-in-docker.
johnnyAghands 7y ago
Drone, Circle CI, GitLab CI, Concourse CI, Semaphore, Travis CI

BjoernKW 7y ago

Willingly? Probably not. One reason why Jenkins is so widely used in enterprise companies is that within traditional corporate structures person hours are readily available whereas software purchases have to be approved by someone with budgetary discretion. It's generally much more expensive to customise and maintain a brittle Jenkins installation than it is to buy a comparatively low-maintenance turnkey CI / CD solution. However, the people who can do that customisation and maintenance work usually are there already anyway. Therefore people rarely bother with finding the most appropriate or most cost-effective solution but settle for the one that comes with the least resistance.

peterwwillis 7y ago
I can't even count how many person-hours we have paid to create virtually unsupportable duplicated Jenkins instances and jobs, most of which are one-offs and nowhere in code. Maintenance isn't even a question; if the old instance is buggy, somebody else just makes a different one-off and you move your job there. Jenkins is a fantastic way to waste time and money.

hcho3 7y ago

I manage a continuous integration server for an open source project that contains CUDA code. To test, we need to run workers with NVIDIA GPUs, and so far I haven't seen a viable alternative to Jenkins.

mikewhy 7y ago
Could throw gitlab-ci-runner on a machine: either windows, macos, or linux, and register it. There's also a way to get CUDA working in Docker by passing the device paths, which gitlab-ci-runner can also use.

shodan666 7y ago

I'm managing the production on the server with over 50 engineers working directly in shell on daily basis... I moved 100+ various scripts from Cron to Jenkins in this year, including some mission ciritial applications. Jenkins makes it super easy to know and measure what is going on, and setup procedures for failback.