Don’t get mad a Jenkins, talk to your lead for not using it right.
I recently read an article about someone bashing Jenkins. I’ll refrain from backlinking the article cause it isn’t worth your time to read. The article read as if a team member (not a lead) was complaining about Jenkins and the process/pipeline that was into place for their dev team. The argument was “not every company’s cultural environment would allow for continuous integration/deployment/delivery”.
Every team should have a process in place and that process better be as automated as possible.
I’ve been thrown into teams that have zero process and literally cowboy code their way through their professional careers. To be honest (before I joined more structured environments) I was thinking and doing the same things. I get it. When you have a boss that wants things done yesterday and doesn’t fully grasp the technology; bad estimates and unrealistic expectations happen. There should be no reason to rush things that can be done right. However, there are managers out there that almost roll around like a pig in mud over the idea of hacking together “demos” that are held together by scotch tape, bubble gum, and rubber bands. If you take a step back and you’re in this situation, you are the poor roadie running around with the circus setting up an entire carnival every week. Why not build a sustainable theme park once, build it right, and something unique versus your competitors? Do market research! Look at the competitive landscape, the data available, the target demographics, the possible ROI, your runway of time you have to build and sell it with your currently available capital. These things are simply overlooked in all kinds of companies that put the cart before the horse.
Jenkins is that silent killer of bad/broken code.
Often it is overlooked on the business side that a process must be put into place to get projects put into a pipeline and properly distributed in a responsible way. Burnout is real and so is abusing your development team. Drive by managers that stand over you and walk around with a stick (this is a real story) are a viscously toxic environment to be in. Instead of building products, you’re building smoke and mirror demos. That is the best way to ensure you’ll never get to market with a minimum viable product (an MVP as they say in the startup world). It is far too often that the business over promises, under delivers, and give unrealistic deadlines without consulting their development team. This is the environment I see the author of this Jenkins bashing article must be in (and has never seen these processes work). Project leads/managers are a critical piece of managing the two sides of the coin (both business and development).
Every company & team, needs some sort of documented process to get work done. This is where tools like Jira, Confluence, Jenkins, GitHub, etc. come into play. These tools are the cornerstones of any happy and productive development team. I’d love to see anyone claim otherwise because I’m sure I can prove they are completely clueless when it comes to running a development team. Here is why these tools (and others like them) make the team strong, structured, organized, and productive:
- Having code reviews to allow for more knowledge transfer, security auditing, and accountability is detrimental to any software shop.
- Recording projects, business requests, support tickets, and other work is so important to keep everyone on the same page about timelines, expectations, and workload management. Without this, there is a hell of a lot of assuming happening on both sides (business and development) that things get lost in translation. Ever play that game telephone back in elementary school?
- Documenting, Documenting, Documenting! Oh my gosh how often is this never done? I get it. Things get out of date and it is sometimes hard to capture complex things in a wiki. Thats where things like videos, charts, diagrams, and other tools need to be leveraged if documenting isn’t enough. Redundancy within your development team becomes so much easier when you spend a small bit of time passing the knowledge on in a documented way. Not just pair coding or sitting down with one person, but actually documenting it and holding a team meeting to go over it.
- Continuous Integration is a massive productivity booster. Manual (or worse, undocumented) release processes are no longer acceptable ways of ever doing deployments within a team. Would you go driving if there were no stop lights, signs, and other “processes” in place to prevent you from crashing? No you wouldn’t, so why would you allow for a brittle release process to remain in place? Say no to regression testing, finger crossing FTP deployments, and other horse crap. Start saying yes to automation! Testing, deployments, builds, monitoring, alerting, and other things become massive productivity boosters to make the team comfortable.
Think of Jenkins as the commander that does what he’s programmed to do.
Jenkins is a automation tool that you can use for so many things other than just deploying & testing code. I’m curious about setting up some IoT related things in Jenkins at home just to try it out. It is a fantastic tool that has been around for quite awhile and it isn’t going anyway. Tons of CI/CD startups are popping up left and right. My only guess is because people don’t know how to use Jenkins and give in to paid products that just “do it for them” and there is nothing wrong with that. As long as you have something in place for your team to utilize, then fantastic! I’ve used GitLabs CI stuff a bit and it seemed to work pretty well too. More custom things you might want to leverage Jenkins for still.
If you’ve never used Jenkins or automation tools before, I highly recommend looking into it. Don’t fool yourself into thinking your manual process works. The only reason it works is because of your “tribal knowledge” that only you and hopefully a few others on your team knows. If you asked a new developer on your team to do the same process, they might have no clue where to start without a documented process. However, if it is as easy as logging into Jenkins and hitting ONE BUTTON then even a caveman can do it. Heck, you can even setup SCM polling and not even have to hit any damn buttons to begin with.
One of the best quotes I’ve ever heard within a development environment was:
“At the end of the day, it just f-cking works.” ~ Some Irish guy with a thick accent
Stay classy internet.
This is a true statement. However, if nobody knows how it works; then you’re playing with fire.
?
Happy coding and keep on deploying!
-Josh
@PHPVegas
#VegasTech