.NET Web Service Best Practice for Multiple Developers
We have a large ASP.NET project with several hundred reports. We are going to move all SQL queries (working with Oracle Database) into three web services. Web services are categorized by commands, selections, and report queries. We have to deploy a subset of our project using SQL * Server to multiple locations that are offline. So having all the database connections and queries in the web services makes the application manageable and we can pull out a subset of the reports and not change the code. The project is under source control using Serena ChangeMan software.
The problem is that we have several programmers and they all need to validate web service files to work with their elements. We've just implemented branching, but it's slowly becoming a nightmare. We have monthly production shipments and sometimes items that need to go into the monthly build will be picked up until next month. Merging has become a manual process.
I have some internet searches and am surprised that I could not find any good white pages of Best Practice Web Services. There are many large companies that have had to face these challenges.
Do most large development groups use branching? I have read that Visual Studio Team System Database Edition can provide standard code that will allow an application to connect to various databases. Will buying Team System be the best method? Or does anyone know where I can find documentation to help us resolve these issues?
Thanks, Lorie
This problem seems to be completely independent of the purpose of the software. The problem here is that you have a small, finite number of files that multiple developers will work with on a daily basis. I have no experience with Serena ChangeMan and TFS software other than playing with it. I have experience with several version control systems that use the merge / commit model: CVS and Subversion . They are excellent, free version control systems that are widely used.
If you're unfamiliar with the merge / commit model, the idea here is that no developer can "check" and lock a file for changes. Anyone can download and make changes to any file. When it's time to commit those changes to the source database, the repository software will prevent the 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-check and then you commit that version. This model is very successful and highly scalable.
Having said all that, even the merge / commit model cannot solve the grief of 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 could create three groups of related web services. I think this, when combined with using a merge / commit version control system, will solve your problems.
CVS and Subversion servers run on Windows, Mac and Linux. For each of these, there are several clients available on a number of operating systems. These include regulars, Visual Studio plugins, and shell plugins. Another plus is that both CVS and Subversion are available from the command line, which makes scripting easier (auto build, I think).
source to share