.NET Web Service Best Practice for multiple developers

Question

Hello,

We have a large ASP.NET project consisting of several hundred reports. We are in the process of moving all the SQL Queries (running against an Oracle Database) into three web services. The web services are categorized by command, selections and report queries. We have to deploy a sub-set of our project using a SQL*Server backend to several locations that are disconnected from the Internet. Therefore, having all connections to the database and queries in the web services makes the application manageable and we can pull the sub-set of reports and not have to modify the code. The project is under source control using Serena ChangeMan software.

The issue is we have several programmers and they all need check out the web services files to work on their items. We have just implemented branching, but it is slowly becoming a nightmare. We have monthly production deliveries and sometimes items that are supposed to go into the monthly build get held up until next month. The merging has become a manual process.

I have conduct Internet Searches and I’m surprised that I have not been able to find any good “Best Practice” web services architecture white pages. There are many big companies that must have faced these issues.

Do most large development groups use branching? I did read that Visual Studio Team System Database Edition could provide standard code that will allow the application to connect to different databases. Would purchasing Team System be the best method? Or does anyone know where I can find documentation that will help us address these issues?

Thank you, Lorie

Answer 1

We use SOA, but we also use SVN which is more merging oriented. Maybe consider a different source control system?

Answer 2

This problem would seem to be quite independent of the purpose of the software. The issue here is that you have a small, finite number of files that multiple developers will be working with on a daily basis. I do not have experience with Serena ChangeMan software nor TFS other than playing around with it. I do have experience with a couple of version control systems that use a merge/commit model: CVS and Subversion. These are both excellent, free version control systems that are widely used.

If you are unfamiliar with the merge/commit model, the idea here is that no single developer can "checkout" and lock a file for changes. Everyone can download and make changes to any file. When it is time to commit these changes to the source code database, the repository software will prevent a commit if other changes have been made to the file by another developer. The new version is then downloaded, and in most cases the changes are automatically merged with your changes. You re-test, and then you commit that version. This model is very successful and very scalable.

Having said all of that, even the merge/commit model cannot solve the grief of having a small number of files with a lot of developers making changes to said files. I would recommend splitting your functionality into more web services. Perhaps instead of three, monolithic web services you might create three groups of related web services. I think this, coupled with using a version control system with merge/commit will solve your problems.

CVS and Subversion servers run on Windows, Mac and Linux. There are a number of clients for each, available on a number of operating systems. These include stand-along clients, Visual Studio plug-ins, and shell plugins. Another plus is that both CVS and Subversion are available from the command line which makes scripting (think automated build) fairly easy.

Answer 3

Why not segment your logic into individual class files that can be checked out by each developer?