One lesson i had beaten into me at an old job is that software should come with a self-contained reproducible build with an absolute minimum of external dependencies (which might be none at all). If GAE provided a zip file with everything in it, all set up and ready to go, you could download that and get working.

But making a self-contained build is hard, so nobody ever does it.

Java has got usefully close in recent years. You can download and build a Gradle project with only a JDK and a shell installed, plus HTTP out to the internet; the project can (should!) contain a standard wrapper script which can download the right version of the build tool, and the build tool can then download the right versions of the dependencies and do the build. The downloads are cached locally so you don't download the internet on every build. The wrapper script only does straightforward stuff, so it doesn't require a particular shell or version, and the JVM changes slowly and safely enough that you can get away with being pretty sloppy about versions (ie any Java 8, 2014 - 2017+, will do).

There's no dependency on having some SDK installed, or some version of the runtime, or some build tool, or some package manager, or any other bits and bobs. Just a shell and a JDK. You don't have the problems listed in the article, and you don't have to invest time in avoiding them.

The next step would be for the wrapper to download the JDK itself, but i think that's unlikely to happen, due to bandwidth and licensing.

Once you're in the build tool, there are strong conventions about what's where. The 'build' task should do everything; 'check' should run every kind of validation possible; 'assemble' should build every artifact. Ideally, none of them should require any setup, although that requires some discipline on the developer's part.

I don't know of any good way to set up things MySQL or RabbitMQ if you need those for integration tests, which is definitely a problem. Perhaps we need a Docker plugin, so in my build i can say "to run the integration tests, download and start the following images, and inject the container IP addresses into the tests like so". The usual way to get around this is to use pure Java in-memory options for integration tests (eg H2 for a database, maybe something like HornetQ for a message queue), and you can get those like any other dependency, with no manual setup needed.

Sorry for the ramble. tl;dr yaks are bad, but there is hope for canned pre-shaved yaks.