Demystifying TFS Project Collections and Projects

Team Foundation Server has been a reliable tool for projects across organizations.  On One hand wherein it might be thought as a Configuration Management Tool, It actually is a complete Application life cycle Management(ALM) tool. With the advent of Visual Studio Online, It is now possible to have free instance of TFS in the Cloud.  However, working with TFS has its own architecture and hence the tips and tricks.

TFS has an architecture that Underneath the installation of TFS, there are project collections. Under one Project Collection, there can be Several projects and under the project we have the teams working together.

Project Collection can better understood as Account or Department. For. eg. one Line of Business in an Organization is Banking. We would create Project Collection called Banking and  underneath it all the Projects of banking would be created.   The basis need of Project Collection is to isolate the data among different project collections.

Projects vary according to the Lifecycle of the projects.  Thereby, TFS provides us with three different Process templates viz.

1. CMMI Template

2. Agile Template

3. Scrum Template

These templates can be adopted on the basis of the Lifecycle and Model of the Project.

In case the Project Lifecycle is based on CMMI which can be thought similar to Waterfall Model, then the Process template for CMMI is used.

Agile methodology for Sprints is Supported by the Agile Template.  This is best suited for development projects.

Agile Methodology for Kanban is supported by Scrum Template.  This is best suited for maintenance projects.


Thus this was a jist of the Project Collection and projects and process templates in TFS.

DevOps using VSTS 2013

The World in this century is moving very fast and especially software Development. The advent of Social Media has further made this complicated, as the Customer Expectation as well as Interactions is Intense. An increased focus of User Experience and Expectation for Quicker Change implementation is evident. The changes here include both the changes proposed by the Customers as well as the changes, which the process requires such as the process itself being flexible enough to be changed quickly. The traditional development practices are unable to cater to such a massive change in the Mind-set and Expectations. Another important aspect to deal with is the performance of the Applications should be competitive so that it leads to an actual adoption of the software product.  

With all these challenges in place, any change in the process becomes next to impossible, as there are barriers to adoption.

This need of rapid delivery applies to both type of projects which are in Development or which are in Operations. In projects which are in Development, the changes are frequent as well as the deadlines are aggressive.  Any changes in the later phases can pose serious threats to successful delivery. In Operations, there is a strong concern of introducing minimum changes. Although the changes are less, however they need to checked rigorously that they should not hamper the existing product being used by Customer on a daily basis. Further, the change should be quick and prompt as per customer expectation. These demand a complete revamp in the process as well as the mind-set to own such a process, which did not exist before.

Some of the Critical Questions in Industry regarding to this are:

•           How can we Release on time and in less time?
• 
  
•      Is there a way in which the Operations are happy to have frequent changes?
• 
  
•         Is it Possible to Deploy Simultaneously and frequently on multiple Servers?
• 
  
•         Can we Develop and Test in Parallel in as Good as Production Environment?
• 
  
•         Is there a way to avoid last minute surprises aka Pandora’s Box?
• 
  
•          How can we perpetually reduce IT Costs and control any effort or resource wastage?
• 
  
•         I have adopted agile practices.  How can I Extend them further?
• 
  

And, the List goes on. The Solution to the above problems is by implementing DevOps.

DevOps is not about technology, but a cultural phenomenon. Hence, it is important to communicate effectively with the IT and delivery teams. Building Such DevOps Culture would require a top down approach in organization where leaders would lead by example so that the flow is imbibed all across. This can be more effective with enablers such as Continuous Delivery and Continuous Testing. 

Continuous Delivery employs Continuous Integration. It also demands the use of agile and lean principles across the Software Delivery chain. This means that the speed of Delivery with an equal focus on quality should be there from Inception to production release and Customer Satisfaction.

It is the need of this hour where commitments to ship reliable deliveries is even stronger. DevOps can be implemented using Team Foundation Server effectively. TFS allows us to construct a release pipeline to implement DevOps. Since Visual Studio 2012, there has an increased focus on Combined Engineering and DevOps. The following features employ quicker implementation of DevOps using TFS:

1.       Creating Product Backlog – DevOps needs interaction of all the stakeholders like Business Analysts, Testers and Developers on a frequent basis so that we can implement changes. To start with this, we need a product backlog ready and accessible to all. This enables us to know what all is pending and to be dealt with. TFS in the enhancement after VS 2012 introduced the enhanced templates for Scrum as well as Agile processes.  These are specifically designed to optimally create product backlog.

Additionally, the Kanban board is of great importance to visualize the Progress in a centralized manner across all the Stakeholders. Board in TFS allows us to implement this across phases and stages.  The communication is loud and clear so that there is no gap in understanding of teams.

Customization of stages supports the lean thinking and changing the process easily and efficiently leads to Continuous Improvement.

An important aspect of this is to avoid any kind of Over Development or Under Development.  Hence, anomalies are critically analysed in the Initial Phase by multiple Stakeholders. This supports the cultural movement as required in DevOps as there is complete collaboration as well as Visibility to evaluate the adoption amongst teams.

2.       Building a Release workflow: Continuous Integration, Continuous Testing and Continuous Delivery are pillars required for DevOps implementation.  Furthermore, whatever can be and thereby should be automated. This would allow minimum hindrance to the Process Changes and would rather facilitate it.

“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. An automated build (including test) to detect integration errors as quickly as possible verifies each integration. Many teams find that this approach leads to significantly reduced integration problems and allows a team to develop cohesive software more rapidly.”  - Martin Fowler

TFS has the provision for implementing Continuous Integration by customizing the Build Definitions.  It heavily relies on Build only Once strategy. This in simple words means that once a Developer checks in code that the Code is built simultaneously to check that the code submitted by the Developer is not interfering with the existing code. In case there are errors, the Code check-in is unsuccessful.   This further is an automated process.

The Next Step to this is to have Simultaneous deployments across multiple environments.  This again is automated depending on the Success of Previous Step. Along with this data for monitoring this is gathered to closely watch the success per stage.  DevOps Workbench express allows us to create Orchestrations.  This has support for multiple Microsoft Technologies including SharePoint, MSSQL, Azure, .NET Applications, ASP.Net Applications. We can create Deployment Orchestrations for performing different Steps in order to enable Continuous Integration and Delivery.

Creating this kind of a Build workflow is a complex activity. To reduce this complexity, DevOps Workbench Express is a rescue. Such Customized orchestrations aka Build Definitions can be readily used to create the Build Pipeline using this.

Until now, we have an orchestration to handle Building the Source Code and deploying it to target environments simultaneously. The Next Big Step is to adhere to Continuous Testing. Unit Test is effective to do this. Employing Automated BVT in the form of Unit Tests can sanitize a Build. Any failure of the tests would lead to subsequent rollback of the build and thereby ascertain fool proof Regression Testing. This necessarily is automated and automatically triggered with a build. Using Visual Studio 2013, we create unit tests and add them to the project so that they are automatically invoked with the build using some basic Settings in the build definition.

Unit Test Generator is as Add on for VS 2015 and provides facility to quickly add unit tests. These Unit tests are tightly couple to the projects and are an efficient mechanism to maintain regression testing. Continuous testing can be achieved by this.

4.       Continuous Monitoring: We all want progress, but if we are on the wrong road, progress means doing an about-turn and walking back to the right road; in that case, the man who turns back soonest is the most progressive. Continuous monitoring thereby becomes extremely important to identify issues and act upon them at the earliest.

TFS provides reports at various levels to cater these needs. Some of these reports for constant monitoring are:

a.       Project Management Dashboard

b.      Progress Dashboard

c.       Quality Dashboard

d.      Test Dashboard

e.      Bug Dashboard

f.        Build Quality Indicator Reports

g.       Bug Backlog Reports

h.      Burn down and Burn Rate Reports

Using these reports provides a holistic approach with complete end to end visibility for all the stakeholders.

Having said all of this, it should be clearly understood that enablers to change could only help if the DevOps culture is in place. Leads of the organization must stress on the implementation of such culture and should be open to feedback for further process improvement. It Might take time to adopt this but the results are very satisfactory.

To Sum it up, the following are the vital benefits of DevOps:

      Minimized Conflicts between Development and Operations

      Greater Scale ability and Flexibility in Process Implementation

      Collaborative and Integrated Development among st Teams

      Frequent and Faster time to Delivery

      More Stable and reliable Releases

      Continuous Monitoring for Complete Visibility across Stakeholders

      Reduced Outages and minimal errors to Operations

Hence, these are the steps for Implementing DevOps using TFS 2013.

Coded UI Test - A Basic Overview

Coded UI is a  User Interface Automation tool provided By Microsoft. This tool has enormous potential of automating Web. Windows and WPF applications. Open Source Tools like Selenium and others are incapable of automating applications such as windows and WPF. Especially wrt to WPF, as it is a  Microsoft Technology, the support provided for WPF by Microsoft is awesome.  The same applies for Window forms and other similar Microsoft Products and their user interface.

Lets Look at How to Create a Coded UI Test using Visual Studio 2013.  The sample Application under test(AUT) is the popular Calculator Application which is a WPF Application.

In Order to Create a Coded UI Test in Visual Studio we need to Create a Project of the Type Test and Coded UI Test project.

Once the Project has been Created Successfully, we  see a pop up on the Screen which asks whether would like to Record actions, edit UI Map or add assertions.

We will Click on Ok Button Keeping the first radio Button Selected. On Clicking Ok, the Visual Studio Minimizes and a new panel appears on the lower right part of the Screen with some buttons.
The buttons that are displayed are: Start recording, Add a New Control and Generate Code.

We Would now Select the Red Button and then work on the AUT for some actions and then pause the Recording.  The Action that has been performed here in this example is that we Press '2', Press '+' , Press '3' and at the end Press the Sign '='.

After this , we need to click on Generate Code Button. It asks for the recording name. We ll provide some Logical Name to this Step.

After Adding this, we refer back to the Coded UI Test Builder and Close it.  We now have the CodedUI Test project in front of us. Double Click on the UIMap.uitest file.

Now here, we See two Sections: Actions Panel and the Control map Panel.

The Actions Panel displays the Steps that have been performed.

The Control Map Panel displays the property of Controls that Have been Captured.

These Sections can be further optimized so that we  can have the best of the Benefits from the Coded UI Test. Here, another information which is vital is to understand the anatomy of the UIMap file.

The UiMap File consists of the following three files:

• UIMap.uitest:  This is internally an XML File which contains the property of all the Controls.  This can be also Understood as the Object Repository
• UiMap.cs:  This is a Class file which initially is and empty Class. This is a placeholder to put the code which the User would like to add as an addition to what Coded UI Itself provides.
• UIMap.designer.cs: This is a class file automatically generated by Coded UI and is a C# implementation of the UIMap.uitest file.

In Addition to this, the UImap.cs as well as UIMap.designer.cs are partia; classes.  As such they combine together to complete the class.

With this much of knowledge about the files, lets See how they Look like:

UIMap.uitest file

UIMap.cs file

UIMap.designer.cs file

It is advisable to edit the UIMap.uitest file for changing the properties of the objects.  Also, no changes should be made in the UIMap.designer.cs file.  All changes on this file are overwritten and hence editing this file is strictly not to be done.

The UiMap.uitest file can be easily tweaked using the UIMap Tool Box which can be downloaded from the Visual Studio Gallery at the following Location:

UIMapToolBox

With the help of this tool, we can restructure the UImap with minimal effort and by simply drag and drop. Once we do the changes to the UIMap.uitest file, remember to save it and regenerate the Map using the Coded UI Test Builder.  After making changes to the Map file, it is recommended to Locate all the elements so as to see that the changes have not impacted the Map and all controls are recognized.

The following Snapshot shows the Updated UIMap After changing it using UIMap ToolBox

The Next Step is to Move the Code from the UIMap.Designer.cs to UIMap.cs for greater Control over the Steps.  To perform this, We need to refer to the Actions Panel and then click on the root Note for the recorded Step.   This Gives us an Option to Move Code to UIMap.cs.  On clicking on this button a Disclaimer comes and we should agree to it.

On Moving the Code, the following is the snapshot of UIMap.cs.  We should remove any mention of point in the Statements if the actions are not Specific to some coordinates on the Screen.

It is also important to know how to View the properties of the Controls.  For this, we need to go to the UI Control Map Panel -->  click on any Control --> Select any node --> Press F4.

The Next Steps is to Goto the Test and the test is written in the CodedUITest1.cs file. Lets Rename this File to Arithmetic.cs.  The Next Step is to see the Attributes on the Screen.  They are:

1. TestMethod - This is a placeholder where the tests are actually written.  VS recognizes these as valid test methods

2. TestInitialize - In case, there are some prerequisites to be run prior to the execution of all test methods within a class, then the section test initialize is used. An example of such activity would be to cleanup Browser Cookies and Cache.

3. TestCleanup - In case, there are some Post requisites to be run after the execution of all test methods within a class, then the section test cleanup is used. An example of such activity would be to cleanup Browser Cookies and Cache.

Few Others which are not mentioned by default but are present are:

4. ClassInitialize - This is a placeholder to specify certain actions which needs to be performed on a class level. Such Actions would be invoked once a class is initialized and not upon every test method.  An example of Such Actions would be Closing all instances of Browser and Opening an IE instance.

5. ClassCleanup - This is a placeholder to  specify certain actions which needs to be performed on a class level. Such Actions would be invoked once a class is initialized and not upon every test method.  An example of Such Actions would be Closing all instances of Browser.

6. AssemblyInitialize - This is a placeholder for actions to be done on an assembly level during start when the assembly is loaded.

7. AssemblyCleanup - This is a placeholder for actions to be done on an assembly level when the Solution is completely executed.

These were few of the attributes which were important to be known.  Now lets, get back to the Test.  here the name of the Test is Addition and the test would look like this.

In order to execute this test, the best way is to execute it through the Test Explorer.  The Test Explorer can be Viewed from Visual Studio --> Test --> Windows --> Test Explorer

On Clicking on Test Explorer, the Test Explorer opens up with all the Test Loaded into it.  Right Click on any of the test and click on Run.  This would execute the test case.  The following example shows the execution of test case.

Hence, This was an illustration on how to create a basic Coded UI Test with the example of the Calculator application.