My team has TFS build machine building checkins.
Today, we have more than a dozen build definitions to prevent building projects/running test in unaffected areas. This was when we weren't using incremental build.
Now that we enabled incremental sync/build, I am thinking about creating one giant gate definition that include all my team's source code. Since incremental sync/build is enabled, unchanged files don't get built anyway. But TFS is still running all tests.
Is there a way to dynamically pick just test assemblies that were built recently?
I can do it by modifying build template to filter out test assemblies that are more x hrs old but before I go that route, I wanted to check if there is something already available.
thanks
Customizing the template is the right path. Beside the official documentation, take a look at ALM Rangers' Build Customization Guide.
The FindMatchingFiles activity has no date filtering, so you have to roll your own.
Related
We have a requirement of associating work items with TFS Builds. Generally, this is possible (or we can say 'natural') while using XAML Build Templates in TFS (via　Integration Build　field of WorkItem. In the below screenshot it was mentioned as 'Integrated In'). We are currently trying to migrate from XAML Build Templates to vNext version of VSTFS 2015 and further to integrate with Octopus Deploy for CI/CD practices.
We are now half the way in the migration because we are stuck up making this vNext templates to associate TFS WorkItems with their Build numbers. Without doing this step, if we complete this migration, it will be difficult to get associated build numbers for each Work Items delivered in that build.
When we searched MSDN blogs, we got a post (link given below) similar to our requirement but I tried that and ended up with no luck.
https://blogs.msdn.microsoft.com/tfssetup/2016/05/09/build-association-with-work-items-in-vnext/
So, please suggest the ways which can resolve our requirement.
Since you are going to migrate from XAML build Templated to vNext. Suggest you also upgrade your TFS version to higher all together.
Just as Daniel point out TFS2015 released already 4 years, kind of little old. Same latest feature in TFS/Azure DevOps are not supported.
What you are looing for is a build-in option in TFS2017 update2 and above version.
Automatic linking from work items to builds
With this new setting in the build definition, you can track the
builds that have incorporated your work without having to search
through a large set of builds manually. Each successful build
associated with the work item automatically appears in the development
section of the work item form.
To enable this feature, toggle the setting under Options in your build definition.
More details refer this blog.
Besides, you could also take a look at our official tutorial Migrate from XAML builds to new builds in case you need.
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.
I have a TFS 2010 with some projects and a common library used in 5 of them. We use VS 2013 and we have Rolling Builds enabled in most if not all build definitions. When the common library is checked in, all of the projects referencing it are recompiled - but the order is poor, the most commonly used project is compiled as the last one. Is there a way to change that so it gets compiled first?
This question hints at a lot of problems and possible solutions. The simplest answer is probably to just add more build servers to run all the builds in parallel.
Otherwise you need to consider turning off rolling builds and writing your own build scheduler. That or other strategies such as building the DLL once and checking it in as source to the other builds or running the build on a branch that is outside of the other 5 builds and merging the source into those builds when they want to pick up the change.
If you are otherwise happy with how things are now and don't want to do a lot of work to solve the problem.... then just scale out your build farm with additional agents.
There's a "Priority in queue" on the build definition, but it sounds like you might want to change your solution's > Project Dependencies' > Build Order?
I'm starting to dive into TFS 2012 and I have a basic understanding of the tiers and how build servers, controllers and agents work and how different build scripts can have different configurations and projects.
However, one of the things I'm struggling with is a requirement for our source control solution that says that I need to be able to prove a particular changeset or shelfset produced a particular build. That is, given a particular binary, I can point to a release changeset that generated that binary. I should also be able to point to the test changeset that was merged into the release branch. The idea here is not just a separation of duty, but validating that because the release and test changesets are identical, no code was injected into a project by a code reviewer.
I've read one blog post that talks about "Binary promotions" -- would that concept be useful in my situation? I'm having a hard time finding how this binary promotion is set up in TFS.
Deployment
Out of the box TFS doesn't really support deployments, it can deploy to 1 location on build which often is a test server (think lab management). TFS 2012 has built in support for Azure deployments, but they still happen at the end of a build and the build artifacts cannot be automatically deployed to a new location.
You could modify the build template to allow to release to different locations, but that would still be a fresh build for every environment and not true binary promotions.
TFS does, however, have a concept of build quality and actually fires off events when this quality is changed. TFS Deployer is a 3rd party tool that hooks into the quality change event and can execute powershell scripts. This means with a simple change of a dropdown value you can automatically kickoff a script that releases to any environment you want. You can customize the build quality list (per team collection) to be a list of environments (dev, uat, staging, production etc) which the script then figures out where to release the specific build to.
VS2012 also has some nice improvements to web deploy which means deployment configurations are stored in source control with the project, which in theory means they'll be available in the drop folder for TFS Deployer to make use of.
I don't believe TFS keeps a history of build qualities, which means you can't really use the build quality history to maintain a list of what is deployed to which environment. You could fairly easily record this information as part of the deployment script though. Or at the very least add a custom summary node to the build with information about the release.
TFS2012 does have the ability to mark a build as deployed as part of the Azure deployment functionality, you mark tfs deployer builds as deployed using a script but it doesn't feel very useful.
Octopus Deploy is another project that's worth checking out, and could be used instead of TFS Deployer if your build template creates NuGet packages. It requires a bit more control over the production hardware as you need to install agents on each environment to handle releases, but it solves a lot of other issues with deployment.
Versioning
Once you have a nice consistent way of automatically releasing that people don't bypass, you can look at enhancing the build template to inject the build version, or changeset number as the assembly version for anything built as part of that automated build. There's a number of different ways to do it and plenty of blog posts and tools to help you achieve that.
Alternatively you could just use automatic assembly versioning ([assembly: AssemblyVersion("1.0.*")]) to give you the date/time the build occurred, which ends up like 1.0.1234.123 where 1234 is something like the days since jan 1st 2000, and 123 is the minutes since midnight (my specifics may be wrong here).
If you're deploying websites, then I highly recommend injecting the current build version into the html somewhere. This way you can check what version a website is running without needing access to the bin directory. It can also be appended as a querystring to css/js file imports to ensure no browser caching occurs between versions.
Thoughts
Personally I'm hoping Microsoft realise that the xaml build workflows are trying to do too much and that they split the different concerns (build, test, deployment...) into different scriptable parts. Of course that would not be until the next major release of TFS which is years away. Although with Team Foundation Service they are trying to iterate a lot quicker, so they may actually extend the Azure deployment stuff into something more useful in the nearer future.
I'm currently working on creating a build template for TFS2010 builds. However, I notice that I'm currently 'spamming' the source control with every change I make to the template (and lots more for all the fixes for those changes).
I wonder what the easiest way is to test the build templates I'm creating?
Is there a way to change the template file and custom activity dlls that doesn't involve checking them in?
I currently have a build controller and agent running on my developer machine, which I'm using to test the template (test = start a build and hope for less errors than last time).
Why is 'spamming' a problem? Anyway, I have a separate Team Project for doing this kind of work, that way I can check in to my hearts content without affecting the developers who need to have a stable build. once I've done my testing I check the template in to the team project(s) used by the developers.
I want to test my builds against the teams latest code-base without having to branch it over to a trial project.
Instead, I do the following:
Create a separate build definition called 'Infrastructure'
clone a production definition
Set the trigger on the Infrastructure build definition to manual.
Set the Infrastructure definitions permissions to allow only [Project]\Build group members to have full control of it.
keeps the notification of broken builds away from the bulk of the team).
Create a separate build process template, called 'Infrastructure.xaml'.
Point the Infrastructure build definition at the Infrastructure process template.
Now when I want to iterate on a new build feature for the team:
Check out the build process template I want to update, and lock it.
Copy the build process template I want to update overtop of the Infrastructure.xaml.
Add my build feature to the Infrastructure.xaml file, and check that in.
Use the Infrastructure build definition to test my changes.
Iterate over 3-4 until I get it right.
Complete the feature and have my changes verified by another Infrastructure team member.
Copy Infrastructure.xaml over the build process template I locked in (1) and check it in.
This still results in 'spam' in the TFS source control, but it keeps the build definition iteration out of the eyes of the team. My build process templates are located out of the main source tree (under the Build Process Templates folder, or in the branches themselves under a 'Core/Build' folder where no-one else on the team is typically paying any attention) so that the team is largely unaffected by it.
#d3r3kk: Why not just branch the template and merge changes back when ready instead of creating copies? That way you can preserve source history in a cleaner way as well.
Ideally, there should be a way to have a build process template that is in progress by having it on your local file system and pointing the build definition to it temporarily. Not sure if something like this exists in later versions of VS/TFS. I haven't seen it available via the UI anyway.