I am exploring Release Management 2013 from the continuous deployment point of view. While creating release template and adding actions I came across some scenarios and have queries on the same.
1) Can I add conditions such as if-else style to the deployment sequence while creating a workflow for release template? I have not seen any default action for this.
2) Can I get the return value/code of a process/action and based on it perform the suitable action for subsequent action in the flow or use it as an argument in subsequent flow?
I'm the program manager for VSTS Release Management. My recommendation is to use the new Release Management capabilities in TFS 2015 U2 or Visual Studio Team Services feature.
It supports both your asks #1 conditionals on steps and #2. ability to set output variables and consume them in downstream tasks.
More information here: https://learn.microsoft.com/en-us/vsts/build-release/
Related
Does anyone know if the feature to tag agents has dissapeared?
I could not find anything related to over the internet.
My idea is to have certain builds use a specific agent. On TFS 2013 I would use tagging, but i no longer see that option.
On the other hand, I see that it is possible to connect a build definition to a certain agent queue.
There is no more agent tags for TFS 2015 or later version. If you want to use a particular build definition and a specific build Agent which used to run the build.
You could add a user Capability to that specific build agent then in the build definition you put that capability as a demand (General tab).
Another way is directly using Agent.Name or Agent.ComputerName demands in build def or when queuing a build. Take a look at this blog: How to send TFS build to a specific agent or server, which also support on TFS2015.
Oren: Is this feature works in TFS15 SP3?
Reply Eric Parvin: Yes, this should work on TFS 2015 to the newest version.
Use demands and capabilities for this. Add a custom capability to the build agent, and then add a matching demand to the build definition.
Demands and capabilities would work, and you could also create a specific queue, with a single available agent in it, and set the queue to your desired build, so you would achieve the same behavior as desired one.
I've been tasked with migrating a build from TFS to VSTS, I've used TFS from a developer point of view, however I've never created builds. Can anyone give me any advice where to start, good websites, tutorials, tools that might help, anything that might catch me out etc, basically my knowledge on this is very limited so anything would help. I've no doubt there must be somebody out there who can say we've done this, here is what we did...the new VSTS build will need to be a copy of the TFS build however some analysis needs to be done as the build process is old and certain parts may not be necessary. Thanks in advance!
Migrate New Vnext build definition from TFS to VSTS
If you want to template your builds or move them from TFS to VSTS, you could also use the REST API's to perform this. Details please refer this blog: HOW TO MOVE BUILD DEFINITIONS IN TFS TO OTHER PROJECTS USING THE REST API
Another example shown here. It shows how to get the JSON response of a build definition and again using the same reference to make a new one in the project you desire.
Migrate Old XAML to New Vnext build definition from TFS to VSTS
Unfortunately, there will not be any automated conversion processes. The new builds are based on a different architecture and run on a completely different system. And you can use both the new builds and agents alongside your XAML builds, controllers, and agents.
If you have heavily customized XAML builds and custom activities, you
can continue using those builds until you are ready to port your
business logic into scripts that can run in the new builds.
You should also take a look at these series of articles by jessehouwing devoted specifically to the case like yours.
About how to create a build, you could refer this tutorial from MSDN.
My team is just now starting to use TFS 2015 Update 1 on premise to manage their development process. I have set up the server and defined some custom states and transitions for work items to better map to our process. To start with, we will only be taking advantage of the Kanban board and are not attempting to use iterations for a variety of reasons I won't get into here.
My problem currently is using TFS to plan releases. Specifically, I don't see any way to group Features and User Stories into a specific release. All of my googling has turned up many articles involving Microsoft Release Management, so I installed and configured it, but it is absolutely overkill for what my team is trying to do right now. I'm not trying to automate deployments to different environments at the moment, I just need a way to group work items into a something that encapsulates the concept of a release in TFS. Is there no way to do this? The best I can come up with right now is to further modify the work item templates to either provide a simple "Release" field with a pick list, or define another type of work item that I can group the others into. This seems like a glaring oversight by MS from my perspective, so I'm hoping I'm just missing something.
Grouping work into releases can be done in a couple of ways, just remember that the concept of a "Release Plan" doesn't explicitly exist in TFS. Release management covers the "Release to Production", but doesn't cover any planning.
Ways to plan releases:
One way is to create a Release Iteration, this works when you're not working on multiple releases in parallel and truly finish one release before working on the next. The Release iteration used to be default, but has been removed from the product in favor of teams delivering sprints and teams doing continuous delivery.
Project Root
+ Release 1.2
+ Sprint 1
+ Sprint 2
Another option is to use Tags. You could tag work items with a tag that signifies it's targeted for a specific sprint.
Use a Marker workitem, on the backlog place one work item which clearly stands out ### END OF RELEASE 1 ### Any workitem below it is not part of that release. This technique fits a more agile way of working and more clearly shows that the contents of a release are a floating thing.
Create a custom Release Workitem, link your other workitems to this work item to target it for that release.
And your option to create a picklist on a *Custom workitem field** is another option.
Alternatively you could also use the Area Path in much the same way as Iteration Path. By using the Area Path you have the benefit of not having a sprint tied to one specific release.
It is not the best solution but could be the solution in some cases.
Answering solely based on your question around planning releases, then:
Create a custom work item template, called 'Deployment'.
When planning of a release begins, create a new 'Deployment', let's say, called 'MyProduct v1.1'.
In your planning meeting, create Features and User Stories appropriately, and create a relation to the 'MyProduct v1.1' Deployment, by opening the User Story and adding a Link (using the Deployment Work Item number) as 'Related'.
To monitor Deployments, create a custom Work Item query targeting the new 'Deployment' Work Item template. You can configure this to display on your dashboard.
Follow whatever release procedure you like based on the 'Deployment' and its' relations.
You should follow a naming convention when creating 'Deployments' for consistency.
p.s. I recommend using the extension 'Work Item Visualization' in this instance. It'll nicely map out the 'Deployment' related Work Items.
If you want to use TFS to actually build an and create a Release, then Release Manager is worth considering.
TFS 2015 Update 2.1 now includes a built-in version of Release Manager. It's much more user-friendly and simple to configure when compared to Release Manager standalone installations.
To group work items into a 'release', you can do the following:
Create a build definition for the repository you're working with - see Build Def creation docs
Create a Release definition - see Release Def creation docs
Once you have these definitions created, the working process would be:
Developers work against work items
Commits are made against the WI number (or tasks)
When it's time to create a release, start a build on the definition you created. In doing so, WIs will then be associated with a Build Number.
When the build succeeds, start a new Release from the definition you created.
You have have a set of work items associated with a release, see screenshot:
Note: You can enable CI builds and releases, although the above is based on manual triggers.
You can also directly call the Release API to locate WIs associated with Releases, however you'll need to obtain the actual Id of the release first.
You are currently limited however to viewing these relationships based on knowing the Release. In a real world scenario, it's more realistic to look at a Work Item to see when it was release. To do that, there's no built-in functionality at present, however my own-answered question will guide you - see here.
Additional to the methods explained by jessehouwing there exists also several 3rd party tools which can integrate with TFS/VSTS and provide advanced planning features. See VSTS Marketplace for an overview.
I am working with Visual Studio 2012 .NET 4.5 ASP.NET MVC 4 project that uses TFS for source control and TFS Build for continuous integration (CI).
I want to create functionality that on each check in the build number gets updated prior to the CI build is kicked off.
From research it seems that a custom activity can be created and integrated in TFS 2010 build template.
I have also seen examples of this can be achieved with MSBuild task.
I haven't done work in this area before, so I am wondering which is the better approach or the recommended approach based upon the options open to me? In general when would I use MSBuild tasks as oppose to custom activity? For example, I will be looking to run FxCop and StyleCop against check ins also in the future, so I would like a common approach to this.
In the case of incrementing the build number, I'd vote for the TFS Build Activity so that the implementation is not tied to your msbuild implementation. This allows you to easily apply the TFS workflow activity to any number of branches without tying it to the branches directly. In addition, it keeps your MSBuild project files clean of the task so that it isn't mistakenly executed on developer machines.
Holistically, I'd say that you need to take a variety of factors into account when deciding between MSBuild and Workflow activities:
1 - Does MSBuild support the functionality out of the box (like Code Analysis/FxCop)?
2 - Does the build step need to run on developer boxes as well as servers (StyleCop/FxCop)?
3 - Does the build step need to interact with the TFS API or source control directly (checking out/in a version file for incrementing)?
4 - Are you going to change build job schedulers later to something free (for example, Jenkins)?
It's the combination of these things that determines the implementation of any given tool integration in my book. I'd implement FxCop, StyleCop and any other tool that should be run on a developer box build via MSBuild. I'd implement build steps such as version incrementing, bin-placing and CI deployment invocation (for example, deployment of a SharePoint webpart as a post-build step) via a Code Activity or some scriptware.
I'm a bit confussed as to the best way to handle our projects in TFS.
We are a CMMI level 3 (working on level 4) compliant organization. As such we are currently using the MSF CMMI process template in TFS, which I'm working on customizing to beter suite the needs of our organization.
With each new release (whether that be a major or point release) we have to follow a standard process that includes multiple qualtiy gates and required documentation (project plan addendums, deployment plans, qualtity gate presentation materials, requirement review documents, etc). My problem is that from what I can see, TFS only requires process to be met with each project not release (we have been trying to use iterations to identify the releases).
The question is, is there a way to have a process indicate the documents required for each release or do I need to start a new TFS project with each release.
As a potential follow on question. If you need to create a new project each for each release, how do you handle source control and work item history.
You are right that opening a new TFS project for each release is probably overkill.
Instead, I recommend creating a release plan for each release, and associating each needed document with a Work Item.
Here are some details on one way to create a release plan, and here is an example template with helpful types built in.
If you have a bunch of spare time lying around, you can customize Work Item fields to create tasks that fit your documentation requirements.
To manage multiple releases in a single TFS project, I recommend simply creating multiple folders, and adding Work Items associated with each release to each folder.