7

My company is looking to implement a CI solution pretty soon, and I am worried about one thing in particular... we are scaling up, which means our solutions are growing with more projects. One thing I wanted to look into is to split off rarely changed projects into a separate project, and then having other projects simply reference the compiled DLL, rather than including the projects in their solutions.

For example...

  • /BLL/DataFramework
  • /BLL/OrmFramework
  • /BLL/OrmDataAdapter
  • /BLL/...
  • /WebUI/MyWebSite

The Data and ORM projects would rarely be changed, but if not referenced as DLLs would add bloat to all solutions.

Instead I'd like to exclude them from the project and have them build to a Libraries folder (or something similar), so that:

  • /BLL/...
  • /Libraries
  • /WebUI/MyWebsite

Where the ORM and Data assemblies .DLLs are in the Libraries folder.

So the question is...

Is there any reason this would not work with Continuous Integration?

Could I have one solution with these rarely updated classes that will build to the library folder during CI, first, and followed by the other solutions?

Edit: To be clear... we want to keep these projects in the CI cycle, but to not directly reference their projects in every solution.

Improve this question

4 Answers 4

Reset to default
2

This would work. I do something similar in that we treat those rarely changed projects as Core Framework/Architecture dlls and they exist in their own solution. The dlls are published to a reference location and the other solutions reference these dlls in this location as required.

Although rare sometimes a bug is found or an new requirement is identified then a change is scheduled for these Framework/Architecture projects and they are built, unit tested and integration tested against those projects that use them.

Once testing has been completed they are released to the reference location and other projects pick them up on their next build.

All of the non Framework/Architecture projects are on a CI cycle and we have never had an issue with this approach.

Another advantage of this approach is that you have a single code base for these Framework/Architecture projects making it easy to control access if you have some IP and also to ensure that all versions of the application that need them are running on the same version.

Improve this answer
2
  • We would like to have these "Core dlls" in CI as well, to assure any changes to them (however uncommon) do not break other projects unexpectedly. It sounds like they are kept out of CI in your case?
    – smdrager
    Apr 17, 2012 at 20:38
  • If there is a change to these "Core Dlls" they are tested outside of the CI and once tested the Dlls are release and its these Dlls that are referenced in the CI projects. We found the CI'ing the changes to the "Core Dlls" had the potential to have unexpected side effects i.e. broke things! Just as you wouldn't take every Service Pack from MS without testing we wouldn't release a "Core Dll" without testing. In our case some of the Core Dlls haven't changed in over 2 years.
    – armitage
    Apr 17, 2012 at 21:47
1

There is no reason using referenced .NET assemblies would not work. As long as you properly include the referenced .NET assemblies in your source control system, your continuous integration server should have no problem using them to build your Visual Studio solutions and underlying projects.

Improve this answer
0

Yes, this will work.

But do you really want your repositories filled up with assemblies, which are a lot bigger than the source files? Why not just build them? As long as you don't use Rebuild or change any of the source files, it will be relatively quick as the compiler will figure out that nothing has changed since your last build.

If you're using VS10 or VS11, there's a further option to build those libraries into NuGet packages and deploy those into a local repository, allowing you full control over versioning. This is the best of all worlds.

Improve this answer
8
  • Unfortunately, things aren't as pink. VS slows down considerably when you add lots of projects. Even the latest version, with the latest service pack. You even get happy random freezes when you move the cursor in the editor.
    – Yam Marcovic
    Apr 17, 2012 at 20:35
  • @YamMarcovic: I have seen this effect, but not so much with the latest version (unless you have Resharper installed on a less-than-optimum machine). But, if you are suffering from this problem, you can still leave them in separate solutions and build them as part of the CI build.
    – pdr
    Apr 17, 2012 at 20:38
  • Part is build time, part is VS responsiveness, part is simply keeping the solutions simple. Why keep projects you edit once every few months in a solution you work on every day?
    – smdrager
    Apr 17, 2012 at 20:42
  • With the latest version installed (latest as in non-beta - so VS10), on a 24-core machine with 16GB of RAM - still happens. :) Just thought I'd mention..
    – Yam Marcovic
    Apr 17, 2012 at 20:42
  • @smdrager: Again, you don't have to only build one solution in CI. And, if you want to go down that road, look into NuGet. You won't be sorry.
    – pdr
    Apr 17, 2012 at 20:44
0

It would work, and it does work (where I work :) ).

Using build servers like Jenkins/Hudson or other similar software, it is possible to set up build triggers for jobs (e.g. other builds).

You can set it up such that any change to project X triggers a build for X as well as builds for Y, Z, ...

For more information, you can go to Jenkin's homepage.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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