My team is in a situation where we need to create about 30 different processors. By processors I mean code that takes data from a DB and sends it to a remote service somewhere else in the world. They each do fundamentally the same thing, only with different data.

Only some of these processors will be deployed to server A, some to server B, and so on. And they won't all version at the same time. If we make a change to processor X, we would version and ship X while leaving the rest of the processors alone.

We've come up with three possible options, each of which have their own issues:

  1. Have 30 different solutions
  2. Have one solution with 30 different projects
  3. Have one solution, with one project, with each processor functionality separated by namespace

The main con of #1 is having to create and maintain 30 different solutions. And if we have to make a change to many processors at once, we'll need to open n solutions to do so.

The main con with #2 is versioning. If we branch the code, we branch the whole thing, even if only one project changed.

The main con with #3 is the same as #2. And then we also need to find a way to exclude certain processors from certain servers for deployment. #3 is the easiest to manage during development, but the most difficult during deployment.

Is one of these the best option, or is there something else I haven't considered?

  • Are any of the "processors" dependent on eachother? – Oren Hizkiya Mar 26 '14 at 13:33
  • No, they are not dependent on each other. – Bob Horn Mar 26 '14 at 13:35

I would advise to think carefully about the different phases of release. For example, usually as a release is created it is built, tested, packaged and then deployed.

Just because a solution builds together, doesn't mean it needs to be packaged together. And likewise, just because you have a single package, doesn't mean you need to deploy everything in the package.

Thinking in this way will give you flexibility where and when you need it.

I think either Option #1 or Option #2 could work. I don't think I would go with Option #3 because you don't have the option to package and deploy separately (So, configuration management would hold all of the complexity).

Option #1:

With this option, you give yourself ultimate flexibility. Advantages are that different development teams can happily work independently (because the code is physically separate). As you have suggested, the DRY principle suffers. However, you can mitigate this by encapsulating common components in NuGet packages and then pulling them into your separate solutions. This also gives the advantage of being about to version your common components.

This option also gives the option of having completely different packaging and deployment processes. Again, you can have a standard script or process for each, but they are separate physical files. This is advantageous if some of the processors will develop at different speeds, or have different complexity, or are development by different teams of people.

But the downside, as you have observed, is that you have separate solutions and have to manage and maintain them.

Option #2:

With this option, usually you would build the solution together. You can keep common components in the solution (as different projects) and reference them. However, versioning the common components between the processor projects is more difficult.

This option is slightly more difficult with different development teams because there is likely more merging as one team (or dev) makes changes to common components. Adding more processor projects (at the same time) also give rise to merge issues.

Even if you build together, you can have different packaging routines for each of the processors. So, you can separate out the dependencies of each and package the deployment separately.

In summary, it depends on many factors on your project. Things like rate of change, team size, code dependencies, and complexity of each processor make a difference. I'm not sure If I've given a clear answer one way or the other, but hopefully this will help in your decision.


One product, one source code, different data.

There are not really enough details to know whether my answer is the right one, but your problem is a common one for solution providers with multiple customers who have slightly different requirements. The answers always some to converge on: Just One Product.

When you build, you build everything and when you run tests, you run all tests. That way one team doesn't silently break something for someone else and everything works all the time.

When you release, you release everything. You run short cycles and you only ship what needs to be shipped, but everything is there all the time for testing.

You may ship code for platform A that is not used on platform B, and you need configuration data to switch things on and off. Depending on your needs, you may converge on a solution that is largely data driven with little or no custom code. Or you might use a Domain Specific Language, or a scripting language to encapsulate differences.

This is a very good answer to a lot of questions. Perhaps it is the answer to yours.

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.