3 ms·

As somebody who has spent his share of time interacting with Jenkins as a user, and messing around inside it as a developer, I am definitely biased. For or agai

As somebody who has spent his share of time interacting with Jenkins as a user, and messing around inside it as a developer, I am definitely biased. For or against, I'm not sure tho ;-) But the problem with Jenkins is the problem with all CI. Our (software in general, not Jenkins specifically) build process are all godforsaken nightmares that would put HP Lovecraft and Rube Goldberg into rubber rooms. You can't add a bunch of extra automation to any of these systems and get something better, let alone a system that needs to be able to automate so many different and unique snowflake horrors.

eternityforest 3y ago
Maybe it's time for languages themselves to start defining what CI means, the way they currently define how builds and packages work. They already include test frameworks. It would be cool to have, at least as an experiment, a language with no snowflake horrors at all, if it runs at all, it's in the language or framework's One True Way All Tools Understand. Static typing, maybe even linter warnings as fatal errors, anything that makes adding CI a hassle just doesn't exist. Maybe it could even refuse to run without full test coverage. So you could take any project at all, click "Turn on CI" and that's that, there's only one CI config that exists. I'm guessing the number of use cases would be tiny to nonexistant in the startup centric tech world, but they might be some of the least stressful projects ever made!
- Sophistifunk 3y ago
  The problem is that a real green-field re-imagination of software development needs to go back to the 70s, and back to the (these days mostly fake) metal, meaning it's a massive job that will take years to even know if you might make it. You need to start with something simple-but-useless, and grow it from there, rather than attacking a single layer or two of our current enormous tower of babel. It will be difficult to adopt because it must by definition be alien to our current workflows, and it will take forever to find users. The only way to find success is to slowly and surely build something that is so obviously good existing devs will be willing to give up tools in which they've invested years and (for many of them) their identities, just to play with it. It requires an iron clad vision, willingness to be a pariah among the coding masses and a dictator internally, excellent communication in order to present the vision and progress to the outsiders who are interested, and piles and piles of money to pay for it for years before it becomes sustainable, however you plan to make it so.

eternityforest 3y ago

Maybe it's time for languages themselves to start defining what CI means, the way they currently define how builds and packages work. They already include test frameworks. It would be cool to have, at least as an experiment, a language with no snowflake horrors at all, if it runs at all, it's in the language or framework's One True Way All Tools Understand. Static typing, maybe even linter warnings as fatal errors, anything that makes adding CI a hassle just doesn't exist. Maybe it could even refuse to run without full test coverage. So you could take any project at all, click "Turn on CI" and that's that, there's only one CI config that exists. I'm guessing the number of use cases would be tiny to nonexistant in the startup centric tech world, but they might be some of the least stressful projects ever made!

Sophistifunk 3y ago
The problem is that a real green-field re-imagination of software development needs to go back to the 70s, and back to the (these days mostly fake) metal, meaning it's a massive job that will take years to even know if you might make it. You need to start with something simple-but-useless, and grow it from there, rather than attacking a single layer or two of our current enormous tower of babel. It will be difficult to adopt because it must by definition be alien to our current workflows, and it will take forever to find users. The only way to find success is to slowly and surely build something that is so obviously good existing devs will be willing to give up tools in which they've invested years and (for many of them) their identities, just to play with it. It requires an iron clad vision, willingness to be a pariah among the coding masses and a dictator internally, excellent communication in order to present the vision and progress to the outsiders who are interested, and piles and piles of money to pay for it for years before it becomes sustainable, however you plan to make it so.