As the upcoming release of the next major version of Team Foundation Server (code name "Orcas") gets closer, I want to write a bit about some of the new features that will be available. I'll also detail how Orcas will affect the Teamprise products and explain some of our future plans in this area. Hopefully this will help explain the big Orcas/Teamprise issues for our customers and others interested in Teamprise.
The biggest question that many of our customers have is one of compatibility - specifically, what will need to be done to allow Teamprise users to access Orcas TFS servers. I'm happy to report that the Microsoft engineers behind TFS have done an amazing job in the compatibility area. Existing versions of Teamprise will work against both TFS 2005 and TFS Orcas servers. Most new features that are available in Orcas (see below) will not appear in Teamprise until we release an update to our clients to add in the client portions of these new features. Once this new version of Teamprise is released, it will continue to work perfectly with TFS 2005 servers. In summary, Microsoft has designed TFS so that compatibility works both ways: a TFS 2005 client will work fine with Orcas (some new features will be unavailable) and an Orcas-aware TFS client will continue to work fine with TFS 2005 as well.
TFS Orcas introduces many new features. I'll briefly mention the new features in the version control and work item tracking areas, as the current versions of Teamprise products focus on these two areas.
Orcas adds a "destroy" feature for version controlled items. Normally when you commit a delete of an item, that item remains in the database but is effectively hidden for most operations. The destroy feature will permanently remove an item from the database. There are all sorts of reasons you might want a true "destroy" - two common scenarios are deletion of pure testing data and regulatory compliance.
In the version control UI there are two new interesting features - an "annotate" view and folder diff. Annotate (sometimes called "blame" in various tools) shows a view of an item across multiple changes and provides inline metadata about each change like the date and user who committed the change. Folder diff is an extension of the item compare feature in which folders can be compared against each other recursively.
Another often-requested new version control feature coming in Orcas is get latest on checkout. The idea behind this feature is that if you have a version of an item in your workspace that is not the latest version of that item and you do a check out, the latest version will be gotten first. Doing this has its pros and cons (it's easy to end up with a not-compiling set of files this way), but this workflow has been requested by many users so it was added for Orcas. The Teamprise client has had a similar "get latest on checkout" feature for a few releases now. In our upcoming release to fully support Orcas features, we'll be revisiting the way we implemented this feature to ensure that it works in a similar way to the way Microsoft implemented it in Orcas.
One new Orcas version control feature I haven't seen talked about much yet is a new kind of working folder mapping called a one-level or wildcard working folder mapping. The idea behind this is that normal working folder mappings are recursive - if I map $/foo/bar to c:\temp, all items below $/foo/bar are implicitly mapped to subfolders of c:\temp (excluding any explicit mappings of sub items). One-level WFMs allow you to map only the immediate children of $/foo/bar without mapping items further down. This is trying to solve the same sort of problems that cloaking solves - avoiding getting unnecessary files into your workspace.
A much-needed new feature in Orcas version control is offline support. In TFS 2005, you pretty much had to have a connection to the TFS server all the time in order to get work on version controlled items. Many users (especially those migrating from source control tools like CVS and SVN) were not used to this stringent of a requirement. Luckily Orcas TFS introduces the ability to work offline.
Finally, Orcas introduces some major performance improvements on the server side. Brian Harry has blogged about these performance improvements (see http://blogs.msdn.com/bharry/archive/2006/10/06/Orcas-Version-Control-Performance-Improvements.aspx) and the numbers are quite impressive. Since these improvements are to the server, the Teamprise clients get to take advantage of them with no changes.
On the work item tracking side, most of the new features are server-side and performance related. As with version control, Brian Harry has blogged some of the work item perf numbers (see http://blogs.msdn.com/bharry/archive/2007/01/14/orcas-work-item-tracking-performance-improvements.aspx).
As alluded to above, we are currently planning for a Teamprise update that will include the client-side bits of many of these new features. However, we will encourage our customers to upgrade to the new Orcas TFS release as soon as they wish, since the existing Teamprise clients will work without any updates. Also, many of the biggest improvements in Orcas have been performance improvements made to the server, which Teamprise clients will be able to take advantage of immediately.
The easiest way to try out Orcas TFS is to download the Beta 1 as a Virtual PC image. Another good resource to check out with regard to new Orcas TFS features is Brian Harry's blog on the TFS roadmap. To try out Orcas compatibility with Teamprise clients, just connect with any existing Teamprise client (if you need one, get an evaluation version).
Finally, if you have any questions about Teamprise client support for Orcas TFS, send an email to our sales alias at sales@teamprise.com or post our our forum.
I'm proud to announce that the latest version of our suite of products for accessing Microsoft Team Foundation Server from Eclipse and non-Windows platforms has been released. We're incrementing our version number by .1 for this release, but version numbers are pretty arbitrary. This effort represents 3+ months of development by our team, a number of new features, about 700 changesets, and about 200 resolved work items.
All of the new features and fixes are outlined in our release notes (edit: updated broken link) (which will look familiar if you're seen the Eclipse new and noteworthy documents).
The Teamprise plug-in now fully supports Synchronize inside Eclipse. This is an important feature for our customers coming from CVS or Subversion environments who are used to using Synchronize all the time. Sadly, our Sync support has never been very good until this release. One of our engineers rewrote the Synchronize engine inside Teamprise and it now works great. I use it myself all the time - it is a nice alternative to the Pending Changes view and should certainly feel more comfortable to our customers coming from CVS or Subversion.
Also, this release introduces a new visual work item query builder. Teamprise has historically had a few different ways of querying for work items, but as of this release we now have feature parity (in the querying area) with Visual Studio. This was an important goal for us - as being able to create custom queries on the per-developer level is important to getting the most out of work items in TFS.
I'm also excited that this release starts what will hopefully be a long series of integration projects to enable access to TFS with various tools. This version introduces a set of custom Ant tasks that allow access to the version control features of TFS from Ant scripts. We've used versions of these Ant tasks internally for a long time (over a year, if I remember correctly). There is lots of interest from customers who want to do Ant builds against TFS, so we added a bunch of features and documentation and are now releasing our set of Ant tasks (all the docs are viewable online). In addition, we are offering a plug-in for CruiseControl to allow continuous builds with TFS.
The primary use-case for the Ant tasks and CruiseControl plug-in is customers who have Java projects versioned by TFS. There hasn't been a good story until now for how to build such projects. We hope this will now start to change, and we have even more interesting projects in the build feature area planned for the future.
We've also increased the IDEs we support and test against. The Teamprise plug-in has been tested to work great in the following IDEs:
-- Eclipse 3.0 through the 3.3 milestone builds
-- MyEclipse
-- JBoss IDE
-- BEA Workshop
-- Adobe Flex Builder
-- RADRails
-- JBuilder 2007
-- RAD 6 and RAD 7
It's extremely easy to try out the Teamprise products. We have a hassle-free 30 day eval for everything we sell, and all we require is an email address. Go to our store to get your demo key, then proceed directly to our download page to grab the binaries you want. Of course you'll have access to our great technical support for free throughout your evaluation period.
About two years ago, Microsoft publicly announced they were planning a software product in the category of “application lifecycle management”. ALM is a fancy umbrella term for a broad category of products that combine a number of discrete software development tools into one integrated whole. These kinds of products are often classified under other names, such as “enterprise lifecycle tools”.
As time went on, it became clear that Microsoft was working on a brand new set of developer tools that would compete directly with products like IBM’s Rational suite. The tools included source control management, bug tracking, build management, project reporting, and document sharing, among others.
Microsoft eventually revealed that the ALM tool would be called Team System, and that the release would be coordinated with Visual Studio 2005. The client-side portion of the tools did ship with Visual Studio 2005, but the server side was delayed until Q1 2006. A few weeks ago, Microsoft shipped Team Foundation Server 1.0, which is the server side piece of Team System.
Team System
Team System is a repositioning for Microsoft in the developer tools space. Traditionally Microsoft focused on mid-level products having low levels of integration with application lifecycle tools. Examples of developer tools like that are the Visual Studio 6 IDE and the Visual Sourcesafe SCM tool. Selling these tools made a lot of sense from a business perspective since Microsoft is a platform company, and these tools encouraged development on the Windows platform. However, while being strategically sound, I doubt these tools were directly profitable for Microsoft.
Team System, in my opinion, is an attempt by Microsoft to enter a much more profitable segment of the developer tools market. It’s clearly going to compete head to head against IBM’s Rational suite, and companies like Borland are paying more attention to this high-end category of developer tools as well.
But - Microsoft faces a serious problem with their Team System offering. The segment of the developer tools market that the Team System functionality appeals to most is also the segment that is most likely to have a heterogeneous development environment. More specifically, the large software / I.T. shops that need the Team System features also need broad client support, which Microsoft does not offer.
An extremely common scenario is that a company considering adopting Team System has a mixture of .NET and Java programmers to support, as well as a mixture of IDEs and programming languages being used internally. Microsoft has provided nicely for the Windows and .NET developers by writing a TFS client that runs on Windows and inside Visual Studio 2005. But for Team System to be successful inside large enterprises, there must also be support for developers on Linux, MacOSX, Solaris, Java, Eclipse, or any other combinations of hardware platforms, IDEs, and programming languages. That’s where Teamprise comes in.
Teamprise
For the last six months, I’ve been part of a team working on a software product called Teamprise. We’re going to ship our 1.0 release next week, so I’ve been busier than usual over the last few weeks as the team has been doing final QA and bug triaging.
Teamprise fills in a substantial missing link in the Team System tool chain: cross-platform and cross-language client access to TFS. In a nutshell, Teamprise exposes the functionality of Team System to environments other than Visual Studio on Windows, while providing the same user experience as that platform. Companies looking to deploy Team System across the entire enterprise will roll out Visual Studio 2005 to their Windows/.NET developers, and Teamprise to everyone else.
Technology
Teamprise version 1 has been in development for a little over a year. The current codebase is around 150,000 lines of Java code and a very small amount of C code. At its core, Teamprise is a Java library built to directly access the web services of Team Foundation Server. Microsoft provides a .NET library (they call it an “object model”) that provides a high-level, object-oriented interface to the TFS web services. Teamprise is doing exactly the same thing in Java – we’re essentially reimplementing the .NET object model so TFS can be accessed from any platform.
The Java library is by far the largest part of the Teamprise codebase, comprising about 2/3 of all the code we’ve written. From an API design perspective, our API isn’t that different from Microsoft’s object model. Of course, a Java TFS client library is only useful if you build applications on top of it. Next week, Teamprise will ship 1.0 versions of three applications: a command line client, a graphical client, and an Eclipse plugin.
The most important Teamprise client application is our Eclipse plugin. This plugin provides TFS source control and work item tracking support for the extremely popular Eclipse IDE and all its variants. Of our three clients, we expect this is the one people will be the most interested in.
We also have a command line client that's very similar to the tf.exe command line client available from Microsoft -- it uses a compatible syntax and offers similar levels of functionality. The CLC will be very useful for performing scripted tasks against a Team Foundation Server instance. We use it internally as part of our automated build process. It could also be used interactively as the main interface to source control for a developer who prefers a command line oriented tool.
Our third client is a standalone GUI application called Teamprise Explorer. This client provides a native look and feel on all of the platforms we support, and is built using the Eclipse Rich Client Platform. For developers who aren’t using Eclipse as their IDE, or for non-developers who simply want access to source control files and work items, the GUI client provides an interface very similar to Microsoft’s Team Explorer / Visual Studio.
Conclusion
My intention with this post is to give a broad overview of the software I’m working on right now. In a follow-up post, I’ll explain in more depth about our development process, what’s worked and what hasn’t, and some of the more challenging things we’ve run into from a development standpoint.
Teamprise 1.0 will ship next week, and while we’re proud of the initial 1.0 effort, there’s still plenty of work to be done. It will be exciting to get our software into the hands of people who need to it to do their daily work and see where that takes the product.
