March 2009 - Posts
I have posted about changing the TFS Source Control Cache Settings in order to boost performance here
How can we be sure that the changes are correct and we have better performance now?
The TFS is saving statistics so you can monitor the cache performance easily.
What can you see?
- Current cache size
- Total cache hits
- Total download requests
- Total files in cache
How can you see it?
Step 1: Log in to the application tier and open a browser.
Step 2: Surf to - http://localhost:8080/VersionControl/v1.0/proxystatistics.asmx
Step 3: Click QueryProxyStatistics
Step 4: Click Invoke
A XML file will be opened with the statistics of your TFS Source Control cache statistics.
Many times when I record a web test, I do that on my local machine, the result is all the requests are directed to my localhost.
A very nice feature added in Team System 2008 is the “Parameterize Web Server” button added to my Web Test GUI.
Clicking on it will open a new window with one new parameter with the default name of “WebServer1”.
We can also see that the “Web Server” parameter is the server that the web test was recorded on.
Click OK and see that two things have happened a folder was added to your Web Test with the name “Context Parameters” and in all the requests the server name section was replaced with the parameter “WebServer 1”.
In order to edit the server name just open the properties window of the “WebServer 1” parameter and change the value field.
You can change the value of the “WebServer 1” parameter in other ways too but it is out of the scope of this post.
The TFS application tier holds a cache of the source control files so the users can download files from this cache instead of downloading them from the data base.
In order to boost performance you can change the size of this cache and how much old files to delete, you can do it in the following way:
Step 1: Open the Web.config file located in [Program Files]\Microsoft Visual Studio 2008 Team Foundation Server\Web Services\VersionControl
Step 2: Locate the <appSettings> section.
Step 3: Now change the CacheLimitPercent and the CacheDeletionPercent keys to get the best performance.
Step 4 (Optional): Instead of using the CacheLimitPercent that sets the percentage of the storage size, you can use CacheLimit to set the amount in MB to use for cache.
CacheLimitPercent - Sets the percentage of the storage size to be used for cache.
CacheDeletionPercent – The percentage of the cache size to delete in each deletion cycle.
CacheLimit - Set the amount in MB to use for cache.
There are times when you have a part of a scenario that needs to be repeated in other scenarios.
There are two options available:
- Record the steps each time for each of the scenarios.
- Create a Web Test that includes these scenario steps and embed the Web Test in other web tests.
Option 2 is obviously preferable because it saves valuable time, take in account that you are not just recording steps but you also adds roles to it and modify it, wouldn’t you prefer to do that one time only?
In Team System 2008 there is a nice feature that allow you to do option 2 very easily, extract the required steps, automatically create a web test and embed the web test in other web tests.
So how is it being done?
Step 1: Record your scenario, include the steps that will be later extracted.
Step 2: Modify your recorded Web Test, include roles to verify the results.
Step 3: Right click the first request and choose “Extract Web Test…” option.
You can see in the example that I have recorder a log-in scenario to facebook and checked my Inbox.
What I like to do is to extract the Log-In steps to reuse.
Step 4: Type the name of the new Web Test, choose the first step to extract and choose the last step to extract.
Step 5: Click the OK button and you are done!
You can see that the new Web Test is embedded in the web test I have first created, look at your test project and you will find there the new web test also.
What you can do from this point is use the new Web Test as stand allown Web Test or embed it to other Web Tests.
I have asked by clients that use the Web Test and Load Test how to add more Browsers and Network Types in order to simulate them.
First I will start with how can you get to these lists.
Step 1: Go to your Test Config file that is located in a solution that contains test projects and open it.
Step 2: Go to the Web Test tab
This is where you can find the list of “Browser type” and “Network type”.
Now lets add a new network, we will call it Demo.
Step 1: Go to “Program Files\Microsoft Visual Studio 9.0\Common7\IDE\Templates\LoadTest\Networks”
Step 2: Copy one of the network files and open it in any text editor.
Step 3: Change the Name to Demo and the BandwidthInKbps to 999.
Save the file and that is all, you have a new network type, you will need to close the visual studio and reload it in order to see the changes you made.
In order to add a new browser do the same, in the browser file you will find the browser’s header, copy one and change the content.
This question is rising every time that customers are not pleased with the performance.
They tell me that the performance problem is because of the fact that there TFS is installed on a virtual server.
After a deep check we always find that the reason is different, for example they don’t give enough resources to the server (TFS can’t work with 0.5GB of memory).
So the answer to the question is yes it can!!!
I like to mention here that it depends on the resources allocated to the server, satisfying the minimum requirements of the TFS will do the work.
When you finish to record a web test tells you that it checks for dynamic parameters, in case it finds one or more it asks if you like to add them to your test, so what is that dynamic parameters and what Team System adds to your recorded test?
Dynamic parameters are the parameters generated dynamically when running a web application and that are passed in the query string parameter values and form post parameter values.
Team System runs the web test again in the background searching for such parameters, when found it generates a script that will gather the data dynamically and pass it in the same method the web application does, doing that is necessary for the correct run of the recorded test.
That script that I have mentioned is using an extraction rule that captures the parameter from the HTTP response and binds it to a subsequent HTTP request.
The answer to this question is defiantly NO!!!
All bugs should be managed but not all bugs should be fixed.
Many times when I talk with my customers about the way they develop software I hear the wrong concept of fixing all the bugs before the release.
So why not to fix all the bugs? An application without bugs is not better than an application with bugs?
Well lets start with a very important fact: There are no applications without bugs, there are applications that have unfound bugs.
But we still left with the bugs that we have found why not to fix them all?
Fixing a bug has a cost, it takes developer time, tester time, it will probably create more bugs because of the changes we make in the code so the risk of delaying the delivery of the application on time is high.
So what is the right way of dealing with bugs?
As I mentioned before all bugs should be managed, the result should be a list of bugs that will be fixed based on criterions that are placed before.
What do we do with the bugs that are left open?
The are a few actions left to be taken regarding these bugs:
- Bugs that need to be entered to the known bugs list released with the product.
- Bugs that need to be passed to the support so they will have answers to customers including work arounds.
- Bugs that need to be fixed in later versions.
- Bugs that need to get in to Questions and Answers published to the customers.
These actions are the main actions, this list is not final.
I will give a brief introduction on how to manage bugs in one of my future posts.
Not once I am being asked the following question:
“Lets say that we have an active requirement that is assigned to a programmer, now the programmer is doing the design and the code for the requirement can I close\Resolve the requirement as done? what if I have bugs that are active and related to this requirement?”
First I like to start by saying that a requirement can be Resolved and then be closed or can be Closed without being resolved first depends on the methodology being used, for our discussion it will be the same result, the requirement is marked as done.
Now lets answer the question, the requirement is marked as done when the code that covers the requirement is done.
The reason I don’t care for the bugs that are related to the requirement is the fact that the requirement is done before the testing begins, one of the triggers for the testing cycle is the closure of the requirements that have been target for the release, and as we know, most of the bugs are being found in the testing cycles that are being executed after the requirements are closed.
We can see that the requirements closure has nothing to do with the related bugs they “live” on different stages in the application life cycle, requirements are done before the opening of the bugs that are related to them.
So why not to leave the requirements open then and to close them only after all the bugs that are related to them are closed?
That is a good question, no? Well I will leave all my requirements open and close them only after all the related bugs are closed, sounds grate…
Lets consider two problematic scenarios:
First Scenario: I have 3 bugs related to a requirement, good bug management practice say that one of the bugs will not be fixed, so the requirement stays open forever.
Second Scenario: I have 3 bugs related to a requirement, I have fixed all the bugs and I close the requirement, now I find another one, what should I do? Leave it closed? reopen?
I have more scenarios that are problematic, but I have a bigger problem, when should I declare Feature Freeze? In Software Configuration Management there is a declaration of Feature Freeze when all the requirement meant for the release are done and fixing bugs is starting.
We can see that it is very problematic to leave the requirements open when they have bugs.
Best practice is to mark the requirement as done when the code for that requirement is done.
We have been dealing with a strange performance issue with TFS.
One of our users reported that he's facing terrible performance issues while working with TFS.
Any source control operation takes a long time. Even exploring the source confrol folders causes Visual Studio to hang.
Besides that - the client PC works great with any other application and any other network resource.
We noticed that those TFS issues happen only in this specific PC, when working with Team explorer 2005 or with 2008, or while using msscci plugin for VB6.
Cleaning Visual studio cache did not solve the problem.
We solved the problem by creating a new workspace. As soon as we set the new workspace as the current workspace in source control explorer, the performance issues were gone.
Hope this tip will help you
What is Process Template?
The Process Template is used to create Team Projects and contain 6 main parts:
- Classification - Defines a team project's initial iterations and areas and contains the mapping file between the Team System and the MSProject.
- Groups and Permissions - Defines a team project's initial security groups and their permissions.
- Work Item Tracking – Contains the Work Item types definitions, initial queries definitions and you can define default work items.
- Windows SharePoint Services - Defines the project portal for the team based on a SharePoint site template, template files and process guidance.
- Reports – Sets up the report site with default reports.
- Version Control - Defines a team project's initial version control security permissions, and check-in notes.
Each one of these sections is configurable in order to make it as close as possible to your organization’s process.
Lets say you have more than one Team Project or see that in the future you will need to create more Team Projects that will need the same customizations.
Out of the box there are two Process Templates one for CMMI and one for Agile most of the times you will need to make changes in these configurations in order to make them as close as possible to your process.
So how do you create a new configurable Process Template?
You will need to download the closest Process Template to your process, make the changes and upload the new configured Process Template to your Team Foundation Server.
Step 1: go to Team –> Team Foundation Server Settings –> Process Template Manager…
Step 2: Choose one of the Process Templates, click the “Download” button and choose a local location.
Step 3: After you get the Success message click OK and make your changes.
Step 4: Open the “Process Template Manager” again, click the “Upload” button and navigate to the local folder that has the modified Process Template and click the “upload” button.
Step 5: You can see that the new Process Template is now in the list and ready to be used, click OK and you are ready to go.
That’s it, you have a Process Template that can be used to create as many Team Projects as you like.
Test Driven Development or TDD is a relatively new way of writing code.
In short TDD is writing the tests before you write the code.
What does it mean to write the tests before you write your code? How is that possible?
To be more specific the way to do that is as follow:
Step 1: Know the purpose of the code you are about to write.
This step is trivial, with no requirements how can you know what to write.
Step 2: Write a Unit Test that will test only one scenario in the code you are about to write.
It is important to keep the Unit Test very Very simple test only one thing I suggest to talk the most trivial scenario you have as the first unit test In case you are about to have more than one.
Step 3: Run the Unit Test you have just written and see that it fails.
This step is important to make sure the Unit Test is ok.
Step 4: Write the minimal code that will satisfy the Unit Test scenario.
Remember that all you need is to make the Unit Test pass at this step not to satisfy all the scenarios, we will do that later.
Step 5: Run the Unit Test and make sure it passes.
In case there are no other scenarios for this code stop here.
Step 6: Write the next Unit Test, again cover one scenario only.
Step 7: Run all Unit Tests and see that only the latest fails.
It is important to check all the time that you don’t brake the code by running all Unit Tests.
Step 8: Write the minimal code that will satisfy the Unit Test scenario.
Remember that all you need is to make the latest Unit Test pass at this step not to satisfy all the scenarios.
Step 9: You guest right, run all Unit Tests and see that they pass.
Step 10: Repeat steps 6 – 9 until all the scenarios are satisfied.
Step 11: Refactor your code.
On this step you remove duplicates and reorder your code, don’t forget to add comments.
Step 12: This is the last step, run all the Unit Tests again to verify that nothing is broken.
It looks difficult but after you change the state of mind you will find it very easy to use and beneficial.
So what are the benefits programming this way?
I will leave the reader to think about the benefits and to further investigate TDD.
I will also love to hear from you about your personal experience using TDD, in case you like to shear your experience add a comment to this post and I will gather the comments and publish them in one of my future posts.
When doing a Check-In action in the TFS Source Control the best practice is to associate the Check-In to one or more Work Items.
How do I choose which transactions from my work flow will be included in the Drop Down list of the work items in the check in window?
In the following screenshot we can see the screen I am talking about, you can see the State column and the Check-in Action column what we want to do is add more options (Depends on your workflow).
In order to do that we will need to add an action to the Transaction in the XML or thru the Process Editor.
Lets say we have a Task that has the following transaction:
<TRANSITION from=”Active” to =” Closed”>
In the XML I will add the following:
In the process editor I will do the following steps:
Step 1: Open the work item with the Process Editor using Tools—>Process Editor—>Work Item Types and choose one of the options, in this example I am opening the work item from the server.
Step 2: Choose the work item type to change, in this example I will change the Task.
Step 3: Switch to the work flow view and open the transaction properties window.
Step 4: Switch to the Actions tab.
Step 5: Click “New”
Step 6: Type microsoft.vsts.actions.checkin and click OK.
Looking in the XML the result will be the same no meter how you made the change (XML directly or thru the Process Editor):
<TRANSITION from=”Active” to =” Closed”>
The addings that are installed for office with the Team Explorer 2008 are for office 2008 and the MSProject 2008, so what would you do if you have office or MSProject 2003?
Step 1: Install the Team Explorer 2008
Step 2: Install the Team Explorer 2005, this needs to be installed after the completion of the Team Explorer 2008 so the dlls regarding the office will be of Office 2003 and MSProject 2003.
Make sure that the “.NET Programmability Support” Item is installed for all the office components and for the MSProject also.
In order to add the “.NET Programmability Support” Item incase you didn’t install it go to the add remove programs and select the “Change” option of the office and the MSProject applications.