current community

your communities

more stack exchange communities

company blog
Stack Exchange Inbox Reputation and Badges
tour help
Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle who care about creating, delivering, and maintaining software responsibly. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top
up vote 0 down vote favorite

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.

share|improve this question
1  
What's the problem with seeing your in-house customers as ordinary customers? – Thomas Kilian 1 hour ago
    
@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 1 hour ago
    
teamcity for build, octopus for deploy. none of those pesky scripts – Ewan 1 hour ago
up vote 1 down vote

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.

share|improve this answer
    
I don't like scripts myself, but it is a standard approach and keeps you deployment product agnostic – Ewan 1 hour ago
    
@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 23 mins ago

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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