So we have 3 branches that match our environments for all our projects (Dev, Test, Main). We have a dev server, test server, then production server and when we commit to each branch a build and deploy is initiated to their respective servers. When we have a new feature we make feature branches from Main.

We have a web site that uses multiple web api's that are each separate projects. However in order to debug the web site locally we bring those web api's into the web site solution and have them all start up before the site itself. The problem comes to when it's time to merge. Since our feature branch points to the dev web api's merging from feature to dev is no issue but merging from dev to test we would obviously not want the dev branch of the api's to merge and then from test to main again, we wouldn't want the dev or test branch of the api's to merge.

We thought about not merging the solution file as that holds the information of what projects to include but there may be other valid changes to the solution file that we do want merged.

What would be a solution to this problem? In general how do others handle a website needing separate web api's to run correctly in their local environment when coding? Do you just have the devs know what API's are needed and have them open those projects separately if they want to run the entire web site locally and that way the web site solution file doesn't need to have the project in it? That seems like if you have a lot of web api's it could get complicated and messy to have to know which ones to open and have how many visual studio instances open as well. This web site is kind of a dashboard of a lot of different functionality which is why the api's are separate projects as they are used in many different front ends (multiple web sites & mobile apps).

Any thoughts would be appreciated.

  • do you have a repo per project/solution?
    – Ewan
    Commented Jul 9, 2018 at 15:44
  • "but merging from dev to test we would obviously not want the dev branch of the api's to merge " why not?
    – Ewan
    Commented Jul 9, 2018 at 15:45

1 Answer 1


When running locally point your api endpoints at the dev environment. Don't run local copies of all the apis and don't have more than one executable in a solution.

Also, don't have a branch per environment. Do a versioned build on the build server and deploy that to dev -> test -> live

  • This for sure is an option but I do find it valuable to be able to step into the API calls from the website, but I guess doing what you said is probably cleaner for the other stuff. Thanks for your input.
    – user441521
    Commented Jul 9, 2018 at 15:54
  • you can still run a second VS window with an API locally if you are particularly interested in one of them
    – Ewan
    Commented Jul 9, 2018 at 15:55
  • Yeah, I'd just have to change the api call to point to localhost vs dev env then I guess. We looked around for different branch/environment strategies and this branch per environment is something we settled on but it's newer and we're testing it out. So far it's been working well but we are open to other ideas. Could you list benefits you see with your branch/env strategy vs the branch per env strategy just we can discuss locally.
    – user441521
    Commented Jul 9, 2018 at 16:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.