Software development is full of decisions, some classic ones:
- Which logging framework should we use?
- Which IoC container should we use?
- Which packaging tool should we use?
- Which database deployment tool should we use?
- Which navigation framework should we use?
With all of these there are multiple choices that we could make, but there tend to be a few categories that they fall into:
- The default choice.
- The popular choice.
- The weird choice.
Notice that there is no right or wrong choice in that list, there are just choices. By definition the default and weird choice aren’t as popular as the popular choice, although they probably both have some level of support from someone in the team.
The challenge is – which choice should you make? Well, you really need to evaluate it against a set of criteria:
- Is the choice going to work us now?
- Is the choice going to work for us later?
But I want to step back a little bit and look at the Default Choice again. For example, in the case of database deployments, the default choice for me on the .NET platform is to try to use vsdbcmd.exe. I get a bit of push back about that because people don’t trust what it is doing, but what other choices are there?
- The popular choice: change scripts, manually applied to the database.
- The weird choice: build our own database deployment tool.
I usually here the popular choice coming from DBA’s, and I usually hear the weird choice coming from the software development team members. But both stem from a lack of trust in what Microsoft has developed with DBPro. I get that, I’ve seen some of the issues myself, but overall it does work.
To me, for a .NET development team targeting a SQL server database backend, vsdbcmd.exe is actually the default choice and you need a really good reason not to use it. The popular choice is my second favourite because it is often a reality when you are dealing with customer DBAs, but I don’t think the weird choice (the re-invent the wheel choice) is the way to go because you aren’t going to be able to build a tool powerful enough in the time you have available.