this post was submitted on 10 Sep 2023
730 points (98.4% liked)
Programmer Humor
25649 readers
2916 users here now
Welcome to Programmer Humor!
This is a place where you can post jokes, memes, humor, etc. related to programming!
For sharing awful code theres also Programming Horror.
Rules
- Keep content in english
- No advertisements
- Posts must be related to programming or programmer topics
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
I recently made a small pure JS package at my company. It just fucking worked, can you believe it? No setting up compilation and CI/CD for build + release. Just put it in the repo and publish manually, and it just worked, it's ridiculous
CI/CD is useful regardless of which language you’re using. Sooner or later some customer is going to yell at you because you didn’t discover the fatal error before deploying.
@magic_lobster_party @alphacyberranger @unsaid0415 CI/CD won't prevent that. I wonder what it is for. Not using the CPU on my laptop for tests? And why would I want to commit before knowing the tests pass?
CICD isn't an alternative to testing your own work locally. You should always validate your work before committing. But then once you do, the CICD pipeline runs to run the tests on the automation server and kicks off deployments to your dev environment. This shows everyone else that the change is good without everyone having to pull down your changes and validate it themselves. The CICD pipeline also provides operational readiness since a properly set up pipeline can be pointed to a new environment to recreate everything without manual setup. This is essential for timely disaster recovery.
If you're just working on little projects by yourself, it's usually not worth the time. But if you're working in anything approaching enterprise grade software, CICD is a must.
He says as though he's never had two PR merges conflict logically with each other
@Stumblinbear I only worked on small projects so far, that's probably why I don't understand it. But a merge commit is like any other commit and the person pushing this commit has to make sure it works.
When working in teams, merging in two pull requests with seemingly unrelated changes is common practice. If I had to rebase and re-run tests every time another PR got merged in while mine was awaiting reviews, I'd spend most of my time running tests