Team System - Phases 4,5 - Source Control & Bug Tracking

By Eli Ofek at August 25, 2005 13:05
Filed Under: Team System, Proffesional, Team System
Since we decided to stop the pilot for now, we did not check the Source Control & Bug tracking thoroughly.
We already know that the performance is bad.
From functionality point of view, I can say that we used almost all the features at least once & everything worked.
We did not try use cases where 2 people are working on the same code doing merging.
Since performance is one of the big issues of phase 4,5,there is no point in testing it now.
We can only say for now that the functionality & the integration is nice.
I will post new information when the pilot will be resumed after the release version comes out .

Team System - Phase 3 - Migrating the code from 1.1 to 2.0

By Eli Ofek at August 24, 2005 16:09
Filed Under: Proffesional, Proffesional, Team System, Team System
After migrating all the source files, it's time for the actual code migration.
AS stated before, the pilot is implemented on a real project.
The project is divided to 1 infrastructure subsystem and another 4 subsystems.
For now, we decided to migrate only the infrastructure subsystem,
and one of the other subsystems, that contains both server & client code, so it's a good case to work on.
The conversion was done on a VMWARE machine, running with one 2.7Ghz CPU & 512MB RAM with Windows 2003 Server SP1.
We asked Ziv (one of the senior developers in the system) to migrate the code.
Ziv did not have prior experience with CLR 2.0. Most of the findings here were translated from and Internal Report Ziv wrote.
The target was to make the code compile with no errors or warnings what so ever,
and then make all the unit tests pass as green ( Nunit 2.2.2, see prior post).
It took 2 days to make the code compile, 2 more days to solve runtime errors, and another day to make all the unit tests pass.
No QA tests were done to the system beyond that.
All the code changes were made with special regions & were well commented,
for easy merging to the  real dev branch in the future.
It took a total of 5 work days for 1 senior developer to complete the mission.
General impression from the code migrations stage:
The new IDE is pretty stable for a Beta 2 version. during the working week we encountered only few Exceptions/Aborts.
The newly added features such as code refactoring etc are great.
The main problem was performance. The performance is unacceptable for normal developing.
Compilation time increased about 5 times more then VS 2003, the IDE often freezes for several seconds which is pretty annoying...
Another general problem we encountered is that the new IDE make a bad assumption that the developer has an Internet connection.
A big part of the links in the IDE are links to the Internet and not the local MSDN installation.
in our case the developers work in a closed intra-net environment, so it's a bit frustrating.
During the migration, the compiler often tries to help by giving a link to MSDN
which explains how to convert the code which is great, but most of the links again - refer to the Internet,
even if the information is also available in the Local MSDN installation.
sometimes the explanation was available only in the Internet, which forced us to go to another network and print some pages there...
The new MSDN Feel & Look is nice, it takes time to get used to for us "old" developers,
but it seems like an improvement as the search tab now tries to be a "Search Engine" like.
The big problem with the new MSDN was that it was very buggy.
The search engine constantly returned false results. For example, if I search for the work "XML" I get X documents,
and when I search for "XML and Schema" I get Y documents, and Y was greater then  X which is logically impossible.
it gave us a bad time while searching for migration information, especially since the original compiler help links did not work for us.
I edition to that , the new MSDN Archive Manager which is a nice Idea, gave us trouble too.
We selected several topics to be included, but when we saved and open the MSDN tool,
the list of topics we got there was different from the one we selected...
The integration with the Team Foundation Server is very nice & user friendly, but performance is terrible too.
The Team Foundation server has memory leaks which causes performance degradations, and after 3 days of work with 1 developer
I had to restart the services in order to be able to continue testing in a reasonable time...
List of Source Code changes we made during the migration phase:
  • Changes we made in order to make the code compile with no Errors or Warnings:
    • Major Changes:
      • The usage of XML Schemas has changed. The new framework uses a class called XmlSchemaSet which represents a collection of schemas which compile together to a single logical unit.
      • The usage of XML Readers has changed. The new framework makes the XmlValidatingReader obsolete. Instead, we now need to work directly with the XML Reader, supplying it with an object of type XmlReaderSettings which defines some attributes on the reader we have created.
      • Compile-time error identification of unmanaged resources usage problems. I must say we liked this new feature a lot. the new framework identifies in compile time bad usage of Finalizers and reports on it. We encountered only one instance of this case in the system and replaced it with a correct implementation. Coolness.
    • Minor Changes:
      • The Assembly signature method has changed. in CLR 1.1 we signed the Assemblies using the AssemblyKeyFile Attribute usually found in the AssemblyInfo.cs file. Instead, the new framework makes as use  Project Level definition. This is not so bad, only it was frustrating to change it manually to our 70 assemblies. in VS2003 we could select multiple projects and change a property for all of them at the same time. In 2005 The GUI did not let me select multiple projects for the Project properties dialog. I wonder why.
      • The usage of Path.InvalidPathChars was replaced with the Path.GetInvalidPathChars() method.
      • The Certificates usage was changed. The new framework defines a delegate method on ServicePointManager for Certificate validations instead of the class usage which replaces the standard behavior of the Certificates Control.
      • Form.AutoScaleBaseSize used to be an int value. In the new framework it was replaced with Form.AutoScaledimensions which is a float.
      • The AppDomain.GetCurrentThreadId() Method was replaced with CurrentThread.ManagedThreadID.
      • The SmtpMail class is now obsolete. there is a new class which replaces it. we decided to remove the entire code that uses SMTP which implemented special critical error log reporting using email, since we never used it in the past 3 years.
      • The Dns.GetHostName() method was replaced with Dns.GetHostEntry() method.
      • Parameter.Add() method was replaced with Parameter.AddWithValue() method.
  • Changes due to runtime errors:
    • This is a new cool feature of the runtime. The new Framework identifies at runtime of objects trying to access  other objects from a Non GUI thread to a GUI Thread object without a proper Invoke. It throws a proper Exception. we identified only one case in the system (Bad code in the Client's Splash Screen). This is very cool, because such code can ofthen create random results, and hard to re-create bugs. Other instances of the problem might come up when the system will be sent to QA for a proper regression test.
    • Microsoft score again. Another cool feature ! The runtime now identifies inconsistencies between XSD Schemas of Datasets, against the real Database Types ! When the runtime encounters an inconsistency, it thrown an exception. The the system we encountered 2 instances of the problem, and the Schemas were corrected according o the DB Types. I guess it happened when someone changes the DB without changing the DAL Code properly.
  • Changes made due to Unit Test Failures:
    • The new framework adds the `xml:space="preserve"` Attribute when it finds an empty node in the XML Document. We added the new attribute to the proper places in the XML files.
  • Some Unresolved Issues we decided to let go for now:
    • The client application had a special mechanism that used a special "Home made" Semaphore ( CLR 1.1 didn't have a built in one, CLR 2.0 does). the implementation was bad and we knew it for some time now. it caused a some bugs in the GUI, but they were very rare. When running on CLR 2.0 for some reason the mechanism stopped working almost completely. We did not try to fix or search why, as the proper action here is to re-write the entire mechanism correctly.
    • The server Application started to load very slowly. Short investigation discovered that there is a problem the the Assemblies loading phase that causes some kind of a deadlock. The runtime releases the deadlock somehow after 20 seconds and everything goes on well. It's mainly annoying for debug time to wait these extra 30 seconds each time we start the server process...
    • The Client Splash Screen started to appear in the top left corner of the screen instead of the center. We didn't bother to check why for now.
Pilot Milestone Conclusions:
Due to these findings we have decided to stop the Pilot process at this time.
We understood that the migration process is not very heavy,
so we don't need to start it too much ahead before we actually want to transfer to 2.0.
We are estimating that giving the knowledge we got during this work week,
 the entire team (4 People) can Migrate all the system in one more week).
One of the possible ways we thought of going here before the pilot
was to transfer the dev team to start developing Version 2.0 of the System which starts in less then a month on the Beta2,
with the new Team Foundation, and only transfer them to the release version in November after the Whidbey final release,
as Version 2.0 of the system is not expected to reach production stage until the middle of 2006.
Sadly, since the development experience with the current performance is not acceptable,
we have decided to wait for the final Release in November,
Hoping that Microsoft will fix the performance problems & server Leaks by then.
We saved the converted source, awaiting November 7.
Phase 4 & 5 of the Pilot will not happen for now,
I will write some conclusions about it in a separate post, but it won't be informative as I planned too.

Team System - Phase 2 - Migrating VSS 6.0d to Team Foundation

The Environment is ready,
Even played with it a bit, creating new Team Projects, and all is well.
Experience thought me a long time ago, that if something is working for several files,
It won't necessarily still be working just as well for hundreds or thousands.
The mission in this phase was to import the real project's VSS DB (6.0d)
with all files in all versions & labels into the newly created Team Project.
The VSS DB is currently 2.6 GB, after working on it for a few years now.
I figured that it's a good challenge for the Team Foundation.
For the mission I needed a disconnected copy of the VSS DB, which I can use with the VSSConverter tool ,
in order to migrate it to the team system project.
This request discovered some unpleasant information:
All the legato backups from the last year kept a corrupted DB, since users were never disconnected from the db before each backup ...
I notified the person in charge, and asked for an archive file, in order to restore my own copy I can work with aside.
Alas, I found out that for some weird reason, the Archive tool (Both the GUI & Command line) could not archive the DB properly.
The archive file was always created suspiciously too small,
and when opening it we found that it archived only a small portion of the projects in spite the fact that we specified to backup everything.
With all this trouble I decided not to wait any longer
(this procedure took several days, it takes lots of time to archive & restore 2.6 GB VSS DB for each "try"),
And decided to change my target.
I have decided to let go on all the file versions & labels, and just import a pure latest revision to the Team foundation server.
The challenge is now easier, but still dignified.
We are talking about a total of 140 MB for all files, around 4,400 of them...
I achieved that by doing a "Get Latest" on all the projects recursively to a folder in the file system.
Now I had to disconnect all the projects from source control, but because there are so many of them, I didn't want to do it manually,
So I used a batch tool to do the job for me - "SourceSafe Binding Remover tool " from GotDotNet.
The tool seemed to work well, reporting no errors. (I removed all the RO attributes from all the files before running it).
Later on , I opened each Solution file (there were about 5 of them) using the VS  2005 IDE,
and used the "Add To source Control" menu item.
The wizard reported that the project files contain some "left overs" from a previous source control system, and offered to correct the files.
I accepted the offer, and it worked like magic.
It took about 5 hours to import all the files, but it finished with all files safely in the Team Project.
I checked to see the SQL DB "Data" folder, and the size was ~ 200MB, which seemed pretty reasonable considering I have just added about 140MB of data to it ...
this concludes Phase 2 of the experiment. Didn't get it as I planed too, but got enough to work with for the next phase.

Team System - Phase 1 - Installing the environment - Cont.

By Eli Ofek at August 22, 2005 14:54
Filed Under: Proffesional, Proffesional, Team System, Team System
Hi friends,
Again, didn't have time to blog my findings until now, but I will try to catch you up with the experiment.
While continuing to install the environment, I ran into some more problems, most of them easily fixed after googling for them.
the first problem was getting the "Initialization for plugin "Microsoft.Pcw.wss" failed"
Message in the portal site.
The problem is easily solved if going into the IIS manager and moving the "Report" & "Reports Server" Virtual Applications
to a new pool, so they can run under ASP.Net 2.0 by themselves.
The full explanation can be found at Microsoft Technical Forums, here.
Another problem I ran into happened after creating a new Team  Project to play with, which later on I wanted to delete.
Surprisingly, I found out that there is no obvious way from the IDE to do that.
I did not expect an "easy" way, as no one wants this kind of action which is very destructive to be activated by people "with an easy finger on the trigger".
Googling for this again brought me to a command line solution that is working pretty well.
You can find the "How To" right here on Buck's Blog.
Another problem discovered later on in an Exception in the "Work Items" Web Part.
This was easily solved too by adding a new Work Item so the work items repository would not stay empty.
This consludes the environment installation.
Next: Importing the code from VSS to Team Foundation.

Playing with Team System Beta 2

By Eli Ofek at June 06, 2005 20:32
Filed Under: Proffesional, Team System
I started testing Microsoft's new Team System Beta 2 (Visual Studio 2005 & Team Foundation).
On the coming weeks I will test them with a test case of a real project,
the same one I used to convert Unit Test from Nunit 1.0 to Nunit 2.2.2.
The test will consist of the following phases:
1) Installing the environment.
2) Loading all code from VSS 6.0d to Team Foundation Source Control
3) Converting all code from Framework 1.1 to 2.0, without warnings And all Unit Tests green.
4) Testing the source control (Labeling, Branching etc...)
5) Testing the Bug Tracking.
From Time To time, I will publish interesting stuff I encounter during the process, so stay tuned ...



<<  May 2021  >>

View posts in large calendar

Page List


    I work for Microsoft Israel as s Senior Premier Field Engineer.
    The opinions expressed here are my own personal opinions and do not represent my employer's view in anyway.