The correct way to promote a Branch:

Steps in Order:

1. Check in your changes to your branch.
2. “Forward Integrate” the Parent Trunk’s latest changes down into your branch with a TFS Merge.
3. Resolve FI Merge conflicts and check-in changes to your Branch
4. Re-stabilize, reconfirming features.
5. Check in your changes to your branch.
6. “Reverse Integrate” your Branch into the Parent Trunk using TFS Merge
7. Resolve RI Merge conflicts
8. Check-in Parent Trunk

Verify:

Use TFS Comparison tool to Verify that Branch and Trunk are identical after these steps.

If they are not, use Merge tool from Command Line with /force parameter. (make sure you use the correct switches)

(FI) Forward Integration

The pull the Base Project source down to a branch using Merge.

(RI) Reverse Integration

Promote Base Branch changes into the Parent Trunk

The observer pattern has played a key role in all aspects of Object Oriented Development. The key purpose of this pattern is to allow a Model to focus completely on State Management without being forced to deal with details involved with the usage of the Model’s Data.

This offers Code Isolation to the lowly Model (Business Object) Developer, and well as promotes an endlessly rich landscape of ‘Views’ which may bind to the State of the Model to do what they please.

Recently, as Service Oriented Architectural Patterns have graduated into Duplex-Style client interaction, Views for many Business Layers are slowly becoming more unpredictable at the time of crafting a solution.

For instance, it is common in an Enterprise Environment for a Business Layer to Manage a Global State while Rich Internet, WinForm, Mac, Mobile, and Terminal Clients all interact with the Model seamlessly across Platform Agnostic Service Tiers.

With this in mind, the Observer Pattern can be used initially to as a layer of Abstraction and Control between the Model and its View.

Goals to creating Models Independent of Views:

• Model has the ability to Update View on demand
• Model has no knowledge of how data is being used in a View
• No View has any knowledge of other Composite Views Observing the same Model

The Details of the Pattern

Define an IObservable and IObserver interface:

Above, the IObservable Interface defines the scaffolding for an Observable Model. A Model will be able to accept Entry/Exit from a View implementing IObserver.

There are three important features made available by defining these interfaces:

1. The IObservable Interface defines a specification for Registering and Unregistering Observers. Since the Observers are Abstracted behind a IObserver Interface, the IObserverable Concrete Implementation is independent of the number of Observering Instances.
2. The IObservable Concrete implementation maintains the Observers instances within its own State. This allows the Model to activate “NotifyObservers” whereby the current state of the model can be passed down to each individual view to trigger DataBinding
3. The View does not communicate to the Model, and thus has no knowledge, nor control, of any other view.

Under the hood, what the interfaces do not show, is that the typical implementation of the NotifyObservers Method on the IObservable Instance will iterate through all of its IObserver Views calling Update, passing calling Model’s State as the parameter.

Observer Pattern Geospatial Example

A example of this pattern can be seen geospatially with a Movie Theater scenario where many patrons have the ability to claim that they can See, or not See, the screen given the position of the curtain:

Given that the instance of TheatreScreen is a real movie theatre, the Left Curtain is either Open or Closed. If two patrons are created sitting on the farthest sides of the theatre, each one will be effected independently based on the curtains position.

The Observation of the being able to see from the perspective of a single patron is mutually exclusive of Observations of other viewers.

When the Curtain State Changes, the Model is in charge of informing, in this case visually, that they need to reevaluate their ability to clearly see the screen. The Model does this through NotifyObservers, where each View’s Update method is called with the Models current state passed as the paramter.

Each patron, on the receiving end, will simply wait for Update to be called with the most recent Model State.

If your an agile developer you have probably heard, in passing at least, about the Feature Crew Model of Project Management and Source Control. Even if the literal phrase has not arisen, the concepts might be those that you have been naturally perfecting your Release Pipeline towards.

What is A Feature Crew?

A feature crew is a small interdisciplinary team responsible for producing a feature.

Teams can range from 2-50 developers often assembled based on Skills related to the feature set which is to be worked during an iteration of the Development Lifecycle.

What is A Feature?

A Feature is a set of Bug Changes, Enhancements, or Refactoring tasks that have a strong enough relationship to be considered as a Group, or Category, of Code Updates.

Designing Feature-Sets are a key task, since the ability to Prune/Add Features to a Release depends on how the changes are bundled.

To offer the required Flexibility of Feature Selection for a small Agile Team, consider the following:

• The larger the feature set, the harder it will be to Design, Develop, Document, Integrate, QA, and Release.
• The more dependencies a feature set contains, the more difficult it will be to stabilize Build Quality on Release
• Larger Feature-Sets are more prone to Re-iteration between Development and Staging since the entire Code Set has to be Modified, Stabilized and Retested if QA finds a bug within any of the Sets requirements.

Practical Example of a Feature Set:

1. Bug #2234 Update input Validation for Application View

2. Enhancement #455 Add new Input Field for Address in Application View

3. Refactor Task Clean up code that handles Validation in Application View

 

Why Group Code Changes into a Feature Set?

Within the Agile Development Lifecycle, all code changes, no matter how minor, should pass through a series of well defined steps:

• Requirements Gathering
• Design
• Development
• Integration
• Quality Assurance
• Documentation
• Promotion

Using the Feature Set Model, an initial estimate can be claimed based on Design/Development complexity. Then, once the Feature Set has been deemed ‘solid’ by the developer, an Integration/QA/Promotion estimate for that Feature Group can be communicated back to the business to solidify Release Estimates.

Pros:

• The business will never guarantee a Feature related to an upcoming release until the developer has stabilized the Design/Implementation
• Release Estimation for completed Feature Sets will be only an estimation of Integration Tasks, as well as QA Time, which tends to be much more predictable that Design/Development Time
• Feature-sets are disconnected from a Specific Release Number, which allows the business to weigh the risk of promoting a Development Stabilized Feature Set
• Stabilizing a QA Environment is really easy if Regression Tests are focused on incremental Bundles of Features. It is simple roll-out/back a Feature Set Bundle without compromising the existing integrity of the Product.

Cons:

• Features with pre-requisites of other Feature Sets are hard to keep track of
• The granularity of How the Feature is Grouped defines the flexibility of Promotion

Why use the Feature Crew Model?

• The business does not ever promise a solution that has not been developed
• Estimates are more accurate since Design/Development Time is usually the most complex
• Allows separation of concerns for Bundled Feature-Set Promotion
• Isolates Development, Main (QA), and Production source actions to a series of clear, role restrictive, Forward/Reverse Integration Steps.
• QA focuses on Regression Testing, not Development Integration Tasks.

The Source Control Model

The following is an example of a Small Agile Team’s Feature Crew Source Model. Each Node within the model represents a Branched Code Base that retains the Forward/Backwards Merge relationships with its Source/Destinations Branches.

• Team-Dev – Team Integration Environment (Stabilize Promotion to QA)
• Feature 0 – Feature Crew Work Branch
• Feature 1 - Feature Crew Work Branch
• …
• Main – Quality Assurance Environment (Stabilize Promotion to Release)
• Maintenance – Release HotFix Environment (Stabilize Release Patches)
• Fix 0 – Hotfix Work Branch
• Fix 1 – Patch Work Branch
• …
• Release – Production Environment (Create MSI, Package for Distribution)

The Maintenance Branch

Often in the real world, Legacy Releases are treated with priority for a business. This makes the Release Pipeline difficult to manage if the TeamDev and Main (QA) Branch, for instance, are have been stabilized for an upcoming release.

Although the Feature Crew Model does not offer Total Coverage in the area of a maintenance release, it does allow an accelerated turn-around. Fixes can be maintained beneath the main Maintenance Trunk, Integration Stabilization and QA both happen in the same environment as well.

This type of Maintenance Pattern does, bottom line, open opportunities for Hotfix code to clobber your existing Business Requirements.

Rule of Thumb for Maintenance Branch:

• If you are accelerating Hotfixes out often, you need to bundle the changes for a new release
• If the code-change covers so many areas that a limited regression test will possibly lower the quality of the application, bundle the changes for a new release

The Feature Crew Life-Cycle

1. The business communicates requirements to Team on a congealing SCRUM-Style Work Item list.  Requirements are sorted by priority Descending
• [example dashboard view]
2. Developers add rough estimates for Design/Development Time to Work Items. *Exclude all other
3. steps of lifecycle from this estimate
4. Team/Business have a meeting to decide how to re-order the Dashboard with Development Specs included.
5. Team groups priority Work Items into Feature Sets in a Feature List
• [Example feature set view]
6. Developers complete Work Items on each feature set over period of estimated time.
• If Feature Set is completed in estimated time, an Integration/QA/Doc Estimate is added to the Stabilized Feature
• If Feature Set is not completed, new development estimate is added.
7. Team/Business have a meeting, focusing on the updated Feature Sets in a Feature List
• If amount of completed Feature Set’s can offer enough quality to Update the Product, the Team/Business commit to a Release Timeline based on Integration/QA/Doc Estimates.
• If there are not enough Stabilized Feature Sets to promote a Better Quality Product, the Team goes back to the development phase.
8. Approved-For-Release Feature Sets are Integrated and Stabilized in the Team-Dev Trunk; this is valid if you have multiple features planed for a single push.
9. Merge task between TeamDev promoting Feature Changes into Main (QA)
10. QA Testing begins on Main Codebase.
• If QA Finds a Feature Set that does not meet ALL of the intended requirements, the ENTIRE FEATURE SET is rolled-out of the Main Trunk. Developers fix issues in the Feature Branch, but do not update Main.
• QA Testing does not stop if a single Feature Set fails validation. This allows the product to claim a Quality which, in many cases, is acceptably better with a known feature bug than a faulty Product.
11. At end of QA Testing, intended Feature-Set-Complete or not,  the business weighs if the Quality of the Build is acceptable.
• If the Build is not acceptable, the release time-line is extended based on an estimate for Feature Fixes
12. Upon Quality Acceptance, Merge task takes place between Main (QA) trunk and the Release Trunk.
13. Setup Engineer works on getting the MSI/ClickOnce/WebSite out the door.

A diagram to explain the process in detail:

Conclusion

The Feature Crew Source Control Model is designed with a few issues in mind:

• Code Isolation
• Build, Development, Test, and Release Tasks should never have knowledge of the other environments of the Development Lifecycle
• Clear Promotion Path
• Promotion from Development to Stage, or Stage to Release is a single Merge task that only a restricted set of user can execute
• Promotion is Associate, Machine, independent
• Forward & Backward Merge Relationships
• Ability to Promote Forward, Backwards using Source Merge Tools
• Unlimited Feature Development
• Features are disconnected from any specific Release.
• The Business can choose which Developed Features it feels can be Integrated based on the Release Timeline.

The clear advantages are that:

• A Business Release Date is not set until the development has already taken place
• Team Integration, QA, and Documentation do not begin until the Solution has been developed and stabilized
• Estimates are broken into two broad groups (Design/Development, and Integration/QA/Documentation) which will increase the accuracy of a the prediction

The XPS FixedDocument could become the new standard in portable documents. We just need few developer’s to build a strong API and get Microsoft to ramp up!

In the meantime, here is a little help on Printing your [Fixed/Flow]Document:

Creating a Document

First of all, you must create a Package before a document can come into play. This is not clear, since the XPS API has been updated between the Beta, 3.0, and 3.5 release.

Here is one of the most common examples online (http://www.ericsink.com/wpf3d/B_Printing.html):

   1: public static void PrintXPS(FixedDocument doc)

   2: {

   3:     string tempPath = "";

   4:     try

   5:     {

   6:         tempPath = System.IO.Path.GetTempFileName();

   7:         Package package = Package.Open(tempPath);

   8:         XpsDocument xpsd = new XpsDocument(package);

   9:         XpsDocumentWriter xw = XpsDocument.CreateXpsDocumentWriter(xpsd);

  10:         xw.Write(doc);

  11:         xpsd.Close();

  12:  

  13:         PrintXPS(tempPath); 

  14:     }

  15:     finally

  16:     {

  17:         if (tempPath.Length > 0)

  18:             System.IO.File.Delete(tempPath);

  19:     }

  20: }

Of course, this now throws: Archive file cannot be size 0.

Digging through the XPSCreate Sample shows a quick workaround:

Excert from XpsCreate.cs in XpsCreate Sample Provided by MS:

   1: if (File.Exists(packageName))

   2:     File.Delete(packageName);

   3:  

   4: // Create an XpsDocument package (without PrintTicket).

   5: using (Package package = Package.Open(packageName))

   6: {

   7:     XpsDocument xpsDocument = new XpsDocument(package);

   8:  

   9:     // Add the package content (false=without PrintTicket).

  10:     AddPackageContent(xpsDocument, false);

  11:  

  12:     // Close the package.

  13:     xpsDocument.Close();

  14: }

Integrating this back into our code, we have:

   1: tempPath = System.IO.Path.GetTempFileName() + ".xps";

   2: Package package = Package.Open(tempPath);

   3: XpsDocument xpsd = new XpsDocument(package);

   4: XpsDocumentWriter xw = XpsDocument.CreateXpsDocumentWriter(xpsd);

   5: xw.Write(doc);

   6: xpsd.Close();

   7:  

   8: PrintXPS(tempPath); 

Its that simple!

Lets flex our WPF Muscles and figure out how to render a list of Images:

   1: <ListBox Grid.Row="1" Grid.Column="0" Grid.ColumnSpan="2" Name="ImagePanel" ScrollViewer.HorizontalScrollBarVisibility="Disabled">

   2:     <ListBox.ItemsPanel>

   3:         <ItemsPanelTemplate>

   4:             <WrapPanel />

   5:         </ItemsPanelTemplate>

   6:     </ListBox.ItemsPanel>

   7:     <ListBox.ItemTemplate>

   8:         <DataTemplate>

   9:             <TextBlock Text="{Binding ContextKey}" Width="100" />

  10:         </DataTemplate>

  11:     </ListBox.ItemTemplate>

  12:  </ListBox>

Notice, The System.Windows.DataTemplate requires us to set the width on the item in order to allow ‘line breaks’ where we want them. Otherwise, we will just get a ton of items running off the view.

The above code manufactures this view:

There are a few theories about using System.Windows.Data.RelativeSource to target the WrapPanel’s Width:

   1: <ListBox.ItemsPanel>

   2:     <ItemsPanelTemplate>

   3:        <WrapPanel Width="{Binding ActualWidth,
   4:             RelativeSource={RelativeSource Mode=FindAncestor,     

   5:             AncestorType={x:Type ScrollContentPresenter}, AncestorLevel=1}}" />

   6:     </ItemsPanelTemplate>

   7: </ListBox.ItemsPanel>

Silverlight has its limitations.

For one, the Silverlight Unit Test framework (ScottGu), although beautifully built, does not integrate well into any performance tuning harnesses. Out-of-the-box you get an export provider that meets the requirements to import into the VS.NET 2008 Performance Analyzer. This opens up the path to doing Line-Item Comparisons between benchmark sessions. But, the process of testing your Silverlight application, importing into VS.NET, and Comparing is kind of painful.

Another problem is Microsoft’s Expectation that minor Applications, like Widgets and Streaming Video, are the primary usage of the semi-portable framework. But, what about HTML Interpreter, Spreadsheet Engines, Peer-to-Peer collaboration (using the nifty Duplex features). What is the use of client side processing if you cannot get a myriad of little muscles to do the lifting?

So, how do we utilize the existing VS.NET Tools to run benchmarks on Silverlight Projects?

Create a Class Library to house the Model that uses the Compiler Directive to check for the SILVERLIGHT flag.

Public Sub DoWork() Implements IWorkHarness.DoWork        

System.Threading.Thread.Sleep(5)

#If SILVERLIGHT Then        

System.Threading.Thread.Sleep(10)

#End If    

End Sub

Then, create an additional Project in WPF that will link the files over for compilation.

Example:

1. Create Silverlight Class Library

2. Throw together your Implementation with the Bridge Pattern, knowing that some items are not supported in WPF. Remove all of your dependencies on the SL Framework out as far as you can away from the Model. Inheriting/Implementing any Silverlight features should exist only at the concrete level aside fundamental types like System.Object. Generally, the Bridge Pattern was built just for this type of situation: Silverlight is a subset of WPF; common objects can be used to define your Model/Controllers while all real ‘Flavor’ specific items can be added via dependency injection. So, feel free to use System.Object, and other fundamental types. Rule of Thumb: If you have to add any new Framework DLLs to your Default Project Imports, there is a good chance the item contains something that is not supported in WPF. Feel free to use a tool like Reflector, try the File Dissassembler Add-in, on the Core Silverlight Framework DLLs to extract your interfaces. (that may be faster in some scenarios than using the Object Browser

3.Create WPF Class Library. This will be our WPF Skeleton to represent our project.

4. Right Click on WPF Class Library Project and select Add->Existing Item. Then, Search for all *.vb/*.cs files in your Silverlight Libraries Project Folder

5. Select all code files, Drop Down Add Button and select “Add as Link”

6.Create Application Fixture to mount Performance Analysis Tool. Add the WPF Class Library Skeleton as a reference In the application, create a Class/Method to define the workload Implement any necessary concrete types that are specific to the WPF Framework Flavor

7.Use Analyze Menu Option in VS.NET to tune