We are currently building applications that will run in house and not be rolled out to any customers. We are the only customer.

We are using c# and the latest .Net platform. We are also using Team Foundation Server with a git repository.

I am looking for information on build and deployment strategies. I am finding it hard to locate information for our particular situation. Most of the articles I find are geared towards development of software solutions that either are deployed to mobile devices or to a bunch of customers.

Because we will only have one installation and we are the only customer we want to keep things as simple as possible while using best practices and automation.

Does anyone know of good strategies for build, deployment, continuous improvement / integration for our particular situation? Also interested in modern environment strategies, such as development, test, staging, live and disaster recovery.

Any insight is much appreciated.

  • 2
    What's the problem with seeing your in-house customers as ordinary customers?
    – user188153
    Commented Nov 22, 2016 at 14:17
  • @ThomasKilian: it is not "a problem", but when you have only one customer, you can handle some things much more efficient than when you try to support different customers, especially when don't know them yet.
    – Doc Brown
    Commented Nov 22, 2016 at 14:25
  • teamcity for build, octopus for deploy. none of those pesky scripts
    – Ewan
    Commented Nov 22, 2016 at 14:28

1 Answer 1


I was exactly in your shoes, and developed a simple solution which works at least for our company (but your mileage will vary).

The most important thing is automation by scripting. We have standardized build scripts for every application, which will run Visual Studio with the correct parameters and copy exactly the needed files for a deployment to a "Deploy" folder.

Then, we have standardized deploy scripts to copy the content of the deploy folder to a dedicated network share. If that network share is located directly in your production environment, your test environment or if it is a folder from where your admins grab the files and install them for you is up to you and the way your organization works.

Of course, there are other models possible, where you require the source code first to be checked in into your VCS, then tag it, grab the tagged version from there to build and test it and then deploy. But all of these steps are scriptable.

Creating scripts, especially the ones for deployment, is very lightweight and to my experience much easier than creating a full-fledged installer. But it works only that way when you have a more or less standardized destination environment. That is often easy to fulfill in inhouse development, but seldom when you have different customers, not knowing their exact IT environment beforehand.

  • I don't like scripts myself, but it is a standard approach and keeps you deployment product agnostic
    – Ewan
    Commented Nov 22, 2016 at 14:31
  • @Ewan: sure, scripting needs some people which have special scripting knowledge. And you need to invest a little effort to get a robust solution. On the other hand, it is very flexible. So far I did not find any tedious, repetitive task I could not put into a script.
    – Doc Brown
    Commented Nov 22, 2016 at 15:40

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.