I've been in this position lots of times, having to context switch from the refactored 2.0 code base I'm working on back to the 1.1 code base that is due to be released. The context switch is expensive, but the process of setting up my development environment to recreate the 1.1 UAT environment is even more costly.

The release process may create a versioned MSI, but typically you can't just run that in your development environment. The installer may be packaged with the configuration for a specific environment. It may have been compiled in release mode and packaged without PDB files, so there's no option to attach a debugger, and it may have prerequisites that I don't have available in development, such as certificates or encryption keys or additional software components.

Instead, I need to recompile the 1.1 version from source. Hopefully, the release process has enough information for me to find the exact source code that was used to build the release, take a branch, and clone it locally (maybe the Git commit ID or the TFS change set is recorded in the built assemblies). Then, the real problems start when I try to recreate another environment on my local development box.

The workflow looks a little like this, where there are lots of differences between my setup and the 1.1 environment:

• Compile the source locally. I'll build the app in Visual Studio, but the released version uses MSBuild scripts, which do a lot of extra things.
• Run the app locally. I'll be using IIS Express on Windows 10, but the release uses an MSI that deploys to IIS 8 on Windows Server 2012.
• My local SQL Server database is set up for the 2.0 schema I'm working on. The release has upgrade scripts from 1.0 to 1.1, but there are no downgrade scripts from 2.0 to 1.1, so I need to manually fix the local schema.
• I have stubs for any dependencies I can't run locally, such as third-party APIs. The release uses real application components.

Even if I can get the exact source code for version 1.1, my development environment is hugely divergent from the UAT environment. This is the best I can do, and it may take several hours of effort. To reduce this time, I could take shortcuts, such as using my knowledge of the app to run version 1.1 against the 2.0 database schema, but taking shortcuts means my local environment is even less like the target environment.

I can run the app in debug mode at this point and try to replicate the issue. If the bug is caused by a data problem or an environmental problem in UAT, then I won't be able to replicate it and it could have taken a whole day of effort to find that out. If I suspect that the issue is to do with the setup of UAT, I can't verify that in my environment; I need to work with the Ops team to look at the UAT configuration.

But hopefully I can reproduce the issue by following the steps in the bug report. When I have the manual steps worked out, I can write a failing test that replicates the issue and be confident that I've fixed the problem when I change the code and the test runs green. There are differences between my environment and UAT, so it could be that my analysis is not correct and the fix won't fix UAT, but I won't find that out until the next release.

How that fix gets released into the UAT environment is another problem. Ideally, the full CI and packaging process is already set up for the 1.1 branch, so I just push my changes and a new MSI comes out that is ready to be deployed. In the worst case, the CI runs only from the master branch, so I need to set up a new job on the fix branch and try to configure that job to be the same as it was for the last 1.1 release.

If any part of the toolchain has moved on between 1.1 and 2.0, then it makes every step of the process more difficult, from configuring the local environment, running the app, analyzing the problem, and pushing the fix.