I find that on many projects, the most psychologically draining part of the whole experience, other than the final sprint before the thing is completely finished is the first little bit of code to get started. It’s both simple and tempting to open a new project and just start slinging code, but it also frequently complicates things later on. Therefore, I’ve long since come to the conclusion that I should have a fairly standard way of approaching the setup of projects, both for myself and for external clients. I’m going to start writing a series showing how to implement the things you need to have a reasonably decent home development setup. I’m not going to cover what kind of desk or chair to get, as I’ve had the same desk for 14 years and pick chairs based largely on how comfortable they feel in the store with a reasonably similar desk. No, I’m go to get into the guts of how to get a working process together to develop software in your house with professional-grade discipline so that you can actually complete what you set out to do. I’ll be doing these piecemeal as I get a more regimented environment set up at my own house, so feel free to follow along and change anything that doesn’t suit your needs/desires.

Before we begin, however, I think it useful to go through a bit of requirements gathering. What do you want out of a home development environment to enable you to reach your goals? What, pray tell, are your goals? What sort of issues do you expect to come up during the process?

For myself, I think there are quite a few things I’m looking for that will make what I’m trying to do easier. Here’s my list (think about what yours are as you go through).

1. Internal source control – I want to manage my own code on my own server without paying a monthly fee for now. I’m not overly fond of setups like github’s where I have to pay based on the number of repositories I have. That tends to drive me towards not separating things that should be separated. For the initial run, I plan to use Bitbucket, although that may change as I go further along.
2. Internal nuget package management – I want to be able to build my own nuget packages and make them available for projects I’m working on within my internal network. I also have a fairly decent VPN, so there’s no particular problem with hosting this stuff internally. Nuget.org is frequently down and a custom nuget repository package will allow me to cache frequently used nuget packages so that an outage from them doesn’t stop me cold. I’ll also plan to deploy my nuget packages to a directory under my dropbox, as I’m sure I’m not the only one who has used that software package to keep packages in sync before either.
3. I want to be able to manage builds, automated tests, and deployments with a single click. I’ll be using a combination of MSBuild and good old batch scripts for the first round of this, as they work and there is lots of documentation.
4. I want to have nice resharper scripts and templates to kick out some of the oddball and nasty files quickly (looking at you, MSbuild) without having to go find a another copy and replace bits and pieces.
5. I want to have infrastructure for quickly standing up a windows service (and building deployment assets for it). I’ll do this using TopShelf along with some MSBuild additions.
6. I want to have a decent, working message queue infrastructure. Because of the nature of one of the projects I’m building, this will be an early requirement. Thankfully this isn’t that difficult to build on top of the previous service infrastructure.
7. I want a service for scheduled tasks to let me easily schedule things without messing with the windows task scheduler. This is pretty easy with Quartz.net, thankfully.
8. I want to be able to stand up websites as well, with the same quality of deployment options as everything else.
9. I want effective and consistent error logging and tracing across libraries and projects.
10. I want to be able to test and build the full set of my company’s application code for verification purposes before I roll out a build (sort of a light continuous integration).
11. I want this system to be primarily geared towards supporting multiple in-house applications, but I want the project libraries (or at least a subset of them) to be usable in client projects that I’m building on a consulting basis. This means additional version control issues, as I will likely want to decouple updates made for clients from updates made for my own purposes.
12. I want all this stuff to happen without being a huge configuration nightmare that takes my eyes off of what I really want to get done (which is building an application to bring in revenue, along with managing a couple of websites). This is why I’m avoiding git for the early stages – on occasion I’ve had some rather nasty configuration issues with it that have caused me to lose hours I didn’t have.
13. I’m sure I’ll have more than the above 12 items by the time I’m done.
    I’ll be building this article series as I go, so it won’t all be together. I’ll probably try to make a page on the website with all the episodes on it, however.