As a SET working on multiple projects I see every day the difference between an hackable project with a 1-second test feedback loop and projects with bad isolation needing so many external resources to run they can't be reliably tested locally but only on a dedicated set of VMs.I guess the industry has taken a turn to outsourcing key services such as databases or distributed filesystems in this way, but without the necessary testing infrastructure to keep the projects hackable. While Google has the scale to make a commit queue a reality this situation bites hard cloud-enthusiasts who do not take the time to provision testing environments and stub dependencies.
Right. It's not necessarily a bad situation when you can't run a test on your workstation, as long as it's easy and fast to run in the magical environment somewhere else. For instance, if you run something in a terminal and get the results right away it's not a big deal if another machine is actually invoked behind the scenes. If you have to ssh somewhere, reset machine state and then run by hand though, that's a terrible impediment to hackability. Similarly it's a problem if you don't have enough devices for all developers in the magical device pool. In that case your company is throwing money, engineer morale and competitiveness out the window in an effort to save money.I don't know much about test tools for cloud, but I did mention the Google Cloud debugging tools in the previous article: https://cloud.google.com/debugger/.You also mention not everyone has the resources to build a commit queue. This is certainly true, and it's overkill for many projects. Most projects are fine running the unit tests in presubmit (if they're fast enough, at least) and running on all shipping target platforms in postsubmit. You need something massive like the commit queue if you're doing hundreds of code changes a day.
The comments you read and contribute here belong only to the person who posted them. We reserve the right to remove off-topic comments.