Have you considered using Shared Data Sources for your reports if you aren't using these already?
That way you define the Data Source(s) once for each environment, then when deploying the reports to different environments as long as the Data Sources are always named the same and in the same relative location to the report you shouldn't need to worry about updating connection strings each time.
There are a few challenges that can be solved in different ways (e.g. uploading a new report through Report Manager invalidates the existing Data Source reference), but this is a pretty standard and scalable approach.
Added after comment:
Thanks for the update.
Given you have one instance with multiple deployments, Expression-based connection strings aren't a bad option.
The only issue is that you need some way of choosing the Data Source, such as a parameter. If you're happy to have user's choose this (or through any other mechanism you can think of) this would be a good option.
In terms of security, this would be no different than any other static Data Source; you choose whatever credentials you like, e.g. Windows Authentication, stored credentials... These are treated exactly the same so there's no extra consideration here.
One other option you might consider is deploying your reports through the rs Utility. You could parameterise a deployment script to deploy all the reports to one of a number of folders on the server, and point the reports to one of a number of Data Sources on the server.
Once you have the script working you could even wrap this in one batch file for each of your environments and deploy and configure your reports just by running the batch file.
Summary
If possible, I'd still go for separate instances and control deployments through BIDS and build configurations (Develop, Release, etc) which have different instance targets. If you have some SQL Server Development licences this could be an option.
Failing that, either of the other options should work, too - expression-based connection strings move the complexity into the report and/or the calling application or keeping it out of the reports and putting some effort now into some deployment scripts that should make deploying reports through fairly robust batch files.