I think the most important things developers should consider is the target OS (and version), the programming language (and version), and the libraries (and the versions) you use when building a tool. All of these challenges can be thoroughly tested using continuous integration, but to take full of advantage of those features we would need to write tests to cover all the methods and statements, and to write good tests we need documentation. Therefore, I think it would take a lot of work to get most academic software to the point of using continuous integration because I can't think of many toolkits that actually have a test suite and documentation (not just a readthedocs webpage because that is not helpful at the command line or for developing).
Getting there is much easier than you might think though, every Perl package I build has tests to check syntax, formatting, and check that every method is documented, so I can focus on more important things. Of course, a prerequisite to building a system like this is to use version control because you can't maintain a script/package from just your computer and expect it to work in another environment.
You asked for examples, so I will share some features of Perl that I wish more people in bioinformatics knew about. Since Perl doesn't consider whitespace significant you can use tools to pack your dependencies into a single file, so every script/app is dependency-free. This also works with C libraries, you can compile a Perl script and the C libraries it uses into a single binary. Also, there are some fantastic admin-free tools like perlbrew and cpanminus. Both of those tools are examples of my previous point, they can be installed with a single curl command. Therefore, no one should ever have to use "sudo" to do anything with Perl. From a developer's perspective, you can easily manage many versions of Perl with Perlbrew or plenv, and use them all to compile a script with a single command (though I use CI to do that for me). With cpanminus, I use a cpanfile (which is a dependency spec just like a gemfile for Ruby), so I can pin my installation to ensure one library version doesn't break the build. There other tools for managing dependencies also, like Carton and Stratopan, and those allow you to ensure that "version 0.07" always ships with the same libraries, not newer ones that the package manager decides to install.
I don't have a general solution for shipping core dependencies like graphics libraries, I wish there was one. You would think that people who use these in industry have clever methods for updating and deploying these tools rapidly (maybe Docker, as you said).