Same dev env setup across multiple machines - aka fixing “but it worked on my machine”

Question

Community,

as our software and development team grows, we ran into multiple problems:

• Multiple Config files with different paths for each machine
• "Do I need this tool? And what version, I don't have this yet" - "I use it with version x.x"
• "Why does this work on my local machine but not on the prod server?"
• "Which Visual Studio version do you use? Have you installed xy?"
• "what Database sorting-order do you use? Maybe that's the reason."
• ... and the list goes on ...

So we need a setup where each machine is "the same". We're developing an ASP.NET application with an SQL Server Database. We've heard about tools like Docker or Vagrant, but haven't found a setup that fits all of our needs.

So what are your ideas about this (probably common) problem?

Answer 1

• Use relative paths
• Script the installation of tools (use specific versions)
• Use a package manager (eg, NuGet) to ensure everyone uses the same libraries
• If you go down the Docker route, have local development deploy to local containers. This will more closely resemble production environments.
• Don't rely on the order in which DB records are returned unless it's explicitly stated.

But, I guess the more valuable general advice is:

• Script the setup of your development environment
• Anything that can't be scripted should be clearly documented

Answer 2

"You've just taken your first step into a larger Universe".

It's not all about Development and Developing (even if that is the "fun" part). Now you're starting to think about what comes next:

• Deployment - the [automated] [standardised] process[es] by which you move code from machine to machine.
• Testing - [Automated] testing (off of your own dev box) is your biggest "safety net" to catch many of these problems.
• Protecting the Production environment (from yourselves) - the applications that are running in Live are making you money. You changing them [repeatedly] is costing you money. Find the balance.
• Maintenance - sadly, a dirty word to too many Developers but a program only gets written once; it will be changed many times.

More specifically:

Multiple Config files ... ... this tool? And what version ... Which Visual Studio version do you use?

Standardise.

Sure, it's limiting and, possibly, frustrating when you can't "just" download the latest and greatest widget to work with but it makes for a more cohesive working environment and greatly reduces the kind of "missing dependency" problem you describe.
On the flip side, though, beware being falling too far behind on the "Hamster Wheel of Upgrades". That way lies obsolete technologies that you're over-invested in and with no-one around to look after them.

"Why does this work on my local machine but not on the prod server?"

Because it wasn't deployed to and tested on a staging server that's set up the same as Production and that nobody's allowed to "fiddle" with.

"what Database sorting-order do you use? Maybe that's the reason."

Always request the data in the order that you want it with every query. Most RDBMSs these days do not guarantee row ordering any other way.

As your data requirements grow, you may need to train up / bring in somebody to take an "overview" of your data and how you manage it, agreeing and laying down some ground rules.

Answer 3

So we need a setup where each machine is "the same"

No you don't. You need a build server and a dev/test environment.

Get Team City and have it build every check in to the develop branch. If the build fails roll back the commit and fix the problem.

Get Octopus and have it deploy successful builds to the test server. run your tests on the test server. If they fail the job isn't done.

Put your database into source control, version, build and deploy it the same as source code.

Once you have these steps in place its in the interest of every dev to make sure that whatever they do with their machine the code they produce works when its deployed to a 'real' server.

Dev's sometimes need to have different things on their machines. That's how you add new stuff without breaking it for everyone else. Trying to make everyone use the same tool set is just asking for trouble.