Continuous integration platforms are broken – here's what needs fixing

...which is exactly why you have a well defined CI pipeline that prevents buggy code from being committed.

No one "checks in" anything any more.

If you walk calmly down the street and get where you're going, no-one pays any attention.

If you walk down the street, fall on your ass and then perform a Bruce Lee/Kung Fu ("Ninja!") backflip to correct the problem then people say "Wow! That guy is Agile!"

Peer recognition is therefore predicated on first falling on your ass.

Re: What? The snake oil not working?

Original Chinese Snake Oil contains 20 percent eicosapentoaenoic acid which has strong analgetic and anti-inflammatory properties. It's Nurofen!!!

Re: What? The snake oil not working?

This time it will be different!

CI is fine

Well...I'm as sceptical as anyone about the cults of Agile and DevOps. (Both have fairly reasonable ideas at their core, and the people who came up with Agile were mostly perfectly sensible software developers who just wanted to do some software development, but of course they got taken over by a bunch of charlatans and turned into ridiculous management cults). But CI (properly understood) is really a pretty simple and sensible idea that doesn't *need* to be tied to either of the cults. It's really just this:

0. Have some tests.

1. Don't take any code that doesn't pass them.

...that's it. That's the whole thing. And it's really not a bad idea - especially since adopting CI forces projects which hadn't done 0 yet to do it, which is a very *very* good thing.

Your code really *should* have a good test suite that's easy to run. And once you've got that, it's really not difficult at all to set up some hooks to run it whenever someone wants to merge code, and reject it if the tests fail. It's simple to understand, it's not that difficult to set up (especially in ecosystems where there's a kinda standard way of doing it, like github+travis), and it really *does* help.

It's not a panacea, of course not, and anyone who tells you it is should be laughed at. It doesn't replace, you know, planning, or integration testing, or lots of other things you should still be doing. But it sure does help.

(Sadly there does seem to be a nascent Cult of CI developing, which at least from where I'm sitting mainly seems to be based around completely misunderstanding what CI actually is and applying the term to all sorts of other stuff.)

Re: Here's what I'd like...

Visual Studio + TFS supports almost all of your points there.

1. The build server is still a separate thing, but it uses the exact same compiler and generates the same error messages as a local build.

2. As above, they're the same messages and are delivered to whoever pushed to the build server, which can reject the build (gated build).

3. You can send selfsets to other developers, I think that might cover this.

4. You can set TFS to deploy to a set environment after every check-in, or at intervals and you can do it multiple times so that covers this entirely.

Requiring tests to pass also an option.

Anyway, my point is that Microsoft's tooling already supports 99% of what you want to do here. I'm really surprised this isn't common across the board. What are you using? Subversion? CVS? TI Pocket Calculators?

Re: Stability

I work as a web app developer so can sympathise. But to me, a lot of the problems we see are not to do with things like jquery vs React, etc. They're to do with the fact everyone is so focused on "automation", version control, CI, or whatever other bullshit buzzword they've read about. And whilst focusing on these they have dropped "old fashioned" core principles like planning and testing (previously known as "common sense" and "what you should be doing anyway").

You want to build a web app for a browser in 2017? It's not that hard. Write a detailed plan of what you're going to do. If you get some tosser saying it has to be done in a "agile" way, stay away from them, because they've no idea what it really takes to deliver software successfully. As you go along, throughly test things - yes, manually *shock horror*, with human input and interaction. Once you get to the end and have completed your final fixes/tests, it's unlikely to "break" unless either the code is randomly changed without testing (which it shouldn't be) or a *new* browser that wasn't around for your testing at the time comes along. In the latter case it may never cause an issue and should be a relatively minor one if you've planned and coded the application well.

Even now I bet someone will downvote this or say, oooh why would you use manual/human processes when there is *insert new tech in this space*. Well, it's because some of us know how to do things properly, which is why I'm able to take some time to write this at lunch, rather than piss around configuring a CI tool.

Re: Stability

What I love is how npm package updates ALWAYS break something. Half the time the developer of the package has made so many breaking changes you have to totally re-write the code that calls that package. I wish I could say we're writing wrappers around every 3rd-party plugin now, but we're not...

This is annoying for front-end JS, but if you're using Node.JS it's horrible. Your entire application can require days of reworking when you update a single package, which then causes all of it's dependencies to update. And even simple Node applications have 50 - 100 packages because of dependencies.