4

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?

  • 2
    I would have thought it was obvious, but you need virtual machine images. This is how the problem is typically solved in an absolutely reproducible way. The other solutions are good as well, just less deterministic. – Frank Hileman Mar 8 '18 at 19:08
  • 2
    @FrankHileman: For development? I hope not. – Robert Harvey Mar 8 '18 at 20:08
  • @RobertHarvey Can't say I like it either. But it works. Consultants who work for multiple clients simultaneously often use virtual machines to keep projects from contaminating one another. – Frank Hileman Mar 9 '18 at 22:15
  • @FrankHileman Yes, that's how we solved the problem of Linux development in a corporate environment that insisted on Windows Desktops. It also meant all the developers could keep synced with all libraries etc a little more easily than other options. The corporate environment also severely limited access to other machines, network access outside our local network etc. etc. – Peter K. Mar 12 '18 at 21:45
4
  • 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
3

"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.

  • Thanks for this great advice! I really appreciate it. To be honest - I hoped for some sort of a tool which does all of these things for me. We're already using testing, CI/CD (sort of), but it seems like we have to pay way more attention to this - even if it is very time-consuming. Thank you! :) – jdstaerk Mar 8 '18 at 13:55
  • 1
    It's time consuming while you're putting it all in place - once it's there and it's just "what you do" normally then you won't even notice it. – Phill W. Mar 8 '18 at 16:27
1

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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