Guy kolbis

So, first thing first. What is Continuous Integration (CI)?

Martin Fowler:

"Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily - leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible."

What will you gain?

If you select to use CI, you will have several major benefits:

• The technical benefit - You will never break your build, meaning that your build and thus the compilation of your entire code will always succeed.
• The functional benefit - On every build you will execute your automated tests (e.g. unit tests) meaning that those tests will keep you safe functionally. You will never break something old with something new.
• The immediate release benefit - Once you have the build ready, you can ship your new build version potentially to everyone (e.g. Test, Production).

Of course there are other benefits, but this is powerful practice.

Can I do it half way?

Lets say that you do not have any Unit Tests or other automated tests in your project, does it mean you cannot practice CI?

Well, Unit Tests will keep you safe so you will never break anything and potentially you can be production ready at anytime.

If you do not have any unit tests you will be able to benefit only half of the benefits within CI. Let me explain, lets say that every check in, the build process will be invoked and will insure that technically you are safe. That means that the project will always compile. That is good! You will be able to fix technical integration problems immediately, however you will not be able to release the last check in at any moment since you have no protection, you have no tests to keep you safe.

To sum it up, you get the technical benefit but you will not get the functional benefit and the immediate release benefit.

Is that good enough for you?

Kirill Osenkov from the Visual Studio QA team posted a nice and very detailed post on how to debug crashes and hangs.

This post will get you started on how to debug crashes in windows applications using Visual Studio debugger. I recommend you all to read it... Having said that, I must add that this is a simple example and it will only give you the "getting started" knowledge.

You can read it here.

Here is a quote from a book I am reading now:

"To eliminate the need for a branch entirely, automatically migrate your customers and users to the latest version every time you release."

But wait, was is a branch?

Branch

Simply put, to branch your code is to split the repository into two separate lines of
development. You can branch by release, feature, product and so forth.

Back to the first sentence...

This book I am reading is "The Art Of Agile Development", which talk about, well, Agile and uses XP as an example. One of the sections talk about Version Control. According to the book, there are several rules when practicing Agile in regard to version control, and one of them is Single Codebase. A Single Codebase rule, say that you should have only one copy of your code base.

In other words, Branching is not recommended and we can eliminate it...

So, Is it true? Can we eliminate the need for branch entirely?

My Opinion

I have to say that I am having a hard time excepting this sentence:

"To eliminate the need for a branch entirely, automatically migrate your customers and users to the latest version every time you release."

I believe that the elimination depends on the business. Let me explain by an example. Let say that you sale a service for upgrading your product. A customer can choose whether to buy this service. If a customer does not buy it, you will have to maintain a working version that has its own development lifeline which bug fixes are also apply to it. Yes, I know we have an overhead with the merging the fixes, this still, in my opinion, is the best option you have. Having said that, Agile (XP), has another rule that say "No Bugs". "No Bugs" say that there should not be any bugs in your release...Yep, right!!! We can always strive to achieve "No Bugs", but lets face it, there will always be some bugs...

Summary

To sum things up, I would say that branching is something that derives from the business. Having said that, if the business allows it, Agile (XP) can help eliminating the need for branching.

Have you ever seen this code:

class Program
{
    static void Main(string[] args)
    {
        Person p = new PersonManager().GetPersonById(1);
    }
}

class PersonManager
{
    public List<Person> People { get; set; }

    public PersonManager()
    {
        People = new List<Person>();
    }
    public Person GetPersonById(int id)
    {
        Person res = (from p in People
                   where p.Id == id
                   select p).FirstOrDefault();

        return res;
    }
}

class Person
{
    public int Id { get; set; }
    public string Name { get; set; }
}

Take a look at the GetPersonById method within the PersonManager class. What will be the outcome?

That is right, it can be either NULL or the person object that we found in the list. Now, do not get me wrong, it is not that there is something wrong with this code...It is the fact that we have a design decision to make regarding it that we usually ignore.

The Problem

So, what is the design decision we need to make? As the post title implies, I mean that we need to decide whether objects returned from methods can return as NULL. We have three options when returning objects from a method:

1. The actual value - on success.
2. NULL - on failure.
3. Empty object - on failure.

Option number 2 and 3 are a result of failure to execute the method. In my example, it indicates that the Person was not found in the list.

Now, because we have two options we can select when to use the NULL and when to use the Empty object. This allows each developer to do what he feels like. This can lead to inconsistency in the code. This can lead to bugs...and believe me, there will be bugs.

The Solution

We must make a decision. We need to create a standardization to this issue. I like calling it "NULL Object" decision. Every developer should use the same standard for returning objects from methods. It can be either of the above. Both is fine! But make sure you follow it always. 

How To Decide?

I like my team to help me decide, so I usually gather my team together and hold a discussion. At the end of it, we vote. The result will be our decision. The best time to have this meeting is at the beginning of the development. However, if you are using an Agile methodology, the next iteration is a good candidate.

Brian Randell in his blog announced the released a new set off VPC's for Visual Studio 2008 Team Suite (including TFS).

The VSTS virtual machines are all updated with fresh bits and expiration dates. You now can test and evaluate (since these images are NOT licensed for production use - The new expiration date is December 31, 2009) Team System 2008 with SP1.

What's New?

Two main features are added to this release:

• Visual Studio 2008 Team System Database Edition GDR bits installed. These VPC's provide an easy way to test out the GDR release.
• There is a Virtual PC and Hyper-V based image.

More Info...

According to Brian Randell the new images produced are the same pair as before. A VSTS “all-up” image with Team Foundation Server, Team Build, Team Explorer, and Team Suite. And a TFS “only” image with just Team Foundation Server, Team Build, and Team Explorer.

The difference is that the images produced for both Virtual PC 2007/Virtual Server 2005 R2 compatible images AND Hyper-V compatible images.

Download

• VSTS “all-up” Virtual PC/Virtual Server image (6 GB download, expands to 15 GB)
• TFS “only” Virtual PC/Virtual Server image (3 GB download, expands to 8 GB)
• VSTS “all-up” Hyper-V image (6 GB download, expands to 15 GB)
• TFS “only” Hyper-V image (3 GB download, expands to 8 GB)

Are you looking for coding standards for C# or VB.NET?

If you are, you are in the right place...

(Thanks to my colleague Leonardo Kushnir for the link).

The Document

The purpose of this document is to provide coding style standards for the development of source code written in C# and VB.NET. Adhering to a coding style standard is an industry proven best-practice for making team development more efficient and application maintenance more cost-effective.

While not comprehensive, these guidelines represent the minimum level of standardization expected in the source code of projects written in C# and VB.NET.

Download

So, if you want to check it out, download it here.

This is a ZIP file that contains the C# coding standards and the VB.NET coding standards.

Enjoy!

Buck Hodges from the Team Foundation Server team has recently posted about the release of TFS Branching Guide 2.0 on CodePlex.

The release includes the following:

TFS Branching Guide - Main 2.0

This is the main article which briefly explains branching concepts and introduces 3 levels of the most common branching scenario

TFS Branching Guide - Scenarios 2.0

A collection of less common branching scenarios

TFS Branching Guide - Q&A 2.0

A set of most frequently asked questions with answers

TFS Branching Guide - Drawings 2.0

A set of branching drawings in different formats including a large branching poster

TFS Branching Guide - Labs 2.0

A couple of examples for hands on labs with step by step instruction for practicing the branching scenarios

You can download it here.

These are surely difficult times. Every day we keep hearing of new scandals, corruptions, companies going out of business and so forth. That brings me back seven years, to the year 2001 where companies went out of business, no new investments where made, people got fired and the market collapsed.

Remember? Those were times of uncertainty. Well, its back!

As a company, the management should take care of us the employees. The CEO should steer the boat to the right location. He should keep us safe. This is why he is the captain! So, as a company we put our trust in the CEO...and hopefully he knows what he is doing. My good friend always say:

"Do not worry about things you cannot change"

In a sense, he is right. There is so much one person can do to help a (big) company...so why warring about it?

On times like this, we should sit down and think. We need to think about how to insure our future. What do we bring to the organization / company? Can we improve ourselves? Can we put a little more efforts or contribute more?

This post is aimed to try and explain for you what I do in order to insure that I will be the last one to get fired from my company and the first one to find a new company.

Be The Last One To Be Fired

It is important to mentioned again that this is how I insure my future.

• Be the best you can at what you do - I know this should go with out saying but still I think I should say it. Everyday, try to be your best, don't do shortcuts, in the long run they will hart you. Build expertise on fields that are of values to your organization or to the target customers.
• Be an eager learner - Keep on learning and improving. I am an eager learner. I love new technologies and improving myself. I read over 100 RSS per day, 1 book per month and 1 article per day. Doing so allows me to lead my organization to new directions even though I am not the one to take these decisions. It allows the company to offer new services and etc. It allows the company to deliver better software.
• Be The Go to guy - Strive to be the go to guy. Make everybody know that you are the one they should go to when they have a question or a problem.
• Be a people person - People skills the one of the most important sparks one should have. Being a people person will allow you to know what is going on in the company. It will allow you to gain friends that may help you later.
• Establish Relations - good relations within your organization can help a lot. If you have good relations with your manager, he can back you up when time comes. It can help you progress and so forth.
• Establish a good reputation and make your marks - There is a saying that when a person dies, all that is left is his reputation. Ironically, when a person leaves or get fired from a work place, is much like he died. Try and make everybody to miss you. Try people think and say "we cannot do it without him", "he was good", "he did a good job", "he was an expert". Be the one that everyone thinks that "we cannot do without him". You reputation in the organization and outside it is very important to help you keep you job.
• Contribute to the organization - Find some extra credit tasks you can do and enjoy that will contribute to both the company and yourself. I lecture, help setting events and represent my company at big events on the industry.

Having listed all of the above, that does not guaranty anything. I cannot promise that you will be the last one to be fired, however it will surely help!

The most important thing to remember is that you need to be of big value to your organization. Do you consider yourself as one?

Web Tests supports Data Driven capabilities. Data Driven Web Tests are Web Tests that are bind to a data source in order to use different data throughout the test execution.

An Example

You might record a web test that validates the login process. When you record it, the web test recorder will record the username and password you entered during the recordings. This will allow you to test your application against only a single user - the one that you recorded. However, you would probably want to validate the login test with other users. So you have two options:

1. For each user create a new login test.
2. Use data binding.

The first option is not really an option - so I will not elaborate about it.

The second one is what I call a Data Driven Web Test.

Web Test allows you to add data source to a web test. The Data source can be SQL, XML, and Excel. You can do that by simply create a connection to that data source:

Once you created the data source you can now use it and bind your requests to it.

Data Source Method

The thing I want to talk about is the Access Method to that data source.

When you bind it your can select whether to use:

• Random
• Sequential
• Unique

There is a different definition for each according to the way your test lab is built. Load test supports a single machine (local controller) configuration and Rig (multiple agent machine that generate load) configuration.

Sequential

Single machine - When we select to use sequential, it tells the web test to start with the first row then fetch rows in order from the data source. When it reaches the end of the data source, loop back to the beginning and start again. It will continue until the load test completes.

Rig - This works that same as if you are on single machine. Each agent receives a full copy of the data and each starts with row 1 in the data source. Then each agent will run through each row in the data source and continue looping until the load test completes.

Random

Single Machine - When we select to use random, it tells the test to choose rows at random. Continue until the load test completes.

Rig - This also works the same as if you run the test on one machine. Each agent will receive a full copy of the data source and randomly select rows.

Unique

Single machine - When we select to use unique, it tells the test to start with the first row and fetch rows in order. Once every row is used, stop the web test.

NOTE: If this is the only web test in the load test, then the load test will stop.

Rig – This one works a little differently. Each row in the data source will be used once. So if you have 3 agents, the data will be spread across the 3 agents and no row will be used more than once.

NOTE: Once every row is used, the web test will stop executing.

When you install Team Foundation Server (TFS), you get out of the box two process templates; The CMMI process template and Agile process template.

The great thing about us, the community, is the fact that we all can contribute and help each other. In this case, the community and Microsoft had built together some additional process templates that will allow all type of methodology users to quickly adopt TFS. Extreme Programing, SCRUM are well establish methodologies with lots of fans. It is only natural that someone will create these process templates.

So, I have gathered some process templates that you can download and use for your type of development. However, remember that you can always modify them to best fit your needs:

• MSF Agile v4.2
• MSF CMMI v4.2
• MSF CMMI Process Improvement
• SCRUM
• XP
• Scrumpious

Enjoy!

Visual Studio 2008 introduces a new option called "Extract Web Test" within the Web Test context menu.

This is a cool feature that allows you to extract requests or transactions from a web test and create a new web test. I love this feature mainly because it can save us a lot of time and allow you to modular your tests...Let me explain.

One of the key features we need to strive for is to modular our automated tests. We want to be able to reuse modules or web tests within different tests or scenarios. For instance, think of the following scenario:

Lets say that your application supports two types of roles: Admin and Guest. You want to create a test for admin users scenario and another for guest users scenario. Both need to perform a login.

One option is to "repeat" test request in the admin scenario and in the guest scenario. You will record the login transaction twice, thus there will be twice as much test to maintain and remember that test == code.

Obviously it is wrong. So you would like to extract some requests into a web test and call this new web test from both scenarios. It should look something like this:

First I recorded all the user steps in a single action. The action include the login, the scenario and the logout. Notice: this way, we get the correlation of the parameters working for us.

Next we want to extract the request. Note I use notes to indicate where the login ends.

When we click OK, we get a new test in the solution and the current web test will add a web test call to that new test:

NOTE: When you use the extract option, you will get the parameters correlation and you will inherit all the rules and data sources.

Now keep in mind that it is possible for you to create a test based on other tests. You can achieve that by using the "Add Call To Web Test":

This will help you construct new tests fast and by reusing pieces of tests.

Previously I have posted about Test Driven Development & Visual Studio 2010.

Lisa Feigenbaum from the VB Team published a new post that describes the TDD support with the "Generate From Usage" Feature in VS 2010.

You can read about it here.

J.D Meier recently posted about new application architecture pocket guides.

Agile Architecture Method Pocket Guide

A new guide has been released by the Patterns & Practices team This guide describes an approach for agile architecture design and presents an overview of the approach, explains the main activities and how to adopt them.

Here are the chapters:

• Introduction
• Chapter 1 - Agile Architecture Method
• Chapter 2 - Step 1: Identify Architecture Objectives
• Chapter 3 - Step 2: Identify Key Scenarios
• Chapter 4 - Step 3: Application Overview
• Chapter 5 - Step 4: Key Hot Spots
• Chapter 6 - Step 5: Candidate Solutions
• Chapter 7 - Reviewing Your Architecture
• Chapter 8 - Communicating Your Architecture

You can read the guide here.

Web Application Architecture Pocket Guide

The purpose of the Web Application Architecture Pocket Guide is to improve your effectiveness when building Web applications on the Microsoft platform. It focuses on
partitioning application functionality into layers, components, and services, and walks through
their key design characteristics.

Here are the chapters:

• Chapter 1 - Web Application Architecture
• Chapter 2 - Architecture and Design Guidelines
• Chapter 3 - Presentation Layer Guidelines
• Chapter 4 - Business Layers Guidelines
• Chapter 5 - Data Access Layer Guidelines
• Chapter 6-  Service Layer Guidelines
• Chapter 7 - Communication Guidelines
• Chapter 8 - Deployment Patterns

You can download it here.

Rich Client Application Architecture Pocket Guide

The purpose of the Rich Client Application Architecture Pocket Guide is to improve your
effectiveness when building Rich Client applications on the Microsoft platform. The guide provides design-level guidance for the architecture and design of Rich Client applications built on the .NET Platform.
It focuses on partitioning application functionality into layers, components, and services, and
walks through their key design characteristics.

Here are the chapters:

• Chapter 01 - Rich Client Application Architecture
• Chapter 02 - Architecture and Design Guidelines
• Chapter 03 - Presentation Layer Guidelines
• Chapter 04 - Business Layer Guidelines
• Chapter 05 - Data Access Layer Guidelines
• Chapter 06 - Service Layer Guidelines
• Chapter 07 - Communication Guidelines
• Chapter 08 - Deployment Patterns

You can download it here.

Service Architecture Pocket Guide

The purpose of the Service Architecture Pocket Guide is to improve your effectiveness when
building services on the Microsoft platform. The guide provides design-level guidance for the architecture and design of services built on the .NET Platform. It focuses on partitioning application functionality into layers, components, and services, and walks through their key design characteristics.

Here are the chapters:

• Chapter 01 - Service Architecture
• Chapter 02 - Designing Services
• Chapter 03 - Service Layer Guidelines
• Chapter 04 - Communication Guidelines
• Chapter 05 - Service Layer Checklist

You can download it here.

How would you define success in your software development?

No matter which methodology you use, it can be either Agile or Waterfall or CMMI, they all trying to make you successful in developing you software.

The traditional idea of success is delivery on time, on budget, and according to specification.
A Successful project will be one the is “Completed on time, on budget, with all features and functions as originally specified.” (from The Art Of Agile Development).
When your project is missing with one of the above you might say it is either Challenged or Impaired.

A challenged project will be one that is “Completed and operational but over budget, over the time estimate, [with] fewer features and functions than originally specified” (from The Art Of Agile Development).

An Impaired project will be one that is “Canceled at some point during the development cycle ” (from The Art Of Agile Development).

Having said that, I have met software projects that were challenged but still were successful. That makes you wonder, is there more to success than just meeting deadlines?

I have created for one of my customers, a work item that represents a Test. Within this Test work item, I have created a custom control that implements a Test Story, Test Case, Test Step, Test Run and so on and so forth.

In this post I am not going to go over the Test work item I have created because it deserves a post on its own. For now I will show you a screen shot and will say that it is super cool!

So back to the post in hand, I had to create a custom control. This custom control needed the capability to create a new work item of type Bug, and open it within visual studio.

How To create a work item from a custom control?

First we need to user the IServiceProvider instance that we get when we create a custom control. Since every custom control must inherit from IWorkItemControl it should implement a method:

void SetSite(IServiceProvider serviceProvider);

In this method we get this IServiceProvider instance and we keep it, for example:

public void SetSite(IServiceProvider serviceProvider)
{
    this.serviceProvider = serviceProvider;
}

Where serviceProvider is a field within the custom control. The next thing we need to do is to create a Document Service that will enable us to create a Visual Studio document to populate a work item:

DocumentService docSrv = (DocumentService)serviceProvider.GetService(typeof(DocumentService));

So, now lets create the document:

IWorkItemDocument bugDocument = docSrv.CreateWorkItem(
    workItem.Project.Store.TeamFoundationServer,
    workItem.Project.Name,
    "Bug",
    this) as IWorkItemDocument;

As you can see, I have used the workItem to create a work item document. This is a field we have when we implement the IWorkItemControl:

public object WorkItemDatasource
{
    get
    {
        return workItem;
    }
    set
    {
        workItem = value as WorkItem;
    }
}

Now we have a document ready and all we have left to do is open the document and show it. In order to do so I use the following code:

docSrv.ShowWorkItem(bugDocument);

This is it. Once we executed the ShowWorkItem method, a new bug work item will be open.

When clicking on new bug:

Enjoy!