I'm recently working with TFS 2015. I've realized that Microsoft has introduced a new way to configure TFS build pipelines which I think it is very intuitive.
Anyone knows if there is a mechanism to export or save these build configuration?
I think that it would be very useful to have the configuration into the versión control.
Thus, a user could review the history about how the pipeline has been changed. Also it would be possible to clone the build pipeline into another TFS continuous integration server.
Thanks!
Into source control? No. But go look at the "History" view on any build definition, it will show you exactly what you want: A full revision history of the build definition.
Related
We used to get notification from the tray of our windows machine for a finished build while using the xaml build definitions, it also had an option to reconcile workspace. The same functionality is not available for the vNext builds.
The BuildNotification App is available with VS 2015, but it seems that the reconcile workspace is not available with the vNext build. Is there some other app that can give a notification and do the reconcile operation?
We just moved to new builds (vNext) and are missing this feature as well.
Currently, we can do this manually via IDE (VS 2015):
Team Explorer -> Builds
Right click on latest build with you changes -> "Reconcile Workspace..."
The BuildNotificationApp is still a part of the VS 2015 and can be found here: C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\BuildNotificationApp.exe. However, this app only applied to XAML build.
For now, to workaround the missing feature, you can use a free build status tool Catlight . It also shows status of vNext builds in tray area.
As for reconcile workspace, there is no this build-in feature for vNext build. However, you can manually use tf reconcile command for your workspace. Such as below screenshot:
Update:
If you just want a simple app or vs extension to achieve it, there is no these things for now. You may have to customize your own extension to implement it.
Update2:
I have created a feature request in uservoice:
Reconcile Workspace for vNext Build
https://visualstudio.uservoice.com/forums/330519-team-services/suggestions/15979690-reconcile-workspace-for-vnext-build
You can use AnyStatus to monitor both vNext and XAML builds.
AnyStatus comes with a feature called Triggers which lets you run a program or a batch script in response to status changes. Using Triggers you can configure it to run "tf.exe reconcile" when the build status changes from Running to OK.
Disclaimer: I am the author of Any Status.
I'm currently setting up continuous integration using TFS/Visual Studio Team Services (was VS Online), and I'm using the Team Foundation Build 2015 tasks. So not the XAML builds.
I'm using it to build a Xamarin Android project, but that's pretty irreverent I guess,
The process should be like this:
After a check-in:
TFS should download the sources
TFS should increment the version number within AndroidManifest.xml
I've managed to do this by making a PowerShell script for this.
After the AndroidManifest.xml file is modified, it should be committed back into the TFS repository
Then the rest, build deploy into hockeyapp etc
The first steps are all configured, but I'm struggling with the commit part. How do I get TFS to commit the file? I don't really see any task suitable for it. I've tried using the Copy and Publish Build Artifacts Utility - But that did not seem to work, and I'm not even sure if that's the right utility
I'm using the default hosted build agent btw. Any help would be appreciated
Warning
I do want to point out that checking in changes as part of the build can lead to some features of VSTS/TFS not working. Association of work items to the checkin, sources and symbol generation, tractability from changes to build to release and integration with Test Manager, remote debugging, will likely not yield the expected results because the Changeset/commit recorded in te build may not match the actual sources. This may lead to unexpected funny behavior.
Also, if any new changes have already been committed/checked-in after the build has started, the version number may be updated in Source Control for code that was not actually released under that version.
So: First of all, it's considered a bad practice to change the sources from the build process.
Alternatives
There are better ways of doing it, one is to use the build version (Build_BuildNumber or Build_BuildID variables). Alternatively you an use a task like GitVersion to generate the semantic version based on the branch and tag in your git repository. That way your build will generate the correct version number and will increment the revision in case the same sources are built multiple times.
I understand, but I still want to check in my code as part of the build
If these things don't work for you and you still want to check in the changes as part of the build, you can either use the TFVC Build Tasks if you're using TFVC or use the Git Build Tools to add the remote to the local repository and then use the git commandline tools to commit and push the changes back to the repository.
These extensions require TFS Update 2 to install. But you can push the individual build tasks using the tfx commandlien tool. For the TFVC tasks the process is explained here.
On mac
On the mac it's going to be harder since you're using TFVC. My TFVC tasks leverage the TFS Client Object Model and Powershell to communicate to the TFS Server. The tf.exe tool doesn't even work on windows when you're in the context of a build, which is why I need to call into the VersionControlServer object directly. Given I'm dependent on these technologies, the tasks won't run on a Mac or Linux agent.
You could try to see whether the Team explorer Everywhere X-platform commandline works from the build agent (using a shell script). I have no way to test this on an actual Mac.
Given the cross platform nature of your project I'd recommend to move to Git, it integrates into XCode and Android Studio, making it easier to do a native UI or build on top of native libraries.
Alternative 2
You could setup a build which does the required changes to the code and then checks in the modified code. Then have a (CI) build run the Android and the Mac builds using the modified code.
I just downloaded the Automatic Versions add-in for VS here (https://visualstudiogallery.msdn.microsoft.com/dd8c5682-58a4-4c13-a0b4-9eadaba919fe/view/Discussions) and it works great locally, but how do I get it to work with Team Builds? Is there something I should install on the build server?
Firstly, the Automatic Version addin is not called in TFS build even if it is installed on TFS build server machine. In other words, you can't use it to generate incremental assembly version during TFS build process.
Instead, you need to create one custom build process activity to update assembly version, then customize the TFS build process template to add the activity. Please check the following links for the details of the sample build activity and how to customize build process template to use it.
http://www.codeproject.com/Articles/705482/Updating-Assembly-Versions-During-TFS-Builds
http://tfssimpleversioning.codeplex.com/
http://blogs.msdn.com/b/jjameson/archive/2010/11/29/incrementing-the-assembly-version-for-each-build-in-tfs-2010.aspx
It very easy using the TFS Plugin (https://wiki.jenkins-ci.org/display/JENKINS/Team+Foundation+Server+Plugin) to check detect code changes committed to TFS, check out the code and compile it using Jenkins.
However I need to check a build artifact back into TFS after the build is complete. I can't see an option to do this.
Is there a way to commit artifacts tfs from jenkins build
This link might prove useful.
https://blogs.msdn.microsoft.com/visualstudioalm/2016/05/27/continuous-deploymentdelivery-with-jenkins-and-vs-team-services/
It's Developer Tools Blogs > Microsoft Application Lifecycle Management article which shows how to set up a Jenkins project that archives artifacts on TFS.
It's titled "Continuous deployment/delivery with Jenkins and VS Team Services" by Anand Gaurav...Really easy to follow and each step is carefully explained.
Does anyone have specific experiences with using TFS 2008/2010 AND Jenkins for Continuous Integration (CI)? We are trying to decide which CI server to use. Our team works exclusively in Microsoft .NET/Visual Studio 2010/C#. We have the following requirements:
Automatically build our web project on every checkin.
Run unit tests with each build.
Automatically deploy green builds to development and/or test environments.
Provide pretty reports.
Provide build/deployment notifications via email.
I realize that installing a tool won't necessarily give us this functionality out-of-the-box and that we will have to integrate with other tools like MSBuild to achieve this.
I'm looking for specific features that Jenkins has that TFS 2008/2010 does not or vice versa. Also which is easier to maintain, use, etc.
I would highly recommend using Jenkins - it will do all of your requirements out of the box apart from possibly #3, but if you can script your deployments then it can do that as well.
Here are some links to help you get your builds up and running:
Blog about doing .NET builds in Jenkins
Jenkins Windows installers
Installing the Jenkins master and slaves as Windows services
Disclaimer: I have no experience with TFS, but I think open solutions are nearly always more flexible and extensible (and cheaper !) than proprietary products.
Late to this game, but I have used both TFS 2010 and Jenkins for CI. TFS 2010 has minimum set of CI tools in it. However, when you want to create a CI pipeline, it's a completely different story while Jenkins can easily create the pipeline.
If you are looking at only CI for one build either one should work. However, when it comes to the entire pipeline, Jenkins is way to go. With TFS it can be done, but Jenkins is better choice.
Here's quick bullet points:
TFS:
With a build definition you can compile, execute tests, return changeset/workitems, send an email when a build is broken
natural integration with visual studio
extremely hard to create CI pipeline. Requires custom handler and extensive workflow work. Not as intuitive as creating a build definition.
Because of the 3rd bullet, it's not easy to maintain/customize/scale CI pipeline
Jenkins:
Need to create a msbuild config file for CI, which is not much pain comparing to creating CI pipeline using TFS. However, TFS gives better/easier tool to create a build definition. however, it is not bad creating config file for msbuild for a project.
Creating a CI pipeline is very easy. Just chain them using upstream/downstream jenkins job trigger and passing an artifact from previous job.
Since Jenkins is very flexible, it is easy to create a jenkins plugin to meet your own needs and provide it to opensource community :)
In summary, if you need complete automated build, test, and deployment system go with Jenkins. If you just need only build and test, TFS might give you an edge over Jenkins.
If you're using Team 2010-2012, there is no reason whatsoever to bring in Jenkins. Team has all the features you listed, and the build process is ridiculously flexible.
Note that if you are stuck on Team 2008 or earlier, you should seriously look at Jenkins -- 2008 and earlier are quite primitive and inflexible compared to 2010 or later.