Team Foundation Server Express

Get Release Management Datas With API REST TFS

Posted on Updated on


Microsoft has released a documentation of the VSTS and TFS integrating REST APIs. In the recent past we were using the client object model and API to interact with TFS. But it was very difficult for client which don’t have .Net Framework installed, and after installation of this later, you must to have Visual Studio, install dependencies on TFS assemblies, know C# …..
Now you can interact with VSTS and TFS via POWERSHELL scripts, or another language, with simple instructions.
It implies also an openness to other technologies and also ease of use.
You specify different HTTP verbs (such as GET, PUT, POST and PATCH) and the connection point to a specific URI (Uniform Resource Identifier) to interact with the API.
In our post we will define the URI of our TFS server, our project collection and also that of the team project.

$UriCollectionProject =  $TFSInstanceURL+"/"+$ProjectCollection+"/_apis/projects?api-version=2.2-preview.1"
$CollectionResponse = Invoke-RestMethod -Method Get -Credential $credential -ContentType application/json -Uri $UriCollectionProject  

When pointing to TFS, you can pass a username and password (masked as a secret variable) through
So we must to add theses lines below

$User = "Aghilas.yakoub"
$Password = "MyPassword" 
$securePassword = $Password | ConvertTo-SecureString -AsPlainText -Force  
$credential = New-Object System.Management.Automation.PSCredential($User, $securePassword)  

Us in this post we will try to list Releases runned by a specific person.
So secondly we will try to retrieve the list of team projects in a collection.
Emeber that a collection contains a set of project and a project contains a set of releases.
Below calling a GET on the URL of the collection.

$UriCollection =  $TFSURL+"/"+$ProjectCollectionName+"/_apis/projects?api-version=2.2-preview.1"
$CollectionResponse = Invoke-RestMethod -Method Get -Credential $credential -ContentType application/json -Uri $UriCollection

$CollectionResponse contains set of team projects.

foreach ($project in $CollectionResponse.value)
{
    $TeamProject= $project.Name 
	….
}

Now in a second time we will try to retrieve the list of release on a team project.
We will use the following suffix: /_apis/release/releases?api-version=2.2-preview.1

Ref : https://www.visualstudio.com/en-us/docs/integrate/api/rm/releases#get-a-release

#Construct URI for query team prpject and his releases
$Uri = $TFSURL +"/"+$ ProjectCollectionName +"/"+$TeamProject+"/_apis/release/releases?api-version=2.2-preview.1"

#Get response of previous uri
$releaseresponse = Invoke-RestMethod -Method Get -Credential $credential -ContentType application/json -Uri $Uri 

Now we must just get created releases by Aghilas


    foreach ($releaseInstance in $releaseresponse.value)
    { 
	If($releaseInstance.createdBy –eq “Aghilas”)
	{
             ......
        } 
    }

GC.Collect

Advertisements

Package and publish your extension TFS 2015 VNEXT

Posted on Updated on


In order apeak about solution , we explain just that we have two aspects to setup, packaging and publishing, we begin with our sample with packaging.

  • PACKAGING View

For the packaging we follow steps below in order to construct our package, the result of this step is vsix file.

1. Setup Node.js

2. Install vset tool with this command : npm install vset –save-dev

vnext12

3. Run Node.js command prompt tool (C:\Windows\System32\cmd.exe /k “C:\Program Files (x86)\nodejs\nodevars.bat”)

4. Locate you on directory of your extension

5. Run vset package command

vnext13

Your vsix is generated into your root irectory

vnext13

For information you can inspect content of your extension, by unzip your vsix

vnext15

  • PUBLISHING View

Before publish our extension it’s possible to visit differents extension avaiable on the cloud, it’s possible to download and install on premise version of tfs, in order to reuse.

We choose to publish our expansion on the market place on Azure

We follow theses steps, firstly we create a publisher, secondly

1. Go to https://marketplace.visualstudio.com/manage/publishers/
2. Choose to create a publisher by completing a unique Id

vnext10
After that
vnext9
3. Upload your extension by drag and drop your vsix
vnext11

4. Correct and adapt your manifest information

vnext16

5. Now it’s ok and my vsix is downloaded

vnext17

6. Share my extension on my account azure, an it’s possible to update my version on clickin on update button
vnext18

vnext19

7. Go to admin tfs section, and selection extension tab, clck on my extension target

vnext19

vnext20

8. On Build VNEXT find my created extension

vnext21

Branching By Feature – Team Foundation Server

Posted on Updated on


We have several strategies branching, Foncton life cycle of the product, the number of people, delivery mode etc.
We can mention: Release Management or CodePromotion ..
the objective of this bill is to address one of the most complex, it is the featuring.

Context

An application may include multiple versions while having active or corrective maintenance needs. How to do ?

Parallel developments can be implemented by several teams. How a team without negatively impacting the other?

=> Set up branches developments

However it is essential to establish a branch management policy to avoid manage conflicting versions during development, to prohibit changes to the validated versions etc.

Setting up

The installation requires performing the following tasks:

1. Create a development trunk, the trunk is denominated XYZ

Note: the developments are not directly on the trunk, but are on a child branch called Service Pack.

2. Create from a new branch trunk daughter Service Pack denominated 1.YZ

Note: this branch will host the developments dedicated to the first feature.

Event Project: End of the first iteration (The development team estimates that the developments are completed).

3. Create from Service Pack 1.YZ a new child branch Fix denominated 1.0.Z.

Note: This branch contains all the developments dedicated to future bug fixes following the delivery of the target functionality.

4. Create From Fix 1.0.Z. a new child branch Release, 1.0.0 wording.

Note :

-This Branch will remain read-only.

-This Branch is the only branch deployed in production environment.

-This Branch represents an image of our delivery.

It makes it possible to trace the different deliveries made.

-It Allows for Rollback operations on version if the need arises (Avoid version conflicts files).

Event Project: Delivery of production

5. Deliver the branch Release 1.0.0 on the production environment.

6. Merge Service Pack 1.YZ to XYZ trunk

Note: At this stage all branches are at the same level of evolution.

Event Project: Bugs occurs on the Release 1.0.0

7. Treatment of bugs can be done in two ways as possible:

Judging that the version is not stable
-Conduct Fixes on Fix branch 1.0.Z.

-Create A new branch Release 1.0.1

-Livrer The Release 1.0.1 branch

-Fusionner Fix 1.0.Z to Service Pack 1.Y.Z.

-Fusionner Service Pack 1.Y.Z. to X.Y.Z. trunk

Note: You can iterate many times: 1.0,1, 1.0.2, 1.0.3 etc.

Judging that the version is stable and it is decided to fix bugs on a new delivery.
-Create From Service Pack 1.Y.Z. Fix a new child branch 1.1.Z

-Apporter Fixes on Fix branch 1.1.Z

-Create From Fix 1.1.Z. a new child branch Release, 1.1.0 wording.

-Livrer 1.1.0 branch

Event Project: An important new feature arrives

8. Create from the trunk a new child branch service pack, label 2.YZ

Reproduce the same organization …

Implementation in Team Foundation Server 11

Add the solution to Source Control