CinNug - http://www.cinnug.com/.
This was a Microsoft product pitch for Team System by Alex Lowe who runs with the title Developer Evangelist. He made a point of apologizing for his title at the beginning.
To be released in the second half of the year sometime, this solution includes a Team Server and three possible client options, Team Architect, Team Developer and Team Test. Each offers extensions to Visual Studio 2005 which is due for release in the middle of the year.
The target market is the enterprise development team so cost will be high. Alex kept comparing it with the Rational target market. He mentioned that MS would beat their price by 20% but that we should not do a feature for feature comparison since they are very different products. MSDN Universal owners will have a license for one of the three client options but would have to by Team Server anyway. It is not clear which of the client features require Team Server to operate.
The idea behind this solution is to establish a standard framework from which teams can manage their projects. Apparently MS is starting to use the product internally but so little of it is working at the moment there is little internal feedback. It is their intention to completely adopt this development framework within the next 5 years.
Disclaimer 1: I have never used Whidbey or Team System so this write-up is probably filled with assumptions. I am copying Alex so he can correct us if he feels like it.
Disclaimer 2: I am also a long time java developer with perhaps 4 months of full time .Net work under my belt so please forgive any ignorance based bias. With years of VC++ and ASP development I have some background but java swept me off my feet many years ago.
So into the new features of Team System.
Team Architect contains a design diagramming tool replacing the use of Visio for class diagrams. Alex talked about the MS's preference for Domain Specific Languages (DSL) as opposed to the standards based UML syntax. He explained that customers are more likely to understand a language that uses the terms and shapes that they are familiar with.
The demo included a class diagram which showed up in non-UML format. Though we only saw two classes, one that inherited from the other, the inheritance arrow was UML like but the class boxes had rounded corners and contained non-UML sections and verbiage. I am all in favor of DSL's when they best represent the subject you are communicating but developers understand classes and I would wager most understand or at least have seen UML so why go non-standard for class diagrams?
The class diagramming tool included two way dynamic code synchronization so we you add to your diagram the code is being written and as you edit your code the diagram is being updated.
To my mind the biggest problem with class diagrams of larger systems is complexity so the selling points of a class diagramming tool should be the filters that can be applied to simplify the representation. Unfortunately we didn't see any of that.
Enhancements to VSS improve performance, scalability and offer new features like "shelving" which allows you to check your code into a new branch so that you don't pollute the main branch with your failing tests until you are ready. Since VSS already supported branching I assume all they have done is to make it easier to do and given it a fancy name.
Most significant improvement to VSS is that you can integrate with it remotely over HTTP so it can finally be used outside a LAN. While I love CVS, it would be better if we could use a source control system that integrated into VS.
Alex presented the unit test features that allow you to select the classes and methods to create tests for. Team Developer produced NUnit like code to exercise them. Not just test stubs but completed methods with some best guess code in them. This months .Net Developers Journal discusses the same feature with the similar screen shots in Whidbey which will be Visual Studio 2005 so I presume that there is some overlap in these products.
Notice I said "NUnit like". Microsoft has changed the "attributes" that you use to tag the classes and methods that are exercised as tests. NUnit uses "TestFixture" and "Test" but the new MS unit test integration uses "TestClass" and "TestMethod". I view this as a change in standard names that are out in the industry and is completely untenable.
Imagine a 100 developer team with 1000's of NUnit tests thinking about migrating to VS.Net 2005. I would lay money of the fact that no admin is going upgrade 100 developer machines in a weekend, the risk would be enormous. So as desktops are upgraded they become unable to run the product test suite. Alex mentioned that a tool would be provided to convert all your existing test cases but you are still leaving a portion of your developer community out of the testing process until they migration is complete.
Code attributes were invented as a way to abstract the code location from class and method names. This can be a fine idea if one wants that abstraction. MS has ignored the industry standard names and is forcing developer shops to build repositories of tests that are dependent on Microsoft testing tools. Choosing to use these new unit test tools is as bad an idea as choosing .Net as a cross platform development strategy. I see myself continuing to use TestDriven as my VS integrated NUnit framework.
The demonstration of test automation went pretty smoothly but I missed asking one question. When Alex entered into the test creation steps a new VS like window opened up with a new view layout targeted on test management, I believe Alex even called it a "Test Manager". From this new "Test Manager" Alex was able to run the tests and we saw the sample test being scheduled, we waited a little and then it was in run state and finally the red/green bar appeared. Alex then exited this new window to get back to the code.
This UI will impact the way test first developers work because it introduces a time and complexity barrier between your fingers in the code and the red/green bar of feedback. This will reduce the number of times tests get run which is contrary to the goals of test first development.
One of the major reasons that JUnit, NUnit and all the other XUnit frameworks work so well is that they are ultra simple to use. With IDE integration the single click to run a test is a really important feature. I think MS missed the boat on this one.
---------------------------------
By the way Alex, you mentioned that test first required writing tests before the code. You should rephrase that as "writing the tests while writing the code". The process requires that a single, simple test is written before code is written and when the test passes, another is written. Think really small cycles like 60 seconds or so.
---------------------------------
Team System has an integrated build and deploy process. Not much was said about it but a short demo showed the creation of a diagram that you can add IIS server definitions to, then you can drag your Web Projects into your diagram to deploy them.
Since best practice suggests isolating your build and deploy tools from your IDE this may not be a good solution. However, I didn't ask the question, and Alex didn't say whether the build/deploy tools could or could not be used from outside the IDE or whether an IDE deployment/license would be necessary to run them. It strikes me as insane to require a VS IDE on a build server. We need nant integration please. Then we can plug-in it into our CruiseControl.Net environment without a care in the world.
When you create a project you have the option to select a "profile" which is allows you to chose MSF Agile methodology (the only one available at the moment) which sets up your project with the "standard set of documentation required". I think they missed the point of agile if they think it requires any documentation. Anyway, I guess we can say that they are thinking about the concept anyway. Alex also mentioned that we will be able to set out own standard profiles to help with company standardization.
Alex admitted that the product was pretty shaky but promised performance improvements before its release date. Advertised release dates are in question and Team System will probably be released after the VS 2005 which it is targeted to integrate with.
Conclusion
----------------
Team System allows us to integrate the management of design, source code control, testing and deployment as well as bug tracking and reporting. This is a really good thing for development teams.
The architecture of Team System appears to be completely MS centric which could work for pure MS shops. Alex even mentioned that Team Server only works with the packaged SQL server and they have already received feedback from Oracle shops about having to support another database.
I look forward to trying it out when it is available.
Thanks to Alex for a good presentation.
Additional References
--------------------------------
Microsoft product page
http://lab.msdn.microsoft.com/vs2005/teamsystem/
The .Net Developer Journal story on Team Developer:
http://sys-con.com/story/?storyid=47759&DE=1
If you have a subscription you can see the story on Team Test:
http://sys-con.com/magazine/?issueid=507&src=false
-
Posts
2 comments:
Thanks for the recap Ed. I have quite a few comments/corrections so I’ll
make them inline…..
Recap of the CinNug (http://www.cinnug.com/) meeting last night.
This was a Microsoft product pitch for Team System by Alex Lowe who runs
with the title Developer Evangelist. He made a point of apologizing for his
title at the beginning.
Alex: Actually, I was saying that many of my colleagues have ditched the
title but that I have no problem with it. I don’t have a problem with it
because there is nothing wrong with being an evangelist. I evangelize
Microsoft products when they are the best tool for the job and I evangelize
other products when they are better suited for the task.To be released in the second half of the year sometime, this solution
includes a Team Server and three possible client options, Team Architect,
Team Developer and Team Test. Each offers extensions to Visual Studio 2005
which is due for release in the middle of the year.
Alex: There will be a fourth client created by Microsoft called Team
Foundation Client and it will provide non-VS users a mechanism for accessing
all of the data stored in Team Foundation Server (a cost savings in that you
will only need a Team Foundation Server CAL but you will have no client
costs as TFC will be free based on my understanding today). There will also
be non-Windows 3rd party clients – one has already been announced at
http://software.ericsink.com/entries/allerton.html.The target market is the enterprise development team so cost will be high.
Alex kept comparing it with the Rational target market. He mentioned that MS
would beat their price by 20% but that we should not do a feature for
feature comparison since they are very different products. MSDN Universal
owners will have a license for one of the three client options but would
have to by Team Server anyway. It is not clear which of the client features
require Team Server to operate.
Alex: “High” being a relative term of course. I would not get too caught up
on price at this point. Your statement about MS beating the competitions
price does not represent what I said. I said that the price of the client
(Team Architect, et al) will be roughly 20% more than the cost of the price
of the existing products (think Enterprise Architect edition’s price today
plus 20%). Of course, none of this takes into consideration the market
pressure that will likely alter the marketing/pricing plans as we get closer
to releasing the product. So, as I said before, don’t get caught up on
pricing yet.
The following features will require Team Foundation Server:
1) Work Item Tracking and associated Project Management hooks
2) Project Portal
3) Reporting on the Project using the TFS data warehouse, etc.
4) Process Guidance (MSF Agile, etc.) integration into the IDE
5) Enterprise Source Control (not referring to Sourcesafe here)
Now, there are also features that don’t require Team Foundation Server but
will only be in the Team X products. For example, the only edition of Visual
Studio 2005 that will include the Web and Load testing functionality will be
Visual Studio Team System Test edition.The idea behind this solution is to establish a standard framework from
which teams can manage their projects. Apparently MS is starting to use the
product internally but so little of it is working at the moment there is
little internal feedback. It is their intention to completely adopt this
development framework within the next 5 years.
Disclaimer 1: I have never used Whidbey or Team System so this write-up is
probably filled with assumptions. I am copying Alex so he can correct us if
he feels like it.
Disclaimer 2: I am also a long time java developer with perhaps 4 months of
full time .Net work under my belt so please forgive any ignorance based
bias. With years of VC++ and ASP development I have some background but java
swept me off my feet many years ago.
So into the new features of Team System.
Team Architect contains a design diagramming tool replacing the use of Visio
for class diagrams. Alex talked about the MS's preference for Domain
Specific Languages (DSL) as opposed to the standards based UML syntax. He
explained that customers are more likely to understand a language that uses
the terms and shapes that they are familiar with.
The demo included a class diagram which showed up in non-UML format. Though
we only saw two classes, one that inherited from the other, the inheritance
arrow was UML like but the class boxes had rounded corners and contained
non-UML sections and verbiage. I am all in favor of DSL's when they best
represent the subject you are communicating but developers understand
classes and I would wager most understand or at least have seen UML so why
go non-standard for class diagrams?
Alex: While I would generally not disagree with your sentiment in these last
two paragraphs, I think you need to step back and consider that the Class
Designer is not a Class Diagram as you know it in UML terms. That is, the
intent behind the Class Designer is to visualize code, perform object model
design, and simple code generation (stubbing). The intent of the Class
Designer is NOT to create UML Class Diagrams. Now, you can tell me that it
is not useful to you and that is your perspective. The reality is that the
roughly 80% of developers that are doing RAD/Agile development don’t need
UML Class Diagrams and the Class Designer will provide them with a very
useful alternative “view” of their code.
As far as UML versus DSL and all that goes with the debate, there are much
smarter people than Ed and I debating these topics at:
http://www-106.ibm.com/developerworks/blogs/dw_blog_comments.jspa?blog=317&e
ntry=67637&ca=dgr-lnxw03MSrejectsUML
and
http://blogs.msdn.com/jackgr/archive/2005/01/03/346035.aspx
The debate has been great and both sides have very interesting and valid
points from my perspective. Recommended reading for those of you who are
really interested in Model Driven Development
The class diagramming tool included two way dynamic code synchronization so
we you add to your diagram the code is being written and as you edit your
code the diagram is being updated.To my mind the biggest problem with class diagrams of larger systems is
complexity so the selling points of a class diagramming tool should be the
filters that can be applied to simplify the representation. Unfortunately we
didn't see any of that.
Alex: What kind of filters would you like to see? Can you be more specific
as to what you’d like to see in such a tool?Enhancements to VSS improve performance, scalability and offer new features
like "shelving" which allows you to check your code into a new branch so
that you don't pollute the main branch with your failing tests until you are
ready. Since VSS already supported branching I assume all they have done is
to make it easier to do and given it a fancy name.
Alex: Sorry, I must not have been explaining myself very well last night.
Visual Sourcesafe 2005 will not have “shelving”. Visual Sourcesafe 2005 and
Visual Studio Team System will be releasing two entirely different SCC
products.
Alex: Visual Sourcesafe 2005 will obviously be the next version of VSS and
will have many improvements – most of which are outlined at
http://msdn.microsoft.com/library/en-us/dnvsent/html/vssmap.asp.
Alex: Visual Studio Team System will contain an entirely different (read:
not Sourcesafe) source control system. It is different in many ways and one
of those ways is the concept of “shelving”. Shelving is similar to branching
so that would technically be an accurate description of what is taking place
inside the SCC. If you believe that shelving is just a fancy name then I’d
have to ask if you’ve ever had to create private branches for 10, 50, or
hundreds of developers at any given time. Private branches are very useful
feature and are not easy to create and maintain in any of the SCC system I
am familiar with.Most significant improvement to VSS is that you can integrate with it
remotely over HTTP so it can finally be used outside a LAN. While I love
CVS, it would be better if we could use a source control system that
integrated into VS.
Alex presented the unit test features that allow you to select the classes
and methods to create tests for. Team Developer produced NUnit like code to
exercise them. Not just test stubs but completed methods with some best
guess code in them. This months .Net Developers Journal discusses the same
feature with the similar screen shots in Whidbey which will be Visual Studio
2005 so I presume that there is some overlap in these products.Notice I said "NUnit like". Microsoft has changed the "attributes" that you
use to tag the classes and methods that are exercised as tests. NUnit uses
"TestFixture" and "Test" but the new MS unit test integration uses
"TestClass" and "TestMethod". I view this as a change in standard names that
are out in the industry and is completely untenable.
Alex: The person (James Newkirk) who designed and wrote most of NUnit is the
same person (we hired him before starting out on Team System) who designed
and helped write our Unit Testing features in Team System. Jim comments on
similar concerns raised in his blog at
http://weblogs.asp.net/jamesnewkirk/archive/2004/06/16/157703.aspx. While
Jim doesn’t say it in his blog, I believe that at least one of the reasons
that they had to change the names, etc. had to do with
licensing/intellectual property and the fact that James had worked on the
NUnit codebase before coming to Microsoft. Again, I’m not a lawyer (I play
one on TV) but I remember hearing something along those lines at one point.Imagine a 100 developer team with 1000's of NUnit tests thinking about
migrating to VS.Net 2005. I would lay money of the fact that no admin is
going upgrade 100 developer machines in a weekend, the risk would be
enormous. So as desktops are upgraded they become unable to run the product
test suite. Alex mentioned that a tool would be provided to convert all your
existing test cases but you are still leaving a portion of your developer
community out of the testing process until they migration is complete.
Alex: Yes, there will be a tool and early experiments by Jim and others
indicates that it may not be as difficult as you would assume to have both
kinds of tests running in your codebase. See the previous link.Code attributes were invented as a way to abstract the code location from
class and method names. This can be a fine idea if one wants that
abstraction. MS has ignored the industry standard names and is forcing
developer shops to build repositories of tests that are dependent on
Microsoft testing tools. Choosing to use these new unit test tools is as bad
an idea as choosing .Net as a cross platform development strategy. I see
myself continuing to use TestDriven as my VS integrated NUnit framework.
Alex: And we have no problem with you continuing to use NUnit if that is
what works best for you.The demonstration of test automation went pretty smoothly but I missed
asking one question. When Alex entered into the test creation steps a new VS
like window opened up with a new view layout targeted on test management, I
believe Alex even called it a "Test Manager". From this new "Test Manager"
Alex was able to run the tests and we saw the sample test being scheduled,
we waited a little and then it was in run state and finally the red/green
bar appeared. Alex then exited this new window to get back to the code.
This UI will impact the way test first developers work because it introduces
a time and complexity barrier between your fingers in the code and the
red/green bar of feedback. This will reduce the number of times tests get
run which is contrary to the goals of test first development.
One of the major reasons that JUnit, NUnit and all the other XUnit
frameworks work so well is that they are ultra simple to use. With IDE
integration the single click to run a test is a really important feature. I
think MS missed the boat on this one.
Alex: The “Test Manager” is a window that can be docked like any other
window in the IDE and only requires one button to be clicked if you would
like to kick off the unit tests. Please don’t base your judgment of anything
I showed you on the speed of a pre-beta product running in a virtual
machine.---------------------------------
By the way Alex, you mentioned that test first required writing tests before
the code. You should rephrase that as "writing the tests while writing the
code". The process requires that a single, simple test is written before
code is written and when the test passes, another is written. Think really
small cycles like 60 seconds or so.
Alex: There are many things I say that can be semantically shown to be
correct or incorrect and this is one of them. Your statement “The process
requires that a single, simple test is written before code is written”
pretty much validates the sentiment that I was trying to convey. That is,
you write a test before you write the code that is to be tested which sounds
a lot like “test first required writing tests before the code” to me of
course. I didn’t intend to imply (and don’t believe I did explicitly) that
you had to write gobs of code or tests to do test first development.---------------------------------
Team System has an integrated build and deploy process. Not much was said
about it but a short demo showed the creation of a diagram that you can add
IIS server definitions to, then you can drag your Web Projects into your
diagram to deploy them.
Alex: Not much was said because the build piece of Team System is not
functional in the build I have on my machine. In version 1 of Team System,
the modeling piece will end with VALIDATION only and does not tie into the
build process (or the deploy process in the purest of senses because it is
only a reference diagram and doesn’t actively participate in the
deployment).Since best practice suggests isolating your build and deploy tools from your
IDE this may not be a good solution. However, I didn't ask the question, and
Alex didn't say whether the build/deploy tools could or could not be used
from outside the IDE or whether an IDE deployment/license would be necessary
to run them. It strikes me as insane to require a VS IDE on a build server.
We need nant integration please. Then we can plug-in it into our
CruiseControl.Net environment without a care in the world.
Alex: Again, the diagramming is not a deployment tool but rather a
validation tool. The Build piece of Team System will be housed in Team
Foundation Server so it is not “in” the IDE and does NOT require the IDE to
do its thing. The IDE can be used to configure the build functionality. We
also provide an nant like system called MSBuild.When you create a project you have the option to select a "profile" which is
allows you to chose MSF Agile methodology (the only one available at the
moment) which sets up your project with the "standard set of documentation
required". I think they missed the point of agile if they think it requires
any documentation. Anyway, I guess we can say that they are thinking about
the concept anyway. Alex also mentioned that we will be able to set out own
standard profiles to help with company standardization.
Alex: Don’t confuse pure Agile manifesto type development with MSF Agile
which is admittedly Microsoft’s twist to both MSF and Agile. It is not the
intent to produce another Agile methodology but rather to provide guidance
for MSF shops that want to introduce Agile concepts into their development
lifecycle.
Alex admitted that the product was pretty shaky but promised performance
improvements before its release date. Advertised release dates are in
question and Team System will probably be released after the VS 2005 which
it is targeted to integrate with.
Alex: Yes, the product is NOT DONE so naturally there are bugs, incomplete
functionality, and general signs of growing pains. All pre-beta products
(and most beta products) contain lots of extra debugging and profiling code
that slows down the product. Oh, and I was running all of the code in a
virtual machine which of course further slows down the application.Conclusion
----------------
Team System allows us to integrate the management of design, source code
control, testing and deployment as well as bug tracking and reporting. This
is a really good thing for development teams.
The architecture of Team System appears to be completely MS centric which
could work for pure MS shops. Alex even mentioned that Team Server only
works with the packaged SQL server and they have already received feedback
from Oracle shops about having to support another database.
Alex: Team System is not completely MS centric. Team System is extremely
extensible and it will be possible to plug in other Source control products,
work item tracking products, etc. in place of what is provided as part of
Team System as a result (this will require hooking into the exposed API by
either the product vendor or you the developer). There will also be 3rd
party clients for non-Windows operating systems as a result of the demand
the 3rd party vendors have heard from mixed and non-MS shops. So, I would
say it is inaccurate to portray the product as “completely MS centric which
could work for pure MS shops”. Team System is a Microsoft product and so it
naturally has deep hooks and integration into our other products – this is
true of products from virtually any vendor. The extensibility I’ve described
is not true of many vendors and I can’t wait until the day that customers
are building J2EE projects stored in the source control of Team System. =)I look forward to trying it out when it is available.
Thanks to Alex for a good presentation.
Thank your for having me!
Regards,
Alex
Post a Comment