Ok, when hired on to my current company a year ago, I was tasked with migrating our development teams from VSS. They already had it in their minds that they wanted Subversion, and since I had experience using and setting up subversion, I was a good candidate. I first tried to sell TFS because it woul dhave solved the problem I am in right now, but since money is tight, and Subversion is free... well you get it. Anyway, I have finalized the propsal and the only thing standing in the way is the following.
I proposed that we store only our source code in SVN, and all documentation, release builds, and other project artifracts be stored in our SharePoint portal, so we don't have to give non developer stakeholders access to SVN. When I presented the proposal, all was excepted but the question arose about how to manage the syncronization between the artifacts (Ex: How to is document x version 3.1.2 associated with release 4.5.2). My initial reaction is to create a section in the SharePoint porject page for each new release that will hold the artificats (and keep track of changes too). Is there a better way of doing this? Does anyone know of anyone doing this? Or any integration packages to sync SVN with SharePoint?
Here is some info on the companies development environment. All of our software is for internal use, we sell none of it, so our customers are all in-house. We have 2 types of developers: 1. those who take care of maintainance and customization of third party software, and 2. those who write proprieatry software (which is where I fall). Our software we write is mostly .NET, but the 3rd party software is all over the board (COBAL, C, FORTRAN, Other crap that no ones cares about anymore).
Please advise, as I need to get this submitted soon. I HATE VSS!!!!!!!!!! and I need relief!
What we do internally is putting all docs under our version control system, I think it's much easier. Then, of course, you have to give access to not-developers.
In your case, using SVN, why don't you put everything inside and then use the webinterface to give access to the stakeholders? It's easy enough for them :-P
I would use SVN for both documents and source code.
Advantages:
You can synchronize versions of
documents with versions of source
code.
You have everything in one place, so
no two repositories to administrate.
Disadvantages:
You'd probably need to manage the
access rights for some stakeholders
to some parts of the folder
structures.
SVN is not the most appropriate tool
for document management
In order to solve the possible concurrent changes to the same document, you can use SVN property svn:needs-lock for these items, to make them editable by one person, who locks the item.
As pablo said, you can access the documents (at least for reading them) through the web interface.
You could expose the svn repo via the web interface and link to that in sharepoint. That way people who need to edit the documents would need access to subversion but anyone could easily access the documents "read only".
In our organization, we have docs/artifacts, code everything in SVN and have given access to non-technical stakeholders as well who use tortoise client.
however you can look at the following option
Option 1 : create a ASP.Net interface for non-technical users
You can build a simple web interface in ASP.net, configure that with a single user so you would not have to create separate users for all the nontechnical stakeholders and they would get access to the docs with proper version control, etc. you could look at sharpsvn for the implementation aspect. the disadvantage of this approach would be that you might have to invest some time in developing this app
Option 2 : ofcourse, create separate users for each non-developer stakeholder
This answer is probably too late for you implementation, but the simplest integration path may be to store the docs in SVN and then publish to Sharepoint with an svn-hook.
Build artifacts could be programatically published the same way from you build scripts.
You can upload docs to SharePoint using a simple POST
i.e.
http://blogs.msdn.com/rohitpuri/archive/2007/04/10/upload-download-file-to-from-wss-document-library-using-dav.aspx
Probably a little late, too, but I would avoid putting the documents in SVN if you have a SharePoint system setup. Though SVN does a fantastic job for source code, for document management it doesn't provide the ease-of-use of SharePoint. If you have it already setup and you are a primarily MS based network, SharePoint makes a lot of sense and can handle revision control for the MS based documentation much better than SVN.
Yes, you can manage access to SVN documents with a needs-lock, but chances are at some point you'll have a non-developer needing to access the documents. Explaining SVN to a non-developer, non-techie is not an easy thing.
Related
I may be working with Siebel CRM soon, and I'm looking for advice on using modern development practices and enterprise best practices.
Specifically I'd like advice on the following areas:
How should we set up version control (specifically with Subversion)? What kind of structure should our repository have? How should we handle branches and tags?
How can we do code reviews? How can we peer review configuration changes made through Siebel Tools that don't necessarily have any "code"? We want to review these changes for quality assurance and knowledge transfer, as well as compliance with change management policies.
What sort of change management works well with Siebel? How do we verify that only things listed in our change log are actually changed when we do a new deploy?
How can we automate testing of our application? Is unit testing even possible with Siebel? I saw another question suggesting QTP for web testing, but are there other options that work?
Are there other things we can do to implement Continuous Integration practices with our Siebel development efforts?
What recommendations do you have for naming conventions and other things that would traditionally fall under "coding style" guidelines?
How should we separate development roles from Siebel Administrator roles? What should our build/test/deploy cycle look like?
It's not likely that I'll be able to obtain any new expensive tools for this, but if there's a paid tool that provides really great ROI, feel free to mention it.
If you have other recommendations along these lines, but not specifically addressed by one of my questions, feel free to add that as well.
How should we set up version control (specifically with Subversion)?
use the guidance provided in the documentation for Siebel Tools. But please note that Siebel does not build from the files in SVN so it will only be useful as an archival tool; you cannot manage your code or build from SVN.
What kind of structure should our repository have? How should we handle branches and tags?
Siebel development code is not built or managed in SVN so this is a pretty useless thing to do. Just note the date that you built your SRF and exported your Repo and match with a tag or branch in SVN.
How can we do code reviews? How can we peer review configuration changes made through Siebel Tools that don't necessarily have any "code"? We want to review these changes for quality assurance and knowledge transfer, as well as compliance with change management policies.
Use Siebel Tools to do this. It has a built in 'checking' tool for obvious errors (all devs should be using this before they check in) and a diff tool (you will need to check against an older version of the same object - which you could drag out of SVN if you want). I normally automate the checking tool once a day and review the output logs, and automate build from the Siebel server 5 times a day and look for errors during the compile. Diffs via SVN and a standard diff tool might be possible, but the Siebel objects are stored as XML-like files in SVN and so are hard to read sometimes.
What sort of change management works well with Siebel? How do we verify that only things listed in our change log are actually changed when we do a new deploy?
?
How can we automate testing of our application? Is unit testing even possible with Siebel? I saw another question suggesting QTP for web testing, but are there other options that work?
QTP is the standard way to go - check on the Oracle web site for other vendors that they may recommend. You could also try Sikuli.
Are there other things we can do to implement Continuous Integration practices with our Siebel development efforts?
Not really.
What recommendations do you have for naming conventions and other things that would traditionally fall under "coding style" guidelines?
Checkout the appropriate section of Siebel Bookshelf for current naming guidelines and use these always.
How should we separate development roles from Siebel Administrator roles?
Not sure what you mean.
What should our build/test/deploy cycle look like?
Build a new SRF and export a new Repo from Dev once a night. Once all the dev work has been checked-in and unit tests are done take the next SRF and Repo and push into the test environment. At this point in normal software development you'd branch your SVN and continue to develop on the trunk but Siebel is different because you cannot build from SVN and you cannot easily restore a whole lot of files from SVN into your build environment, so you're best to make hot fixes for test either in dev (and pause mainline dev development until that is done) or in the test environment, and do ugly backports to the development environment (that's what most people do in fact). Build a new SRF and export a new Repo from Test once a night and once that's good, snap a copy for your Production release.
Try to stick to cycles of no more than 4 weeks (1 week for desing/prototyping. 1 week for dev, 1 week for test, 1 week for bug fixes and deployment) - any longer than that and the overhead of planning will become too great.
Hints for an easier life: Avoid eScript except in Business Services (otherwise it becomes unmanageable); use all the Siebel built-in tools instead of rolling-your own; try to avoid any roll-up functionality (it always seems like a good idea but it always destroys performance); keep the number of screens and views to an absolute minimum; do not build views when you should be building reports instead; always make sure that EIM tables match and schema extensions that you make - even if you don't use EIM right now; try to build Integration Objects to match your logical schema - they are always useful (for web services, XML publishing) and a hell of a job to build after the fact; prefer Workflow Policies over run-time Events; don't add new sort or search specifications without indexes - ever ever ever; don't make by-reference links to the LOV table; always patch; if the vendor doesn't say that you can do something, never do it.
We have set up a complete Continuous Integration toolchain for our Siebel systems consisting of Subversion, Hudson, Jira, Siebel ADM and some self-written stuff integrating everything.
This helepd a lot, although Siebel "source code" is not as suitable for standard CI approaches as, say, some Java-based project.
And, YES, it is possible to put your files - including SIF - into your Subversion repository and use this as source for your deployments.
I'm planning to blog about this in http://siebel-ci.blogspot.de/ - stay tuned.
SVN/CVS are not suitable for Siebel, a few reasons being
a) Siebel objects are db objects and SVN/CVS etc store sif equivalent of the changes.
These changes are impossible to query except for some basic queries.
b) The integration between Siebel tools and SVN is a loosely coupled integration.
The ideal integration should be with the Siebel repository and invidual tools.
Take a look at our tool Object Hive it addresses many of the short comings of a files based version control.
http://www.enterprisebeacon.com/siebel_version_control_tool.html
Object Hive has been from the ground up specifically for Siebel version control, some of its features are:
1) Object Based repository similar to Siebel repository that stores all version history.
This makes is very easy to query changes and conduct code reviews based on the changes
2) A browser based GUI that is similar to Siebel tools to query for version history (no combing sif files for changes).
3) Seamless integration - directly integrates with the Siebel repository.
No messy installation for invidual developer.
4) Powerful reporting (realtime and batch) to easily identify changes over any time period.
5) Oracle Exa-ready certified.
We have an application at work which is web-based and comes with a bundled web server (Apache tomcat), and is for network monitoring/patch management. It allows for personalisation, all sorts of rules, custom UI design using proprietary components and definition language, and even custom code to fire on events (based on Java).
I am in a team of several developers, each of who will be customising this app to meet various requirements. As it's a server app, not a codebase, what's the best way to setup a dev environment for >1 user?
If there is one single shared VM with this app, I don't know how good source control like TFS would work with this sort of system? I think also, developers working on various parts of the project may even need the same file at the same time (though TFS does do multiple check-outs).
What is the best way to develop against this sort of product? Bare in mind, even with personal VMs and an instance of the app, changes have to be merged to one central instance. Something keeps making me think about how app-virtualisation could help with this?
Thanks
If it is just an instance of Tomcat (even though it was bundled) couldn't you put the whole Tomcat directory and all of its subdirectories under source control? You just need to check in the non-binary parts, so exclude all the .jar, .exe, .tar.gz and .dll files when you check in. That's what I would do, unless I misunderstood your question.
I'm not familiar with the source control software that you mentioned. I have been using SVN (which is free) and TortoiseSVN as a client (also free). Just an option if your software can't support what I've suggested.
We are a small Microsoft shop with 4 developers. We like the idea to have everything integrated and under the same SQL database but not to deal with too many features or a complexity we don't need.
The other option would be to use two distinct third party tools. We also wonder if VS2010 version control and bug/issue tracking capabilities are comparable with the best third party tools on the market.
With TFS 2010, there is a TFS Basic version/configuration options. You can use SQL Server Express as the database, the install is simple and quick and you can install it on a client OS. It includes version system, work items and build system (no sharepoint, reporting...). Price should not be high, the target users for TFS Basic are those used to use SourceSafe. Also if you have MSDN, there is a change that it goes with it, so you would not have to pay extra.
Some thoughts on TFVC in general -- note that I've never used TFVC specifically, but I've been in a similar situation a couple times. My main concern is that it's too little.
TFVC (Team Foundation Version Control) appears to be a client-server version control system. I don't know anybody who hasn't upgraded to DVCS yet. I've never used TFVC but I can't imagine what benefits it'd offer to outweigh the architectural disadvantage. (And before you ask: I only use it from my workstation in the office, where the network has never gone down, but I still use its distributed features every day.)
I also work at a small Microsoft shop with 4 developers and we have never once regretted using Mercurial. It's one of the few decisions we made that everybody seems to have loved. It's one of those moves, like switching to a language with GC, that you never want to even think about reversing.
In terms of support, I hope you found some way to get great support from Microsoft. Things will come up with any VCS and it looks like community support is a couple orders of magnitude worse than Hg or Git.
I can't say much about bug trackers -- I think they're all pretty much the same these days. I've installed a couple open-source ones in an afternoon, even with no experience. The major difference seems to be, if you go with a big-name one, you'll be able to find lots of tools and extensions that work with it. For example, there are a million and one extensions for reporting/testing/etc. for Bugzilla. TFS probably has similar things, for enough money.
Two other things I'd keep in mind:
First, even if you only want these 2 features today, you will want other features in the future, and it will be (sooner or later) something Microsoft doesn't offer. So it's best to make peace with 3rd-party tools ASAP.
Second, unless you miraculously happen to pick the perfect set of tools for your company's future growth for all time, you will at some point want to migrate away from whatever solution you pick today. So make sure it either provides a way to do a full export, or is popular enough that other projects are falling over themselves to write importers for it.
I guess this all sounds kind of negative for TFS. I didn't really mean it that way -- I'm sure it does some things really well. But unless you're rolling in dough already, save your money.
Good luck with whatever you choose!
TFS work ittm tracking is awesome. Whatever your workflow is and the information you want to gather, you can do it easily with TFS.
Most expect TFS to do what they do out of the box as if it were omniscient. Unfortunately, you do things slightly differently than me and I from everyone else. The key is making it easy for the many different roles in your organization to get and input information into whatever your work tracking system is.
There is a plateau you will reach with custom, cobbled together tools that you won't get from cross referencing information along the product development process. TFS removes that barrier. The second barrier is knowing how to consume the information and that takes training and experience in effectively managing projects.
TFS Version control is certainly the low point when compared to the industry right now. DVCS popularity exploded about the time TFS came out. That said, Brian Harry has stated that TFS "fully expect that we will be adding distributed version control to TFS." http://blogs.msdn.com/bharry/archive/2010/01/27/codeplex-now-supports-mercurial.aspx
Take that as you will.
TFS is a great system but after having deployed and used it for some time I realize that the TCO is just too high to justify for a small team.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I am a student and I always develop projects on my own, mainly with Ruby On Rails.
I noticed that even a simple project may become complex if you can't easily rescue deleted code and pass from a version to another. Time Machine backups are not enough.
I would like to use a version control system, but they seem not to be intended for single-user projects. Am I wrong? If so, what policy and software do you use for managing your code?
There is nothing that says you can't use a standard version control system if you are a single user. Doing so would definitely keep you from experiencing some of the more painful problems such as merging files changed at the same time and other conflicts that arise from multiple developers.
Based on this, you could look into any of the version control systems (I believe Subversion is far and away the most popular right now) and pick out the one that will most closely match your needs, or has the interfaces you are most comfortable with.
Distributed version control systems are just for you: look for Bazaar, Git or Mercurial. They are lightweight, local commits are easy and you can always revert to a previous version. With a hosting provider such as GitHub, you can publish your projects, you get backup for free and you can easily share the projects with other potential contributors. Collaboration is easy because merging your changes is also a lightweight operation.
It is definitely a good idea to use version control software, and other project software on your own projects. These tools are not just for team working, although they allow team working. Beyond the obvious reasons for keeping track of your changes to the project it is a good idea to use SCM tools so you are familar with what the industry is using.
Subversion is widespread, and is quite a good bet as it's successfully replaced the earlier and older CVS tool. It relies on a central repository where the code is stored and can be backed up: where I have used SVN for personal projects and small team projects I have backed up to CD. If your project is opensource there are sites like sourceforge that support svn which you can use for hosting.
However as some of the other posters have indicated, a personal project might benefit more from a distributed system: git is increasing in popularity since git-hub has come online and porting efforts to are succeeding. http://git-scm.com/ It is likely that tools like these will grow in popularity over the coming years as they allow a greater number of people to participate on the same code. The idea of one central repository is relaxed giving each developer the ability to version track different designs and only give back to the community the versions they complete.
One of the benefits with using SCM for all projects personal or not, is that a separate server can be set up testing a version of the code. Automated testing on the latest version of the code (using a Continuous Integration Server or similar) can improve the quality of the software you are writing.
Some highly experienced software developers talk about a rhythm where they make incremental changes checking in frequently. Getting into the habit of making small changes which are complete and checking them in: is a good practice to get into for group working.
I would recommend Subversion. It's free and relatively simple, and learning a little about it may well beneficial in the future. It's cross platform and also available on a variety of hosted systems.
See also: https://stackoverflow.com/questions/250984/do-i-really-need-version-control
and: Using Version Control for Home Development?
Subversion!
You can install locally or use a hosted service. The services are nice if you want to switch between computers or use it as an offline backup. http://www.beanstalkapp.com/ has a free plan for personal use.
GitHub (git, not subversion) is also popular but I believe there is a small fee for personal projects.
Use git. It allows you to work without ever needing a server.
There are utilities for the command line and a GUI (older screenshots) too (for linux, windows and OS X).
If you later want to share or publish your project you can easily push it to a site like github.
Even for personal projects, if they become bigger than something you write a few hours, a version control system will be very beneficial.
Here are a few good points:
Many version control systems have good integration with IDEs.
Branching will allow you to experiment without the fear of having to take a long time to revert the changes. The branch can later be merged to the main trunk if needed.
Having a history of changes can be helpful, and tagging will allow setting milestones.
More efficient storage than full backups using regular copying of files.
Extra metadata (such as commit comments) can be attached.
Many version control systems are free!
I personally use a Subversion server running on my system which I access via the Subclipse plug-in in Eclipse, which I find to be very helpful in keeping track of my personal projects.
If you're interested in Subversion, Version Control with Subversion is a very helpful source in learning about the concepts, and how to set up and get started with Subversion.
Version control systems may be a little difficult at first, but it's definitely worth the effort to set up!
I'm very wary of using "always" in any answer I give on SO...
ALWAYS use version control. These days it's free AND easy to do. There's simply no reason ever not to use it. If it's an hour long project...good...it's an hour long project that's in version control now.
My solution has been slicehost(ok...not free), redmine(free RoR bug tracker)git and gitosis. Starting up a new project adds about five minutes on to the front of any coding, but its five minutes well worth it.
Use SVN or Mercurial.
Both very appropriate for "home" usage, I think Mercurial is better for you because by default you'll be creating one repository per project ( oposed to SVN's one "big" repository that stores everything ), so it will be easier to backup individual projects or exchange sources with others if needed.
Both work in command line mode or using explorer-like interfaces ( Tortoise ) or plugins available for the most usual IDE.
I use subversion to manage all my projects. xp-dev.com is a free subversion hosting solution. Also, I think, if you install tortisesvn it installs a subversion server to use locally.
A complete different version control system is dropbox (www.getdrobox.com). It's not (only) intended for source code. It available (with smart OS integration) for Mac, Win and Linux plus private Web Interface.
It may be interesting for you.
One item you will like about git such as using github hosting is that you have a history of changes that you can go to and get the actual code source and thus 'rescue' previous code changes.
You could also use the dropbox approach in just backing up raw code to a folder on the cloud..
I have used both methods for personal projects.
Hosted version control such as beanstalkapp.com is very convenient, but do consider whether you want to hand your source to a third party. You could consider a local repository, backed up online with a solution which encrypts the contents locally before uploading. I do this with subversion, Amazon S3 and JungleDisk.
Bitbucket is an absolute must consideration for personal projects based on:
Free, unlimited, private repositories
Up to 5 users on their free account
Git and Mercurial support
This allows one to quickly spin up a repository without having to pay attention to how many repos are available under a paid source code hosting account.
It also allows projects that will enter the public domain to be simply forked to GitHub, etc.
Version control is always important.
Try a free online SVN like http://beanstalkapp.com/
Do a search and you can find lots of suggestions
I would highly recommend downloading VisualSVN Server. It's a very simple setup and will do exactly what you need.
you can use any version control system that exists just for single user development. as you said, even simple project can become a nightmare if you change something you think is better and it fails. download tortoise snv - it's free and pretty simple to use - and keep your working versions in repository. commit code that works, keep possible small changes (for example refactor one class), build it, test it if it works -> commit, if it doesn't and you don't know why you can allways revert changes and try again.
My organization has begun slowly repurposing itself to a less product-oriented business model and more contract-oriented business model over the last year or two. During the past year, I was shifted into the new contracting business to help put out fires and fill orders. While the year as a whole was profitable (and therefore, by at least one measure, successful, we had a couple projects that really dinged our numbers for the year back around June.
I was talking with my manager before the Christmas holiday, and he mentioned that, while he doesn't like the term "post-mortem" (I have no idea what's wrong with the term, any business folks or managers out there know?), he did want to hold a meeting sometime mid-January where the entire contract group would review the year and try to figure out what went right, what went wrong, and what initiatives we can perform to try to improve profitability.
For various reasons (I'll go into more detail if it's requested), I believe that one thing our team, and indeed the organization as a whole, would benefit from is some form of organized code-sharing. The same things get done again and again by different people and they end up getting done (and broken) in different ways. I'd like to at least establish a repository where people can grab code that performs a certain task and include (or, realistically, copy/paste) that code in their own projects.
What should I propose as a workable common source repository for a team of at least 10-12 full-time devs, plus anywhere from 5-50 (very) part time developers who are temporarily loaned to the contract group for specialized work?
The answer required some cultural information for any chance at a reasonable answer, so I'll provide it here, along with some of my thoughts on the topic:
Developers will not be forced to use this repository. The barrier to
entry must be as low as possible to
encourage participation, or it will
be ignored. Sadly, this means
that anything which requires an
additional software client to be
installed and run will likely fail.
ClickOnce deployment's about as
close as we can get, and that's awfully iffy.
We are a risk-averse, Microsoft shop. I may be able to sell open-source solutions, but they'll be looked upon with suspicion. All devs have VSS, the corporate director has declared that VSTS is not viable going forward. If it isn't too difficult a setup and the license is liberal, I could still try to ninja a VSTS server into the lab.
Some of my fellow devs care about writing quality, reliable software, some don't. I'd like to protect any shared code written by those who care from those who don't. Common configuration management practices (like checking out code while it's being worked on) are completely ignored by at least a fifth of my colleagues on the contract team.
We're better at writing processes than following them. I will pretty much have to have some form of written process to be able to sell this to my manager. I believe it will have to be lightweight, flexible, and enforced by the tools to be remotely relevant because my manager is the only person who will ever read it.
Don't assume best practices. I would very much like to include things like mandatory code reviews to enforce use of static analysis tools (FxCop, StyleCop) on common code. This raises the bar, however, because no such practices are currently performed in a consistent manner.
I will be happy to provide any additional requested information. :)
EDIT: (Responsing to questions)
Perhaps contracting isn't the correct term. We absolutely own our own code assets. A significant part of the business model on paper (though not, yet, in practice) is that we own the code/projects we write and we can re-sell them to other customers. Our projects typically take the form of adding some special functionality to one of the company's many existing software products.
From the sounds of it you have a opportunity during the "post-mortem"to present some solutions. I would create a presentation outlining your ideas and present them at this meeting. Before that I would recommend that you set up some solutions and demonstrate it during your presentation. Some things to do -
Evangelize component based programming (A good read is Programming .NET Components - Jubal Lowy). Advocate the DRY (Don't Repeat Yourself) principle of coding.
Set up a central common location in you repository for all your re-usable code libraries. This should have the reference implementation of your re-usable code library.
Make it easy for people to use your code libraries by providing project templates for common scenarios with the code libraries already baked in. This way your colleagues will have a consistent template to work from. You can leverage the VS.NET project template capabilities to this - check out the following links VSX Project System (VS.Net 2008), Code Project article on creating Project Templates
Use a build automation tool like MSBuild (which is bundled in VS2005 and up) to copy over just the components needed for a particular project. Make this part of your build setup in the IDE (VS.NET 2005 and up have nifty ways to set up pre-compile and post-compile tasks using MSBuild)
I know there is resistance for open source solutions but I would still recommend setting up and using a continuous automation system like CruiseControl.NET so that you can leverage it to compile and test your projects on a regular basis from a central repository where the re-usable code library is maintained. This way any changes to the code library can be quickly checked to make sure it does not break anything, It also helps bring out version issues with the various projects.
If you can set this up on a machine and show it during your post-mortem as part of the steps that can be taken to improve, you should get better buy since you are showing something already working that can be scaled up easily.
Hope this helps and best of luck with your evangelism :-)
I came across this set of frameworks recently called the Chuck Norris Frameworks - They are available on NuGet at http://nuget.org/packages/chucknorris . You should definitely check them out, as they have some nice templates for your ASP.NET projects. Also definitely checkout Nuget.
organize by topic, require unit tests (feature-level) for check-in/acceptance into library; add a wiki to explain what/why and for searching
One question: You say this is a consulting group. What code assets do you have? I would think most of your teams' coding efforts would be owned by your clients as part of your work-for-hire contract. If you are going to do this you need to make absolutely certain that your contracts grant you rights to your employees' work.
Maven has solved code reuse in the Java community - you should go check it out.
I have a .NET developer that's devised something similar for our internal use for .NET assemblies. Because there's no comparable .NET Internet community, this tool will just access an internal repository in our corporate network. Otherwise will work rather much the way Maven does.
Maven could really be used to manage .NET assemblies directly (we use it with our Flex .swf and .swc code modules) is just .NET folk would have to get over using a Java tool and would probably have to write a Maven plugin to drive msbuild.
First of all for code organization check out Microsoft Framework Design Guidelines at http://msdn.microsoft.com/en-us/library/ms229042.aspx and then create a central Location source control for the new framework that your going to create. Set up some default namespaces, assemblies for cleaner seperation and make sure everyone gets a daily build.
Just an additional point, since we have "shared code" in my shop as well.
We found out this is very much a packaging issue:
Whatever code your are producing or tool you are using, what you should have is a common build tool able to package your sources into a "delivery component", with everything used to actually execute the code, but also the documentation (compressed), and the source (compressed).
The main interest into having a such a "delivery package unit" is to have as less files to deploy as possible, in order to ease the download of those units.
The build process can very well be managed by Maven or any other (ant/nant) tool you want.
When some audit team want to examine all our projects, we just deploy on their post the same packages we deploy on a production machine, except they will un-compressed the source files and do their work.
Since our source files also includes whatever files are needed to compile them (like for instance eclipse files), they even can re-compile those projects in their development environment).
That way:
Developers will not be forced to use this repository. The barrier to entry must be as low as possible to encourage participation, or it will be ignored: it is just a script to execute to get the "delivery module" with everything in it they need (a maven repository can be used for that too)
We are a risk-averse, Microsoft shop: you can use any repository you want
Some of my fellow devs care about writing quality, reliable software, some don't: this has nothing to do with the quality of code written in these packages modules
We're better at writing processes than following them: the only process involved in this is the packaging process, and it can be fairly automated
Don't assume best practices: you are not forced to apply any kind of static code analysis before packaging executable and source files.