VSPro vs. VSTS vs. Something Better (tm)
-
I'm on a team of three, using VS2008 Pro/VB.Net on our main project, SQL 2000, and Sourcesafe from the same era. About a year ago there was a thread here to see who was moving to Team System, and for what reasons. My questions are: Short version: dev to dev, what's your opinion of TS now? Long version: for those of you who have gone over to TS from Pro (or other single-user version), what pros/cons really jump out at you? Do you notice a large performance gain/loss when working in a project? Is it more/less buggy in general? Is there anything you miss from Pro that isn't in TS? With integrated builds, is everyone required to work on the central dev server, or a version stored on your local computer? Would you consider TS worthwhile for such a small team? Do you prefer working with the database through TS, or through the database's own UI? <scenario rant> Our team doesn't keep each other too informed. Because there are so few of us, and no one who "knows code" to really call us on it, things are quite lax. There are no scheduled builds, and the dev server hangs whenever one starts - sometimes a dozen times an hour. Project changes are rarely reloaded until the GUI restarts, so new files are excluded from the project continuously for their first few days. Working on a local copy reduces the lag, but checking in a file does not automatically move the new version to the dev server, so there are a lot of lost/overwritten edits. These are all seen as software shortcomings and not flaws with personal habits, so I've been asked to find a VS-compatible system that will "do it right". </scenario rant> If TS is overkill or just not suitable for this scenario, what alternatives are you using? I'm in the research phase. Thoughts, opinions, and warnings are all welcome.
-
I'm on a team of three, using VS2008 Pro/VB.Net on our main project, SQL 2000, and Sourcesafe from the same era. About a year ago there was a thread here to see who was moving to Team System, and for what reasons. My questions are: Short version: dev to dev, what's your opinion of TS now? Long version: for those of you who have gone over to TS from Pro (or other single-user version), what pros/cons really jump out at you? Do you notice a large performance gain/loss when working in a project? Is it more/less buggy in general? Is there anything you miss from Pro that isn't in TS? With integrated builds, is everyone required to work on the central dev server, or a version stored on your local computer? Would you consider TS worthwhile for such a small team? Do you prefer working with the database through TS, or through the database's own UI? <scenario rant> Our team doesn't keep each other too informed. Because there are so few of us, and no one who "knows code" to really call us on it, things are quite lax. There are no scheduled builds, and the dev server hangs whenever one starts - sometimes a dozen times an hour. Project changes are rarely reloaded until the GUI restarts, so new files are excluded from the project continuously for their first few days. Working on a local copy reduces the lag, but checking in a file does not automatically move the new version to the dev server, so there are a lot of lost/overwritten edits. These are all seen as software shortcomings and not flaws with personal habits, so I've been asked to find a VS-compatible system that will "do it right". </scenario rant> If TS is overkill or just not suitable for this scenario, what alternatives are you using? I'm in the research phase. Thoughts, opinions, and warnings are all welcome.
It's not the software, you can do everything you want to with vs pro & some open source integration tools. We use VS 2008 (pro) and it all works fine. Everything is nicely integrated. the source server is subversion. This integrates nicely with vs pro via ankhsvn (and we use tortoisesvn for non-vs files). We have separate code branches for releases and development. We use both nunit and mstest for unit testing. we have cruise control .net running on a build server which is automatically kicked off whenever any changes are checked into the source control (as well as a regular nightly build). ccnet runs the full build (using msbuild scripts), runs all the unit tests, fxcop and stylecop, and reports failed builds via a system tray app (cctray) running on each dev's PC, and gives a link to a web page which includes full build reports and stats. It sounds like you have problems that are deeper rooted than what software you are using. changing to vsts won't magically solve your problems. Step 1 is to get your nightly build running automatically, every night without fail. every morning assign responsibility to 1 person to fix the build if it broke. You can rotate the responsibility on a weekly basis, or pass the responsibility to the person responsible for breaking the last one. For the record, I've used vsts & tfs in the past, and yes it's quite nice. yes it integrates everything very tightly like tasks, bug reports, source control, build server etc, but it's nothing you can't do using the open source apps I've mentioned. The one thing vsts & tfs does that we don't have is bug tracking, but you can add that in with something like trac or bugzilla, we just don't have a requirement for it at the moment. Everything in pro is in vsts as well, so you won't miss anything if you do switch to vsts. Additionals in vsts are the really tight integration with tfs, which gives you source control, bug tracking, automated builds, etc, etc, etc. tfs is miles better than visual source safe. (in fact, anything is better than source safe. ditch that now - we use subversion, but seriously anything is better)
Simon
-
It's not the software, you can do everything you want to with vs pro & some open source integration tools. We use VS 2008 (pro) and it all works fine. Everything is nicely integrated. the source server is subversion. This integrates nicely with vs pro via ankhsvn (and we use tortoisesvn for non-vs files). We have separate code branches for releases and development. We use both nunit and mstest for unit testing. we have cruise control .net running on a build server which is automatically kicked off whenever any changes are checked into the source control (as well as a regular nightly build). ccnet runs the full build (using msbuild scripts), runs all the unit tests, fxcop and stylecop, and reports failed builds via a system tray app (cctray) running on each dev's PC, and gives a link to a web page which includes full build reports and stats. It sounds like you have problems that are deeper rooted than what software you are using. changing to vsts won't magically solve your problems. Step 1 is to get your nightly build running automatically, every night without fail. every morning assign responsibility to 1 person to fix the build if it broke. You can rotate the responsibility on a weekly basis, or pass the responsibility to the person responsible for breaking the last one. For the record, I've used vsts & tfs in the past, and yes it's quite nice. yes it integrates everything very tightly like tasks, bug reports, source control, build server etc, but it's nothing you can't do using the open source apps I've mentioned. The one thing vsts & tfs does that we don't have is bug tracking, but you can add that in with something like trac or bugzilla, we just don't have a requirement for it at the moment. Everything in pro is in vsts as well, so you won't miss anything if you do switch to vsts. Additionals in vsts are the really tight integration with tfs, which gives you source control, bug tracking, automated builds, etc, etc, etc. tfs is miles better than visual source safe. (in fact, anything is better than source safe. ditch that now - we use subversion, but seriously anything is better)
Simon
Thanks for all the leads, and details, and I'll definitely check these out. I think the request for better software was to avoid conflict by blaming software instead of devs. I interpreted it as "Find a system that doesn't allow" us to ignore/forget updates (and other stuff, but I'll keep the rant to a minimum). It seems like your system makes what we do irrelevant until items are checked in and shifted to the build server, and automates a lot of things that have caused us problems by doing them (or not doing, heh) manually. That sounds much easier, and less restrictive. :thumbsup:
-
Thanks for all the leads, and details, and I'll definitely check these out. I think the request for better software was to avoid conflict by blaming software instead of devs. I interpreted it as "Find a system that doesn't allow" us to ignore/forget updates (and other stuff, but I'll keep the rant to a minimum). It seems like your system makes what we do irrelevant until items are checked in and shifted to the build server, and automates a lot of things that have caused us problems by doing them (or not doing, heh) manually. That sounds much easier, and less restrictive. :thumbsup:
Yeah, automation is the key. It makes things so much better. Good luck.
Simon