“Leeroy Jenkins” is what my backend guys say right before they huck a major DB upgrade into prod without testing it in staging.
Always Friday at 16:59 right?
Right before a long weekend where Monday is a government holiday.
Also, Leeroy tried to optimize his PTO and hooked a backpacking trip onto the long weekend. He will be out all week and will have no phone reception.
But he will have chicken.
Our old Jenkins box is called Leroy, and my old place it was called Jankins. Thankfully we’ve moved on from that trash.
Real talk- I agree with this meme as truth.
The more and more I use CICD tools, the more I see value in scripting out my deployment with shell scripts and Dockerfiles that can be run anywhere, to include within a CICD tool.
This way, the CICD tool is merely a launch point for the aforementioned deployment scripts, and its only other responsibility is injecting deployment tokens and credentials into the scripts as necessary.
Anyone else in the same boat as me?
I’d be curious to hear about projects where my approach would not work, if anyone is willing to share!
Edit: In no way does my approach to deployment reduce my appreciation for the efforts required to make a CICD pipeline happen. I’m just saying that in my experience, I don’t find most CICD platforms’ features to be necessary.
This is pretty much what we do as well
All the build logic is coded in python scripts, the jenkins file only defines the stage (with branch restrictions) and calls the respective script function.
This means it works on all machines and if we need to move away from jenkins integration with a new ci platform would require minimal effort.
You’re not advocating against CI like the meme seems to be, but rather for CI builds to be runnable on human’s machines and the results should be same/similar as in when running w/in the CI system. Which is what CI folks want anyway.
Removed by mod
What’s wrong with Docker?
Removed by mod
I’ve found Docker helpful when I want to use it to build binaries or use CLI tools that may not be available directly on the CICD platform. Also, Docker makes it easier to run the same code on MacOS that I ended up running on a Linux CICD server.
What would you consider to be overuse of containers?
Then you would probably enjoy concourse
I don’t think there is a single right or wrong answer but to play devils advocate making your CI tooling lightweight orchestration for your scripts that do the majority of the work means you lose the advantages of being able to easily add in third party tools that you want to integrate with your pipeline (quality, security, testing, reporting, auditing, artefact management, alerting, etc). It becomes more complex the more pipelines you are creating while maintaining a consistent set of tooling integrations.
Honestly, CI is only meaningful on bigger projects (more than 100 man-hours invested in total). So I most often go without.
But I do see its point.
Counterpoint: watching little green checkmarks appear when my PR passes a pipeline step gives me dopamine
I’m a bit confused. I thought “build system” referred to systems like autotools, scons or cmake. How are they related to green checkmarks? Couldn’t one also get green checkmarks when using a build shell script or makefile?
Is a CI/CD pipeline not a build system?
(this isn’t a “gotcha”, I genuinely may have misunderstood the post)
Ah, good 'ol Jenkins. It’s on my list of software I never want to use again, twice.
One feature was really sweet though: being able to edit the Jenkinsfile script inline and run it. On the other hand, that encouraged the wild cowboy lands. Contrasted to GitHub Actions, you get to see how many commits it took to get right 🙃
Nobody will see me force push to “bugfix/gitlabCI” the 10th time today…
What’s wrong with Jenkins? Works pretty great for automated scripts that need to run on a schedule, but I imagine you and this post specifically mean in reference to CI/CD
I work for a very large company which uses Jenkins for CI/CD and it’s an absolute nightmare. Granted, some of these issues may be related to how my company has it setup. I’m not in DevOps so I wouldn’t know. But these are my complaints:
-
Can have incredibly long queue times in some cases. It takes forever to spin up additional build agents to meet demand. In one case we actually had to abort a deploy because Jenkins wasn’t spinning up more build agents, and our queue times were going to put us outside of our 3 HOUR maintenance window.
-
Non-standard format for pipeline configuration files. It could just be JSON or YAML, but noooo, I have to learn something completely different that won’t transfer to other products.
-
Dated and overly complicated UI with multiple UX issues. I can view the logs in a modal from the build page, but I can’t copy from them? Fuck off Jenkins.
I’m actively pushing my team to transition to GitHub actions, because it’s just better in every single way.
Ah man, yeah I use it for a much more constrained and very narrow use case. We only use GitHub actions for CI/CD, it can be clunky itself in some aspects but otherwise works great.
And if you have a large company and many teams, you think actions will help? (Aside from the UI issues you mention). Rebuilding the Jenkins from scratch now would probably get rid of most of your problems, but in a year is gonna be a mess. It’s similar to how it’s going to go with and CI.
Also, a good DevOps person or team will keep the Devs happy (or at least, not very unhappy) with any tool, a bad one will suck anyhow.
At least that’s my experience.
-
Allow me to blow your mind: my Jenkins build calls build.sh because I’m not a fuckin idiot
Joke’s on you. I have a Jenkins hook from github to trigger build.bat! :P
Yeah sure. Try building anything more complex than helloworld.c with a build.sh
The point is that “build.sh” implies a single file, which becomes an absolute nightmare to maintain on larger projects
I believe he goes by Leroy
Ha ha. I work on Bazel (a great build tools, https://bazel.build), and I agree 100%.
God I hate bazel/blaze.
Thanks? I’m not sure why you wanted to share that with me.
Hey buddy can you step over here, there’s a very tall cliff I want you to see
If I break our master build in CI, I get multiple emails and people saying “fix this”!!! I wouldn’t have to fix it if you stopped letting people commit directly to master and stopped using git rebase! 😁
The build system issue is getting out of control. Just look at cmake
When your build system is a build system for build systems you know something went wrong years ago
build.shis no build system?edit: URL arser should require
*://.I’ve been using Gearset for Salesforce CI/CD for a while and it’s pretty simple to get up and running and it just kind of works. I’m looking into integrating it with Azure for our .net stack but not sure how smoothly that will go.
