Well first things first, you really need to be telling the client that they need to get off SQL 2008 and like 2 years ago, so you really need to be pushing them for an upgrade and sharpish.
2008 is now end of extended (CVE patches) only and 2012/2014/2016 are only in extended support, so depending if your client has to adhere to certain regulations they are at serious breach of contract and should be running 2017 or 2019 with a push to be on 2019 as best they can.
Debugging has been removed from SSMS for a number of versions now, so I would highly advise against using it on older servers if Microsoft have removed it, there must be a serious reason right?
Debugging is an art form and to do it right you need to explore what the issue is first. You have not eluded to what it is you need to debug or what the issues are.
As for how do you configure it for dev/test/debug, well they should really all be separate servers, there should be environmental separation wherever possible. After that it is up to the application to work out if a database is dev/test/debug/prod based off of the connection strings and any configuration tables within the database to make it a dev/test/debug/prod version of the database, that is entirely application dependent and nothing that can be shared on a forum who have no information about the app, its background etc, you need to get that "domain knowledge" from your client.