A continual sticking point for my team has been our “Common” library. (Looking at related questions here, it might be more correct to say “Framework”).
This currently consists of v1, v2, and v3. Where v3 is used for all new apps. It contains multiple WCF services, a class library with business objects, and a common web directory for js/css/images.
We want to do things right as we go forward, especially since we have all actively begun contributing to the common library. It’s turning into a big ball of mud, and deploying it is frightening for everyone.
Our first thoughts are to set up a test server that runs unit tests across all the code to make sure nothing breaks. The problem is that writing tests for everything is extremely tedious, and frankly no one has that kind of time. We are also all inexperienced with writing proper unit tests. With that said, we’ll get it done if that’s the best route to go.
After that, we’re not too sure. We see the common code as a place to apply continuous integration practices, since there are many varied applications we write that utilize it.
This also introduces questions such as copying DLLs local, or having everything on one server somewhere. We are already feeling like we’re in DLL Hell, and want to get out.
What are strategies that (good) software shops use to manage a situation like this?
Any and all advice is appreciated. If more information is needed, just ask. I’ll be happy to provide it.
Thanks!
The real problem is that you wrote your code without a TDD approach (tests should be written first), now in a project where testing is the focus (it should happen in every project) the tests usually take more time or the same time to write that writing the real code. Why? Because when following a TDD when you are writing your tests you are actually designing your code and you follow this pattern red-green-refactor
You should definitely start writing tests for your code, the problem now (and I am daring to take this assumption) is that you and your team did not write testable-code.
Check this thread https://stackoverflow.com/a/10365073/1268570
Assuming not all of your code was written to be testable, create unit-tests will be a real pain, you could write however some kind of integration tests.
About the CI server, you should go and implement it, actually a CI should not be optional for every serious project
I am actually creating a tool to simplify the integration with CI servers, it consist of a set of MSBuild scripts wrapping third party tools to perform common tasks that every project should follow, I have not released yet cos I am not done writing documentation but it is functional now you could take a look at:
https://github.com/jupaol/NCastor/tree/develop
Check the develop branch, since I won’t merge to master until I release a new version
About versioning, to leave “dll hell” as you say, that makes me think that you do not have a versioning standard, I would recommend you to check the Semantic Versioning model:
http://semver.org/
BTW a good strategy I have found to distribute new component versions internally in an organization is to setup a private Nuget server, and publish to that server Nuget packages of your components. Of course to make this happen, you need to package your components as Nugets, but that’s really easy to do.
Take this article as a reference and put all your efforts in:
Use a TDD approach writing unit-tests
Write clean testable code
Implement a CI server
http://misko.hevery.com/2008/07/16/top-10-things-i-do-on-every-project/
Tools I would recommend you to use when writing tests:
AutoFixture
Moq
FluentAssertions